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

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

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

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

サブスクリプション更新の検証に失敗しても接続が続いている場合、急いで再起動すると、最後に使えている実行状態まで失う可能性があります。元のデータとエラーを保存し、新しい内容を候補ファイルとして別に検査してから、使える設定を復元します。アプリ更新は今後の更新を保護できますが、すでに上書きされたファイルを自動で取り戻すものではありません。

サブスクリプションは取得できたのに Mihomo が新しい構成を拒否する

Clash Party 2.0 で使えていた Profile、更新後の最終設定、検証エラーの全文を記録します。公式 issue #2047 では新しいファイルはダウンロード済みで YAML も解析できましたが、Mihomo が拒否し、ホットリロードや再起動ができなくなりました。ダウンロードのタイムアウトとして扱わないでください。

サブスクリプションのアドレスが 401、403、HTML ページ、空の内容、Invalid YAML を返す場合は、それより前の段階で失敗しています。まず応答内容と YAML の構文を調べてください。取得に成功して Profile が書き換わった後、Mihomo が読み込みを拒否する場合に限り、更新後の最終構成を確認します。

通信できている間に動作中の構成を保護する

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

復旧できる余地を残す

  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 のバージョンを基準に判断します。別のカーネルの結果を受け入れ確認の代わりにしないでください。

原因の判断に役立つ最後のエラーをもとに対処方法を選ぶ

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

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

候補の構成は別の一時保存先に置き、現在の Profile を上書きしないでください。token を含むリンクをオンライン変換サイトに渡してはいけません。

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

コマンドの mihomo は、アプリが実際に選んでいる実行ファイルを使う必要があります。同名の別プログラムで代用しないでください。candidate.yaml は実際の上書きを適用した一時コピーを指します。コアと候補ファイルの場所を確認できるまでは、テストを実行しないでください。

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

  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.3以降の安定版へ更新すべきなのか?

Clash Party v2.0.1は2026年8月11日に公開されました。公式リリースノートには「リモートサブスクリプションの更新前に設定を検証せず、異常な内容が既存の有効なサブスクリプションを上書きする可能性がある」問題の修正が明記されています。v2.0.0にはこの保護がありません。

2026年9月23日時点の公式最新安定版はv2.0.3で、悪意のあるrule-providers設定によって任意のコマンドが実行される可能性がある問題も修正されています。旧版を使っている場合は、まず使用中のProfileをバックアップし、公式Releaseから更新してください。

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

現在選択できる方法

選択肢対象となる利用者適用範囲
v2.0.3以降の安定版へ更新更新前の検証機能を利用したい方まずProfileをバックアップし、無効な候補を使って旧設定が書き換わらないことを確認します。v2.0.3にはrule-providersのセキュリティ修正も含まれます
すぐには更新できない現在のProfileを先に保存する必要がある場合自動更新を一時停止して候補を手動で検証します。旧版は有効なProfileを上書きする可能性があり、v2.0.3のセキュリティ修正も含まれないため、できるだけ早く更新してください
旧版のアプリへダウングレードする構成の復旧に使うべきでない方法すでに上書きされたProfileは復元できず、v2.0.3のセキュリティ修正も失われます

無効なサブスクリプションは以前の設定を上書きする?有効なものは更新できる?

公式のv2.0.3以降の安定版へ更新した後は、バックアップのある環境で二度更新を試します。最初は機密情報を除いた無効な候補を使い、Clash Partyが検証エラーを返しても、旧Profileの内容、現在のコアの動作、ノード接続が変わらないことを確認します。次に検証済みの有効な候補を使い、保存、再読み込み、実際のアクセスがすべて成功することを確かめます。

「更新完了」の表示だけでは不十分です。無効な更新では以前正常に動作していた設定を残し、有効な更新は正常に反映される必要があります。Clash Party を終了して再起動した後も、ポリシーグループを選べて接続記録が作られ、システムプロキシや TUN を正常に無効化して復旧できることを確認します。接続記録のルールと出口も想定どおりである必要があります。

参考資料