接続トラブルシューティング · Clash 技術ブログ

Clash Party でサブスクリプション更新後に設定の検証へ失敗する場合は?

Clash Party v2.0.1 では、リモートサブスクリプションを更新する前の設定検証が追加されました。旧バージョンですでに異常な内容へ上書きされた場合は、まず現在の動作状態を保全し、利用可能な Profile を復元してから更新します。失敗する候補によって以前の設定が書き換えられないことも確認してください。

  • Clash Party
  • サブスクリプションの更新
  • 設定の検証
  • Mihomo
  • 障害からの復旧
目次

ダウンロード成功後、カーネルに拒否された段階で障害が起きたことを確認する

この記事で扱うのは、範囲が明確な Clash Party 2.0 の問題です。元の Profile は利用できたのに、リモートサブスクリプションを更新すると設定検証の失敗が表示され、ホットリロードやカーネルの再起動にも失敗します。公式 issue #2047 に記録されているのはダウンロードのタイムアウトではありません。新しいファイルはダウンロードされ、YAML としても解析できますが、最終設定が Mihomo の検証を通りません。

サブスクリプションのアドレスが 401、403、HTML ページ、空の内容、Invalid YAML のいずれかを返す場合、障害はそれより前の段階で発生しています。サブスクリプションの応答と YAML 構文から先に確認してください。ダウンロードに成功し、Profile が書き換えられた後、Mihomo が読み込みを拒否する場合だけ、この記事の手順を続けます。

最後に有効だったエラーに沿って切り分ける

表示された結果障害が起きた段階対処の入口
401、403、タイムアウト、Web ページのいずれかが返るサブスクリプションのリクエストから設定を取得できていないリンク、認証、ネットワーク、提供元の状態を確認する
Invalid YAML、インデント、引用符のいずれかに誤りがあるファイルがまだ YAML の解析を通っていない形式を修正し、現在の Profile を上書きし続けない
YAML は読み取れるが、proxy group not found などのエラーが出るMihomo の意味検証に失敗しているノード、ポリシーグループ、ルール、オーバーライド間の参照を照合する
更新は成功し、特定のノード接続だけが失敗する設定は読み込み済みで、問題はノードまたはプロトコルにあるノード、TLS、UDP、ネットワークの確認へ移る

通信できる間に、動作中の古い設定を保全する

設定のホットリロードに失敗しても、動作中の Mihomo は一時的に以前の利用可能な設定を使い続けている場合があります。この時点でカーネルの再起動、アプリの終了、サブスクリプションの再更新を急いで行わないでください。これらの操作で、まだ機能している古い実行状態が失われる一方、ディスクへ書き込まれた新しいファイルは自動的には直りません。

サブスクリプションカードの更新ボタンを押すのを止めます。この Profile に自動更新が設定されている場合は一時的に無効にし、元の間隔を記録してください。その後、既存のバックアップから以前の利用可能な Profile を探すか、サブスクリプション提供元に上流設定を先に修正してもらいます。唯一のバックアップをテストファイルとして直接使用しないでください。

復旧できる余地を残す

  1. 現在の実行状態を固定する

    Profile の切り替え、カーネルの再起動、Clash Party の再起動を行わず、まず現在の Web ページへ元のノード経由で引き続きアクセスできるか確認します。

  2. エラーとバージョン情報を保存する

    検証エラーをコピーし、Clash Party、Mihomo、Profile、更新時刻を記録します。鍵を含む完全なログはエクスポートしないでください。

  3. 利用可能なバックアップをコピーする

    最近利用可能と確認した Profile を別のディレクトリへコピーし、元ファイルには触れずに残します。バックアップがない場合は、まず提供元へ修正済みの設定を依頼してください。

  4. 上書きを続けない

    候補ファイルが完全な検証を通るまで、手動更新を行わず、ダウンロードした内容を使用中の Profile へ貼り付けないでください。

YAML を開けても、Mihomo が実行できるとは限りません

YAML パーサーが判断するのは、インデント、リスト、キーと値の構造が成立しているかだけであり、各ポリシーグループの参照先が存在することは証明しません。次の例は構文上は有効ですが、「手動選択」が未定義のポリシーグループを参照しているため、Mihomo は読み込みを拒否します。

