Clash サブスクリプション失効・解析エラーの6つの原因と自己診断手順

サブスクリプション不調はまず症状を見分けることから

サブスクリプション(Subscription)とは、クライアントがサービス提供元から発行されたリンクへ定期的にリクエストを送り、ノード情報を含む設定ファイルを取得してポリシーグループを自動生成する仕組みです。サブスクリプション関連の不具合は、大きく3つの症状に分けられます。1つ目は読み込み時に即座にエラーが出て「解析できません」「フォーマットが不正です」と表示されるケース。2つ目は読み込み自体はできるもののノード数が異常で、更新後に数十個あったノードがゼロや数個まで減ってしまうケース。3つ目は読み込み・ノード表示は正常なのに、接続後にうまく使えないケースです。この3つは原因が完全に異なるため、闇雲にクライアントを再インストールしたり「サブスクリプション更新」を連打しても解決しないことが多く、むしろ本当の原因が見えにくくなってしまいます。以下では、サーバー側からクライアント側にかけて順に、よくある6つの原因とその見分け方を解説します。

原因1・2:リンク期限切れと通信量上限──見落とされがちなサーバー側の問題

サブスクリプションリンクは永久に使える資格情報ではありません。多くのサービス提供元はリンクに有効期限を設定するか、アカウントの契約期限と連動させています。リンクが期限切れになると、サーバーは通常404や403、あるいは空の内容を返し、クライアント側は正常な設定テキストを受け取れないため「解析失敗」というエラーが表示されます。このエラー表示はクライアント自体の不具合と誤解されやすいのですが、実際の原因はサーバー側にあります。確認方法は簡単です。サブスクリプションリンクをそのままブラウザのアドレスバーに貼って開いてみてください。ブラウザでも開けない、あるいは正常なテキストではなく文字化けや空白しか返ってこない場合、リンクが失効している可能性が高く、サービス提供元に連絡して再発行してもらう必要があります。

通信量上限に達した場合の症状はより具体的です。サブスクリプションを更新した途端、ノード数が数十個から数個、あるいはゼロまで一気に減り、同時にクライアントに何らかのメッセージ(サービス提供元によって表現は異なりますが「通信量を使い切りました」「プランの期限が切れました」といった内容が多い)が表示されることがあります。これは、多くのサービス提供元が通信量を使い切った後、サブスクリプションのAPIレスポンスを正常なノードリストではなく単なる案内テキストに置き換えてしまうためです。クライアントはこの案内テキストを設定ファイルとして解析しようとするため、結果として空のリストやエラーになるわけです。サービス提供元のユーザー管理画面にログインして通信量の使用状況を確認するのが、この原因を特定する最も直接的な方法です。

原因3・4:フォーマット非対応とUAブロック──クライアントとサーバーの「素性」が合わない

Clash系の設定ファイルは本質的にYAML形式のテキストで、プロキシノード、ポリシーグループ、ルールの記述方法を定めています。コアによってサポートするフィールドの範囲は完全には一致していません。初期のClash Premium、コミュニティが保守するClash Meta(現在のコア名はmihomo)、各種GUIクライアントに内蔵された解析エンジンでは、新しく追加されたフィールド(一部プロトコルの特殊パラメータやルールセットの記法など)への対応状況がそれぞれ異なります。サブスクリプションの内容に、比較的新しいコアでしか認識できないフィールドが含まれていて、使用中のクライアントのバージョンが古い場合、解析エンジンはそのノード1件だけをスキップするのではなく、ファイル全体を不正なフォーマットと判定してエラーを出すことがあります。この場合の見分け方は、より新しいバージョンのクライアントや別のGUIラッパーで同じサブスクリプションリンクを読み込んでみることです。正常に解析できれば、バージョンの互換性問題である可能性が高く、クライアントを新しいバージョンに更新すれば解決します。

User-Agent(UA)ブロックは見落とされやすい別の原因で、症状がやや特殊です。同じリンクでもブラウザでアクセスすると内容が正常に表示されるのに、クライアントで読み込むとエラーになったり内容がおかしくなったりします。これは、サービス提供元がリクエストヘッダーのUser-Agentフィールドを見てリクエスト元を判別し、クライアントの種類(clash、clash-verge、clash-meta、Shadowrocketなどの識別子)に応じて異なるフォーマットやノード構成を返しているためで、通常は通信量の統計やクライアント専用の最適化を目的としています。サービス提供元側の判定ロジックに問題があったり、サービス提供元がまだ対応していないマイナーなクライアントを使っていたりすると、異常なリクエストと誤判定されてサービスを拒否されたり、不完全な内容が返されたりすることがあります。この場合は、クライアントの設定画面に「User-Agentのカスタマイズ」項目があるか確認し、clashやclash-metaなど汎用的な識別子に変更してから再度サブスクリプションを更新してみてください。

