Clashの購読が無効・設定解析に失敗する場合の原因と復旧手順

Clashで購読を更新できないとき、画面にはリクエストのタイムアウト、異常なステータスコード、ダウンロード内容が空、設定の解析失敗、プロキシノード数がゼロ、設定を切り替えると直ちに元へ戻る、といったメッセージが表示されます。どれも「購読が使えない」ように見えますが、実際には異なる障害層に対応しています。購読の更新は少なくとも、URLへのリクエスト、サーバーのレスポンス、コンテンツ変換、YAML解析、設定の保存、コアの読み込みという6段階を経ます。更新ボタンを何度も押しても、同じエラーを繰り返すだけになりがちです。

切り分けでは、まずどの層で失敗したかを確認し、そのうえでURLの変更、購読の再生成、設定の修正、クライアントキャッシュの削除のいずれかを判断します。古い設定を保存しないまま、すべてのデータを削除しないでください。購読URLにはアクセス認証情報が含まれる場合があるため、公開ログやスクリーンショット、フォーラムにそのまま貼り付けるのも避けましょう。

まず購読更新に失敗した段階を特定する

最初に行うべきことはYAMLを変更することではなく、クライアントログで最初に出たエラーを確認することです。後続のエラーは連鎖的な結果であることが多く、たとえばダウンロード失敗の後に「設定ファイルが存在しない」、YAML解析失敗の後に「コアの起動に失敗」と表示される場合があります。エラー発生時刻、購読名、HTTPステータス、エラー行番号、使用中のコアの種類を記録し、次の特徴で分類してください。

REQUEST

リクエスト段階

タイムアウト、ドメイン名を解決できない、接続拒否、TLS接続失敗、HTTPステータス異常などが起こります。この時点では、設定内容はまだ解析器に渡っていません。

CONTENT

レスポンス段階

リクエストは成功したものの、ログインページ、エラーメッセージ、空白の内容、またはクライアントと互換性のない購読形式が返されます。

PARSER

解析段階

ログにYAMLの行番号、フィールド型エラー、重複した名前、未対応の設定項目が示される場合、ファイルはダウンロード済みですが設定を構築できていません。

STORAGE

読み込み段階

ファイルは解析できるものの、クライアントが古いバージョンを読み込み続ける、または設定ディレクトリへの書き込みに失敗する状態です。多くの場合、キャッシュ、ディレクトリ権限、設定インデックスが関係しています。

古い設定を手動で選ぶと正常に接続できる場合、コアとローカルネットワークは動作しており、問題は購読リクエストまたは新しい設定内容に集中している可能性が高いです。すべての設定が同時に使えなくなった場合は、システム時刻、ネットワークの入口、DNS、システムプロキシのループバック、ファイアウォールの状態も確認し、環境側の障害を購読の期限切れと誤認しないようにします。

購読URL、有効期限、リクエスト条件を確認する

購読URLは通常、一般公開された通常のウェブページへのリンクではありません。URL内のパスやクエリパラメータが、ユーザー識別、プラン状態、アクセス認証を担っている場合があります。サーバーによる古い認証情報の無効化、URLの再生成、プランの期限切れ、購読入口の移転後は、古いURLを開けてもエラー説明しか返らないことがあります。

URLが途中で切れていないか確認する

チャットアプリ、メール、QRコードから長いURLをコピーする際、表示された部分だけをコピーして末尾のパラメータが抜けることがあります。改行、全角記号、前後の空白が混入する場合もあります。クライアントの購読編集画面に完全なURLを貼り直し、スキーム、ドメイン、パス、クエリ文字列が連続していることを確認してください。余分に見えるパラメータを手動で削除しないでください。サーバーの認証やクライアント種別の判定に使われている可能性があります。

HTTPステータスから原因の方向を判断する

401 または 403：通常はアクセス認証情報の無効化、権限不足、またはサーバーによるリクエスト拒否を示します。まず購読サービスの管理画面でURLを再取得してください。
404：古い入口が移転した、パスのコピーが不完全、またはサーバーからリソースが削除された可能性があります。
429：短時間にリクエストが集中したことを示します。連続更新を止め、制限が解除されてから再度テストしてください。
5xx：サーバーまたは上流の変換サービスに一時的な障害があることを示します。ローカル設定を削除しても通常は解決しないため、古い設定を残して時間を置いて再試行してください。
301 または 302：リダイレクト自体は必ずしも障害ではありません。ただしログインページ、告知ページ、異なるスキームのURLへ転送されると、クライアントが最終的な購読内容を取得できない場合があります。