Clash Party は、リモートサブスクリプションにグローバルオーバーライド、個別 Profile のオーバーライド、ルール、制御された設定を組み合わせて最終実行設定を作ります。リモートファイル単体が正常に見えても、マージ後に名前の重複、参照先の欠落、未対応フィールドが生じる場合があります。そのため、YAML を開いて見るだけではなく、最終候補を検証する必要があります。

構文は有効だが、意味が無効な例
proxies:
  - name: 节点 A
    type: socks5
    server: 127.0.0.1
    port: 1080
proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - 不存在的策略组
rules:
  - MATCH,手动选择

特定の proxy group が存在しないとエラーに示される

その名前が proxies または proxy-groups に実際にあるかを確認し、スペース、大文字と小文字、全角記号も照合します。

特定のオーバーライドを無効にすると検証が通る

問題はマージ結果にあります。無関係なノードを変更せず、オーバーライド内の古いグループ名またはフィールドを修正してください。

元のサブスクリプションとすべてのオーバーライドを組み合わせても失敗する

機密情報を伏せた正確なエラーをサブスクリプション提供元へ渡し、上流で生成される設定の修正を依頼します。

同じファイルが別のカーネルバージョンでは通る

二つのバージョンとエラー全文を残し、実際に使用する Mihomo のバージョンを基準に判断します。別のカーネルの結果を受け入れ確認の代わりにしないでください。

新しいサブスクリプションを候補ファイルとして個別に検証する

修正時は、新しいサブスクリプションを一時的なコピーとして先に保存し、現在の Profile を上書きしないでください。token を含むリンクをオンライン変換サイトへ送信してはいけません。各ルールの接続先、各ポリシーグループのメンバー、すべてのオーバーライドの参照先が存在することを順に確認し、Clash Party が実際に選択した Mihomo カーネルで最終候補をテストします。

コマンドラインに慣れている利用者は、一時的なコピーに対して Mihomo のテストモードを実行できます。コマンドが正常終了しても、このカーネルで候補を解析・初期化できることを示すだけです。ノードへ接続できることは証明せず、後の実リクエストも代替できません。唯一の設定原本をその場で書き換えないでください。

候補ファイルからインポート可能な設定まで

  1. リモートの原本を残す

    今回ダウンロードした内容を一時ディレクトリへ置き、比較用に機密情報を伏せたコピーを別に保存します。サブスクリプションの URL をコマンド履歴やチケットへ記録しないでください。

  2. 参照関係を照合する

    検証エラーで示されたグループから始め、proxies、proxy-groups、rules、rule-providers を確認し、存在しないか改名された接続先を修正します。

  3. 実際のオーバーライドを重ねる

    グローバルオーバーライドと対象 Profile のオーバーライドを確認対象へ含めます。マージ後だけ失敗する場合は、同じサブスクリプションを何度もダウンロードせず、オーバーライドを修正してください。

  4. 選択したカーネルでテストする

    一時的な最終設定へテストモードを実行し、終了コードとエラーを保存します。正常終了した場合だけ、インポート手順へ進んでください。

上級利用者は一時的なコピーにだけ実行する
mihomo -t -f candidate.yaml
リモートサブスクリプションを安全に検証する順序
  1. リモートサブスクリプションの候補一時ファイルにだけ書き込み、現在の Profile を上書きしない
  2. ルールとオーバーライドをマージするClash Party が実際に使用する最終設定を生成する
  3. 選択した Mihomo -tグループの参照、フィールド、カーネルとの互換性を確認する
  4. 成功後に保存する失敗した場合は一時ファイルを消去し、以前の利用可能な設定を残す

PR #2048 では、保存処理が Mihomo の検証後へ移されました。v2.0.0 にはまだこの保護がなく、v2.0.1 で正式に収録されています。更新しても、以前に上書きされた Profile は自動的に復元されません。

すでに起動できない場合は、以前の利用可能な Profile を復元する

カーネルがすでに停止している場合は、まずシステムプロキシと TUN を無効にし、OS が直接接続できることを確認します。すべてのダウンロードが停止済みのローカルポートへ送られ続けるのを防ぐためです。その後、以前バックアップした利用可能な設定を新しい Profile としてインポートします。壊れた Profile はオフライン比較用としてだけ残し、現在の設定には戻さないでください。

