Clash サブスク解析失敗・ノード空リストの原因と自己診断チェックリスト

まず問題の種類を切り分ける:導入エラーかノード一覧の空白か

サブスク関連の不具合は大きく2種類に分かれ、原因を調べる方向はまったく異なる。1つ目はクライアントがサブスクを導入する際に直接エラーを表示するケースで、「サブスクのダウンロードに失敗しました」「サブスクの解析に失敗しました」「URLが無効です」といった文言が典型例だ。これはクライアントがサブスクリンクへリクエストを送り、内容を受け取る前後の段階で起きている。2つ目は導入時にエラーが出ず、クライアント側も「サブスク更新成功」と表示するのに、プロキシグループやノード一覧が空のままというケースで、これは内容自体は取得できているのに、パーサーが中から有効なノード情報を認識できていないという状態だ。

この2種類を分けて考えることが重要になる。前者はネットワークリクエストとリンク自体を、後者は取得した内容のフォーマットとフィールド構造を優先して調べるべきだ。以下では外側から内側へ向かう順番で5段階の自己診断チェックリストを示すので、順番通りに1つずつ潰していくことをおすすめする。

ステップ1:サブスクリンク自体が完全で有効かを確認する

多くのサブスクの不具合は、実はリンク自体に問題があるという単純な原因に行き着く。以下の項目を1つずつ確認しよう。

• リンクを完全にコピーできているか。サブスクリンクは長く、長いトークンのパラメータが付いていることが多いため、手動コピーだと末尾の文字が欠けたり、余分な空白や改行が混ざったりしやすい。提供元が用意している「ワンクリック導入」や「リンクをコピー」ボタンを使い、手動選択は避けたほうがよい。
• リンクのプロトコルがクライアントの要求と一致しているか。Clash系クライアントでは通常、サブスクリンクは http:// または https:// から始まる必要がある。提供元が clash://install-config?url=... のような呼び出しリンクを渡してきた場合は、そこから本来の url パラメータの値を取り出して個別に導入する必要があり、まるごと貼り付けてはいけない。
• リンクが期限切れ、または無効化されていないか。一部のサブスクサービスでは、利用者が端末を変更したり鍵をリセットしたりすると旧リンクが失効する。この場合、旧リンクは見た目上は「正常」に見えても、サーバー側は応答を拒否するか空の内容を返す。
• ローカルのネットワーク環境からそのリンクへ直接アクセスできるか。サブスクのドメイン自体がプロキシ経由でしかアクセスできない環境にあり、その時点でクライアントがまだどのノードにも接続できていない場合、「プロキシがないとサブスクを取得できず、サブスクがないとプロキシを確立できない」という堂々巡りが発生する。この場合は一時的にシステムプロキシを無効化するか、直接接続モードで初回のサブスク取得を済ませる必要がある。

ステップ2:サブスクが返す内容のフォーマットを確認する

リンクにアクセスできることを確認したら、次はサーバーが返す内容のフォーマットをクライアントが正しく認識できているかを確認する。Clash と Clash Meta(mihomo)がサポートするサブスクの返信形式は主に2種類あり、1つは標準的な proxies フィールドを持つ YAML 設定、もう1つは Base64 エンコードされたノード一覧(古いクライアントとの互換を目的とした汎用サブスク形式でよく見られる)だ。返信内容のフォーマットがクライアントの解析想定と一致していない場合、「ダウンロードは成功したのにノードが空」という典型的な現象が起きる。

コマンドラインツールでサブスクが返す元の内容を直接確認し、フォーマットが正常かどうかを素早く判断できる。

ダウンロードが完了したら sub-raw.txt を開き、次の点を重点的に確認する。

1. ファイルが正しい YAML になっているか、proxies: フィールドが含まれているか、インデントが統一されているか(YAML はインデントに非常に敏感で、タブとスペースが混在すると解析がそこで止まる)。
2. 内容が一見ランダムに見える長い文字列であれば、Base64 エンコードの可能性が高い。クライアントが自動識別・デコードに対応している必要があり、対応していない旧バージョンではやはりノードが空という結果になる。
3. 返信内容が実は HTML ページ(ログインページ、エラーページ、トラフィック超過の案内ページなど)になっていないか。この場合、リクエストは本来のサブスクデータを取得できず、サーバー側によって案内ページへリダイレクトされている状態であり、クライアントは当然 HTML からノードを解析できない。

ステップ3:トラフィックと有効期限が切れていないかを確認する

多くのサブスクサービスは、トラフィックまたは期限が切れた際にエラーを直接返すのではなく、空のノード一覧を返したり、応答を案内ページへリダイレクトしたりする。これは「クライアントには更新成功と表示されるのにノードがない」という現象の最も一般的な原因の1つだ。確認方法は2つある。

• サブスク提供元のパネルまたはクライアント専用ページにログインし、残りトラフィックと有効期限を直接確認する。これが最も直接的で確実な方法だ。
• サブスクの応答ヘッダーにある Subscription-Userinfo フィールドを確認する。このフィールドには通常 upload、download、total、expire(単位はバイトと Unix タイムスタンプ)の値が含まれ、一部のクライアントではこれらをサブスク詳細画面に直接表示する。upload + download が total に近づくか超えている、あるいは expire が現在時刻より前であれば、トラフィックまたは有効期限の問題だと確定でき、クライアント設定の問題ではないと判断できる。