ブラウザでURLを開けても、クライアントで更新できるとは限りません。ブラウザはログイン状態を保存したり、自動的にリダイレクトしたり、サーバーが生成した説明ページを表示したりします。一方、Clashクライアントは通常、ネットワークリクエストを実行してレスポンス本文を読み取るだけです。逆に、ブラウザに読みにくいエンコード文字列が表示されても、内容が壊れているとは限りません。購読の中には、Base64でエンコードされたノードリンクの集合もあります。

システム時刻とネットワーク経路を確認する

端末の日付、時刻、タイムゾーンに大きなずれがあると、HTTPS証明書の検証に失敗することがあります。まずシステムの自動時刻合わせを有効にし、購読を再リクエストしてください。現在のネットワークで購読ドメインが遮断されている場合は、一時的に別の信頼できるネットワークへ切り替えて更新します。システムプロキシ経由で購読を更新する場合は、クライアントがループバックを起こしていないかも確認してください。クライアントが購読をリクエストし、その通信がまだ起動していない、または無効になったローカルプロキシポートへ再び向けられると、接続拒否やタイムアウトになります。

リクエスト成功後に異常な内容を見分ける方法

HTTP 200はサーバーが内容を返したことを示すだけで、有効な設定であることまでは保証しません。解析失敗の多くは、サーバーが返したHTMLページ、JSONエラーオブジェクト、空のレスポンス、誤った購読形式が原因です。この場合、ログに「proxiesフィールドが見つからない」「マッピングを解析できない」「不正な文字」、または先頭行付近の構文エラーが表示されることがあります。

よくある購読内容を区別する

Clashの設定は通常YAMLを使用し、主なトップレベルフィールドには proxies、proxy-groups、rules、proxy-providers、rule-providersがあります。mihomoは一部のフィールドに対応・拡張していますが、利用できる項目はコアのバージョンによって異なります。別の一般的な購読形式として、複数のプロトコルリンクを並べたテキストがあり、Base64でエンコードされている場合もあります。この形式は、クライアントまたは購読変換サービスでClash設定へ変換してから使う必要があり、完全なYAMLだと決めつけて直接読み込むことはできません。

レスポンス本文がHTMLドキュメントのタグで始まる、またはログイン案内、プラン期限切れの説明、認証ページであることが明らかな場合、問題はサーバーのレスポンス側にあります。ローカルのYAMLを修正し続けないでください。JSONが返った場合は、まずエラーコードと説明が含まれているか確認します。レスポンスが数文字しかない、または完全に空の場合は、購読URLを再取得し、サービスの状態を確認してください。

クライアントとコアの互換性を確認する

同じ設定でも、クライアントによって結果が異なる場合があります。従来のClashコア、Clash Meta（現在は通常mihomoの名称で開発・保守されています）、各種バージョンのGUIクライアントでは、プロトコル、DNSフィールド、ルールセットの動作、設定拡張の対応範囲が完全には一致しません。サーバーが新しいmihomoでのみ使えるフィールドを生成し、クライアントが古いコアを使い続けていると、未知のフィールド、未対応のプロキシ種別、起動時チェックの失敗が発生することがあります。

まずクライアントのバージョン情報画面でGUIのバージョンと実際のコアのバージョンを確認し、購読サービスが求める形式も確認します。クライアントでコアを切り替えられる場合は、古い設定を保存してから、ドキュメントに従って切り替えてください。対象フィールドに対応していない場合は、未知のフィールドを適当に削除するのではなく、互換性のある購読形式を選択します。フィールド同士に依存関係があるため、1か所を削除するとプロキシグループやルールの参照が無効になることがあります。

YAML設定の解析失敗箇所を特定する

YAMLはインデントとデータ型の影響を受けやすい形式です。ログに行番号が示された場合は、その行だけでなく数行前も確認してください。実際の原因が、直前のブロックでの引用符の閉じ忘れ、インデント階層の中断、リスト記号の位置の誤りである場合があります。設定を編集する前に元ファイルをコピーし、プレーンテキストエディターを使い、UTF-8エンコードを維持してください。

インデント、タブ、コロンを確認する

階層のインデントにはスペースを使い、タブを混在させないでください。同じ階層のリスト項目は同じインデントにそろえます。ノード名、プロキシグループ名、文字列値に特殊文字が含まれる場合は引用符で囲めます。特に、値にコロンの後のスペース、シャープ記号、その他YAMLとして解釈される可能性のある記号が含まれる場合は有効です。

proxies:
  - name: "Tokyo: Primary"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "Tokyo: Primary"
      - DIRECT

rules:
  - MATCH,PROXY

次の例は構造の説明 בלבדです：proxies、proxy-groups、rulesはトップレベルに置き、各リスト項目にはハイフンを使います。プロキシグループが参照するノード名は、ノード定義と完全に一致していなければなりません。実際のプロキシプロトコルには、対応する認証、トランスポート、暗号化パラメータも必要です。例のフィールドだけをコピーして、利用可能なノードになると考えないでください。