バックアップがない場合、Clash Party のデータディレクトリ全体を削除して運任せに直そうとしないでください。サブスクリプション提供元に設定を修正してもらい、一時的な場所で意味検証を終えてから新しい名前でインポートします。こうすれば、元のオーバーライド、エラーの証拠、ロールバックの手掛かりを残せます。

ロールバック可能な順序で復旧する

  1. システムの直接接続を復元する

    システムプロキシと TUN を無効にし、ブラウザが停止済みのローカルプロキシポートへ接続しなくなったことを確認します。元のスイッチ状態を記録し、復旧後に一項目ずつ有効にしてください。

  2. 以前の利用可能なコピーをインポートする

    新しい名前で Profile を作成し、障害のある設定はまだ削除せず、自動更新も有効にしません。

  3. カーネルを起動し、一つのノードをテストする

    利用可能と分かっているノードを選択して一般的な Web ページを開き、リクエストが新しい Profile へ実際に入ったことを接続記録で確認します。

  4. 最後に自動更新を復元する

    手動更新、再読み込み、アプリの再起動を一度ずつ行い、すべて成功した後に元の更新間隔を復元します。

v2.0.1 では保存前の検証が正式に収録されています

Clash Party v2.0.1 は 2026年8月11日に公開され、公式リリースノートには「リモートサブスクリプションの更新前に設定を検証せず、異常な内容が以前の利用可能なサブスクリプションを上書きする可能性がある」問題の修正が明記されています。v2.0.0 にはこの保護がありません。現在の安定版は v2.0.2 まで更新されているため、旧版の利用者は利用可能な Profile を先にバックアップし、公式 Release から更新してください。

v2.0.1 は、まずリモートサブスクリプションを候補として扱い、制御された設定、ルール、オーバーライドを重ね、選択した Mihomo の -t モードで一時ファイルを検証します。検証に失敗した場合は保存済みの Profile を置き換えず、カーネルも再読み込みせず、その後一時ファイルを消去します。この保護が対象とするのは以後の更新だけであり、更新前に上書き済みの古い設定を自動的に取り戻すものではありません。

現在選択できる方法

選択肢対象となる利用者適用範囲
v2.0.1 またはそれ以降の安定版へ更新する更新前の検証機能を利用したい方現在の安定版は v2.0.2 です。Profile を先にバックアップし、失敗する候補によって以前の設定が書き換えられないことを確認します
v2.0.0 を一時的に維持する現在は更新の時間を確保できない方自動更新を停止し、候補を手動で検証します。旧版では利用可能な Profile が引き続き上書きされる可能性があります
旧版のアプリへダウングレードする別の明確なバージョン回帰へ対処する場合だけ上書き済みの Profile は復元できず、同じ更新経路を避けられる保証もありません

失敗する候補と有効な候補の両方で受け入れ確認を完了する

v2.0.1 またはそれ以降の安定版(現在は v2.0.2)へ更新した後、バックアップ環境で二回の更新を行います。一回目は機密情報を伏せた無効な候補を使い、Clash Party が検証エラーを返しても、以前の Profile の内容、現在のカーネル動作、ノード接続が変わらないことを確認します。二回目は検証済みの有効な候補へ切り替え、保存、再読み込み、実際のアクセスがすべて成功することを確認してください。

「更新完了」と表示されるだけでは不十分です。無効な更新で以前の利用可能な設定が壊れず、有効な更新は反映され、Clash Party を終了して再起動した後もポリシーグループを選択して接続記録を生成でき、システムプロキシまたは TUN を正常に無効化・復元できる状態が、実際の完了条件です。

v2.0.1 の更新保護に関する確認リスト

  • Clash Party が公式 v2.0.1 または、この修正を明確に含む後続の安定版へ更新されている
  • 無効な候補では、Mihomo の具体的な検証エラーが表示される
  • 無効な候補によって、保存済みの以前の利用可能な Profile が書き換えられない
  • 検証に失敗した場合、現在の Mihomo が再読み込みまたは停止されない
  • 有効な候補を保存でき、想定したノードとポリシーグループが表示される
  • 実際の Web リクエストが接続記録に表示され、ルールと出口が想定どおりである
  • アプリを終了して再起動しても通信でき、システムプロキシと TUN を正常に復元できる
  • 自動更新を再び有効にする前に、新しい利用可能なバックアップを保存している

参考資料