この段階での確認には、クライアントの再インストールや設定の再導入を繰り返して時間を浪費しないという意味がある。サブスク自体が未払いや期限切れであれば、どのようなクライアント設定を行ってもノードは再表示されない。

ステップ4:User-Agent とリクエストヘッダーの制限を確認する

一部のサブスクサービスは、リクエストヘッダーの User-Agent(UA)からリクエストの発信元を判断し、「正規クライアント」と識別された UA にのみ完全なノード一覧を返し、ブラウザの UA や未知の UA には簡略化した案内、空リスト、あるいはアクセス拒否を返すことがある。これはサブスクリンクが不特定多数に取得・転送されるのを防ぐための一般的な手法だ。これによって、次のような現象がよく起こる説明もつく。同じサブスクリンクをブラウザで直接開くと内容が異常または空なのに、クライアントで導入すると正常にノードが取得できる、という現象だ。原因はクライアントがリクエストを送る際に付与する UA がブラウザとは異なるためだ。

UA 制限が原因ではないかと疑う場合、次の方法で確認できる。

1. クライアントのサブスクリクエストの UA が、そのサブスク提供元のドキュメントに記載されている対応 UA になっているかを確認する(クライアントごとにデフォルト UA が異なり、例えば Clash Verge、Clash for Windows、mihomo カーネルではそれぞれのデフォルト識別子が完全には一致しないことがある)。
2. クライアントがサブスクリクエストの UA をカスタマイズできる場合(一部のクライアントはサブスク詳細画面にこのオプションを用意している)、提供元のドキュメントで推奨されている UA 文字列に変更して試す。
3. カスタム UA パラメータを付けたコマンドラインリクエスト(前述の curl -A の例など)で、異なる UA ごとの返信結果をそれぞれテストして比較すれば、UA 制限があるかどうかを確認できる。

ステップ5:クライアントのバージョンとプロトコル対応範囲を確認する

サブスクの返信フォーマットが正しく、トラフィックと有効期限も正常、UA も制限されていないのに、それでもノードが空だったり一部のノードが欠けたりすることがある。この場合、問題はクライアントのバージョンとプロトコル対応範囲にあることが多い。よくあるケースは次のとおりだ。

• サブスクに比較的新しいプロキシプロトコル(一部の新しいカーネルバージョンでのみサポートされるトランスポート層の機能など)が含まれているのに、現在使用しているクライアントのカーネルが古く、該当プロトコルのノードを解析する際にエラーを出さずに黙ってスキップしてしまう。その結果、ノード一覧が「一部だけ減っている」状態になり、気付きにくい。
• サブスクでカスタムの proxy-groups のポリシーグループタイプや rule-providers のリモートルールセットの書式が使われているのに、旧バージョンのクライアントのパーサーが対応するフィールドを認識できず、解析段階全体が失敗する。
• クライアントで選択しているカーネルの種類がサブスクの要求と合っていない。例えば一部の高度な機能(より完全なルール構文、一部の新しいプロトコルなど)は Clash Meta(mihomo)カーネルでのみサポートされており、クライアントが古い純正 Clash カーネルのままだと、サブスクの内容自体に問題がなくても解析異常やノード欠落が起こる。

このような状況に遭遇したら、まず次の2点を優先して行う。1つはクライアントとその内蔵カーネルを比較的新しい安定版へ更新すること。もう1つはサブスク提供元のドキュメントを確認し、そのサブスクが特定のカーネルやクライアントバージョンを明確に要求していないかを調べ、自分が使っているクライアントと1つずつ照らし合わせることだ。

どのような場合にクライアントの調査を続けず提供元へ連絡すべきか

以上の5段階の自己診断はクライアント側で解決できるほとんどのケースを網羅している。しかし、そもそもクライアント側の問題ではなく、これ以上ローカルで調査を続けても意味がなく、直接サブスク提供元へ連絡すべきケースもある。

1. パネルにログインしてアカウントのトラフィックと有効期限がいずれも正常であることを確認済みなのに、サブスクリンクが依然として空の内容やエラーページを返し、長時間にわたって回復しない。
2. 同じサブスクリンクを異なるネットワーク環境、異なるクライアント、異なる UA のすべてで試してもノード情報を一切取得できず、ローカル環境の要因はほぼ排除できている。
3. サブスクのパネル自体でノードのメンテナンス、経路の調整、サービス移行などの告知が表示されている。この場合は通常、提供元の復旧を待つか、告知に従って新しいサブスクリンクへ切り替える必要がある。
4. アカウントが誤って異常な挙動と判定されアクセス制限をかけられていると疑われる場合は、提供元の公式サポート窓口を通じて状況を説明すべきで、クライアント側で何度もリトライを続けるのは避けたほうがよい。

まずクライアント側で自己診断できる項目をすべて潰しておいてから提供元へ連絡すると、やり取りがより効率的になる。リンクの完全性、返信フォーマット、トラフィック状況、UA、クライアントバージョンについて既に確認済みであることを明確に伝えれば、通常は基本情報を何度も確認し合う必要がなくなり、相手が問題箇所をより早く特定する助けになる。