フィールドの型を確認する

ポートは通常数値、ブール値はコアが認識できる真偽値、リスト型フィールドは通常の文字列ではなくリストで記述します。よくある誤りには、proxiesを1行のテキストにする、ルールリストをオブジェクトにする、数値に単位を付ける、引用符の不足によって数値や特殊値が誤解釈される、といったものがあります。解析器が「expected sequence」と表示する場合はリストが必要であり、「expected mapping」と表示する場合はその位置にキーと値の構造が必要であることが多いです。

名前の参照とフォールバックルールを確認する

設定では、名前を使ってノード、プロキシグループ、ルールを接続します。プロキシグループが削除済みまたは改名済みのノードを参照したり、ルールが存在しないプロキシグループを参照したりすると、チェックに失敗したり実行結果が不安定になったりします。名前の比較では通常、大文字・小文字、空白、記号を含めて完全一致が求められます。ルールは具体的なマッチから順にフォールバックへ進め、MATCHは通常ルールリストの末尾に置きます。フォールバックが早すぎると、後続のルールがマッチしなくなります。

部分購読を完全な設定として扱わない

proxy-providersが返す内容は、プロキシの集合だけである場合があります。メイン設定のprovider項目がそれを読み込む仕組みで、ポート、DNS、プロキシグループ、完全なルールを含むとは限りません。そのため、常に単独のメイン設定として直接インポートできるわけではありません。同様に、リモートルールセットはドメイン、IP、ルール動作のデータを提供するだけで、起動可能なClash設定ではありません。コピーしているのがメインの購読入口であり、特定のproviderやルールセットのURLではないことを確認してください。

クライアントのキャッシュ、古い設定、書き込み失敗に対処する

購読レスポンスが正しく、設定も単独のチェックを通るのに、クライアントに古いノードが表示される場合は、キャッシュと保存層を確認します。GUIクライアントは通常、購読インデックス、ダウンロード済み設定のコピー、現在有効な設定、コアの実行ファイルを管理しています。画面上の購読名とディスク上のファイル名が異なることもあります。

自動更新を停止：診断中にファイルが上書きされ続けないよう、一時的に高頻度の定期更新を無効にします。
現在の設定をエクスポート：利用可能なノード、プロキシグループの選択、ローカルの上書き内容を保存し、現在の設定名を記録します。
購読項目を新規作成：古い項目をすぐに上書きせず、再取得したURLで新しい項目を作成して更新を実行します。
更新時刻を確認：クライアントに表示される更新時刻、ノード数、ログの時刻が今回の操作と一致していることを確認します。
設定チェックを実行：切り替える前にクライアントのチェック機能を使い、新しい設定を現在のコアで読み込めることを確認します。
切り替えてコアを再起動：プロキシコアまたはクライアントだけを再起動すればよく、システム全体を先に再起動する必要はありません。新しい設定が実際に有効な設定になったか確認します。
安定を確認してから古い項目を削除：ルール、DNS、プロキシ接続の検証がすべて完了するまで、復旧用のバージョンを残します。

更新後もファイルの時刻が変わらない場合は、設定ディレクトリに書き込めるか、ディスク容量が十分か、セキュリティソフトがクライアントの書き込みを阻止していないかを確認してください。クライアントをシステム保護ディレクトリにインストールすると、通常権限では隣接する設定ファイルを更新できないことがあります。適切なクライアントは通常、ユーザーデータをユーザー設定ディレクトリに保存するため、実際のパスをクライアントログで確認してください。

バックアップなしでユーザーデータディレクトリ全体を直接削除することは推奨しません。そのディレクトリには購読URL、上書きルール、プロキシグループの選択、DNS設定、画面設定が同時に保存されている可能性があります。まず設定をエクスポートし、クライアントのドキュメントに従って個別の購読キャッシュやインデックスを特定する方が安全です。クライアントに「設定をリセット」機能がある場合も、影響範囲を理解してから使ってください。

購読はインポートできるのにノードやルールセットが空

インポートに成功しても、すべてのリモートリソースが読み込まれたとは限りません。メイン設定が proxy-providersやrule-providersを参照している場合、コアの起動後にそれぞれのリソースへリクエストが送られます。メイン購読が正常でもproviderのURLが期限切れだと、プロキシグループが空、ルールセットのダウンロードに失敗、一部のノードが不足するといった状態になります。

プロキシ集合の更新を確認する