原因5・6:エンコード異常とコア差異──テキストとプロトコル層の互換性問題

サブスクリプションリンクが返す内容は通常Base64でエンコードされており、クライアント側でダウンロード後にデコードしてYAMLやノードリストのテキストに戻し、それを解析しています。サービス提供元が設定ファイルを生成する際に使用した文字エンコードがクライアントの想定と一致しない場合(たとえばUTF-8以外のエンコードでノードの備考が混在している場合など)、デコード後に文字化けが発生することがあります。軽度であればノード名がクエスチョンマークや四角い文字の羅列になるだけですが、重度になると該当行が正規のノードとして認識されずスキップされてしまい、想定よりノード数が少なくなります。この問題を見分ける特徴は「全部ではなく一部のノードだけが消える」ことで、消えるのは名前に特殊記号や非標準文字が含まれるノードが多い傾向があります。自分で確認する際は消えたノードの命名パターンを観察してください。エンコード問題だと確認できても、通常はサービス提供元側の修正を待つしかなく、クライアント側で安定した回避策はありません。

コア差異による問題はフォーマット非対応と似ていますが、症状はより「局所的」です。サブスクリプション全体の解析が失敗するわけではなく、比較的新しいプロトコルやパラメータを使っている一部のノードだけがリストからこっそり消え、残りのノードは正常に表示されます。これは解析エンジンが未知のプロトコル種別やフィールドに遭遇した際、全体の解析を失敗させるのではなく、その1件だけをスキップする仕様になっているためで、動作としてより「見えにくく」、サービス提供元がノードを配布し忘れたと誤解されやすいです。確認方法は、クライアントのコアバージョン番号を確認し、そのコアの更新履歴やプロトコル対応リストと照らし合わせて、該当プロトコルへの対応が始まったバージョンを確認したうえで、クライアントの更新やコアの切り替えが必要かどうかを判断することです。

自己診断手順:10分でサブスクリプション失効の原因を特定する

サブスクリプションに問題が起きた場合、以下の順序でチェックしていけば、上記6つの原因のほとんどのケースをカバーできます。多くの場合、サポートに問い合わせなくても自分でどの層に問題があるかを判断できます。

1. サブスクリプションリンクをそのままコピーしてブラウザのアドレスバーに貼り、開けるかどうか、テキストが返るのかエラーページが返るのかを確認します。まずはリンク自体の失効を除外するステップです。
2. サービス提供元のユーザー管理画面にログインし、現在のプランの通信量使用状況と契約期限を確認して、通信量上限やアカウント期限切れの可能性を除外します。
3. クライアントで現在のコアバージョン番号を確認し、直近半年以内のバージョンかどうかをチェックします。古すぎる場合はまずクライアントを更新してから再テストしてください。
4. クライアントがUser-Agentのカスタマイズに対応している場合、clashやclash-metaなど汎用的な識別子に切り替えてからサブスクリプションを再更新してみてください。
5. 更新前後のノード数の変化を比較します。全部ゼロになった場合は通信量やリンクの問題、一部だけ消えた場合はエンコードやコアの互換性問題を疑ってください。
6. 別のクライアント(特にコアの更新頻度が高いGUIラッパー)で同じリンクを読み込んでみて、結果の違いから問題がサーバー側かクライアント側かを逆算します。

サブスクリプション更新後、設定が本当に反映されているか確認する方法

サブスクリプションの解析にエラーが出ず、ノード数も正常であっても、設定が確実に反映されているとは限りません。一部のクライアントは更新後に新しいポリシーグループを自動で適用しなかったり、古いルールセットのキャッシュがクリアされないままだったりすることがあり、画面上のノードリストは新しくなっているのに、実際の通信は旧設定のまま流れているケースがあります。サブスクリプションを更新するたびに、プロキシモードを一度切り替える(たとえば「ルール」から「グローバル」に切り替えて再度「ルール」に戻す)、あるいはクライアントのサービスを再起動し、これまでアクセスできなかったサイトを実際に開いて動作確認することをおすすめします。ノードリストの数字だけを見て判断しないようにしましょう。