ログでprovider名、リクエストURLの状態、更新時刻を確認します。プロキシグループが useでproviderを参照する場合、provider名は定義と一致していなければなりません。リモート内容はコアが要求するprovider形式に適合する必要があります。通常のウェブページ、完全なメイン設定、互換性のないノードリストでは読み込みに失敗する可能性があります。プロキシグループが静的なproxiesとproviderを併用している場合、静的項目だけが表示され、リモート集合の失敗が隠れることもあります。

リモートルールセットを確認する

ルールセットのbehavior、内容形式、ルール種別は一致している必要があります。たとえばdomain、ipcidr、classicalのbehaviorはそれぞれ異なるデータ構造に対応します。メイン設定が参照するルールセット名、ルール内のプロキシ名、リモートファイル形式のいずれかが一致しないと、ルールセットが利用できなくなることがあります。更新後はログにルール数が表示されるか確認し、最後にMATCHなどのフォールバック動作が存在することも確認してください。

直結とプロキシ経由のダウンロード経路を検討する

リモートリソースは直接取得するよう設定することも、現在のプロキシ経由でダウンロードすることもできます。providerへのアクセスにプロキシが必要なのに、コアがproviderを読み込む前には利用可能なノードがない場合、起動依存が発生することがあります。反対に、サーバーが特定のネットワークからの直接接続だけを許可している場合、プロキシ経由を強制しても失敗します。クライアントとコアが対応する設定方法に基づいてダウンロード経路を明確にし、少なくとも1つの起動可能な方法を残してください。

復旧後の確認リスト

購読更新ボタンに成功と表示されても、設定が実際に動作へ反映されているか確認する必要があります。ノード一覧だけでは不十分です。DNS、ルール、システムプロキシが古い状態のまま残る可能性があるためです。次のテストを決まった順序で行うことをおすすめします。

購読の更新時刻、設定ファイルの変更時刻、ログの時刻が一致していることを確認します。
ノード数が想定どおりで、プロキシグループ内に大量の空参照がないことを確認します。
1つのノードで遅延テストを実行します。遅延結果はテスト先に到達できることを示すだけで、すべてのウェブサイトにアクセスできることを意味しません。
現在のプロキシモードを確認し、ルールモード、グローバルモード、直結モードのいずれがテスト目的に合っているか確認します。
接続ログを開き、対象リクエストが想定したルールとプロキシグループにマッチしたことを確認します。
DNSログを確認し、ドメイン名の解決失敗、誤ったマッピング、システムDNSによる迂回を除外します。
システムプロキシを有効にしている場合は、ローカルの待受ポートとシステム設定が一致していることを確認します。TUNを使う場合は、サービス、権限、ルーティングが確立していることを確認してください。
クライアントを一度再起動し、購読インデックスと有効な設定が現在のセッションだけでなく、継続的に保存されていることを確認します。

TUNモードはより広範なシステム通信を取り込みますが、無効な購読や誤ったYAMLを修正するものではありません。設定がチェックを通過していない段階で、TUNの有効化を復旧手段にしないでください。反対に、設定は正常なのに一部のアプリだけがプロキシを経由しない場合は、TUNの権限、システムルート、除外項目、アプリ独自のプロキシ設定を確認する方が効果的です。

症状に応じて復旧方法を選ぶ

症状	優先して確認する項目	復旧方法
401、403、またはプラン案内が表示される	購読認証情報とサービス状態	サーバーでURLを再取得し、古い購読項目と置き換える
リクエストがタイムアウトする、またはドメイン名を解決できない	ローカルネットワーク、DNS、システム時刻、プロキシのループバック	時刻を合わせ、ネットワークを切り替え、更新通信の経路を確認する
HTTP 200なのに先頭行の解析に失敗する	レスポンスがHTML、JSON、または空の内容ではないか	サーバー側の入口を修正するか、正しい購読形式を選ぶ
ログにYAMLの行番号が表示される	直前の行のインデント、引用符、リスト、フィールド型	バックアップ後に項目ごとに修正し、設定チェックを繰り返す
インポートに成功したのにノード数がゼロ	providerのURL、形式、プロキシグループの参照	providerを単独で更新し、名前と内容の種類を確認する
更新後も古いノードが表示される	有効な設定、キャッシュインデックス、ディレクトリ権限	購読項目を新規作成し、書き込み時刻を確認してコアを再起動する

復旧手順全体は、まず最初のエラーを読み、次にリクエスト状態を確認する、という順に整理できます。リクエストが成功したらレスポンス内容を判別し、内容が正しければYAMLとコアの互換性を確認します。設定チェックを通過した後にキャッシュと書き込みを確認し、最後にprovider、ルール、DNS、システムプロキシ、TUNを検証します。層ごとに対処すれば有効な設定を残せるうえ、購読サービスの障害時にローカルの利用可能なバージョンを誤って削除することも防げます。