Clash サブスクリプションのリンク失効・解析失敗を調べる方法:返信内容からフォーマット互換まで一つずつ確認
サブスク読込エラーやノード消失の多くはクライアント側の問題ではありません。返信内容・リンク有効期限・フォーマット種別・変換処理の順で確認し、ブラウザとcurlで生データを検証する手順を紹介します。
まず区別すべき2種類の問題:リンク失効と解析失敗
「サブスクに問題がある」という状況には実は2つの異なる現象が含まれており、対処方法は完全に異なります。1つ目はリンク失効です。クライアントがタイムアウト、接続不可、404、あるいは何も内容をダウンロードできないと表示する場合で、この種の問題の根源は通常サーバー側やネットワーク経路にあり、クライアント設定とは無関係です。2つ目は解析失敗です。サブスクはダウンロードできてクライアントも確かにデータを受け取っているのに、インポート後にフォーマットエラー、YAML解析異常が表示されたり、ノードリストが空になったり一部のノードが消えたりする場合です。この種の問題の根源はサブスク内容自体のフォーマットにあることが多く、リンクが到達可能かどうかとは別問題です。
この2種類の問題を混同することが、調査が遠回りになる主な原因です。多くの人はクライアントのエラーを見ただけで再インストールやコア切り替えに走りますが、実際には先に2分ほどかけてサブスクの生の返信内容を確認するだけで、半分以上の調査方向を排除できます。
ステップ1:ブラウザとcurlでサブスクの生の返信内容を直接確認する
クライアントはサブスク内容の受け手にすぎず、サーバー側が実際に何を返したのかは教えてくれません。問題がどの層にあるかを判断するには、まずクライアントを経由せず、サブスクリンク自体が何を返しているかを直接確認することが常に第一歩です。
最も簡単な方法は、サブスクリンクをブラウザのアドレスバーに貼り付けて直接アクセスすることです。ブラウザがダウンロードダイアログを出したりテキストを表示したりしたら、内容を開いて確認します:
proxies:、proxy-groups:で始まるテキストが見えたら、これは標準的なClash YAML設定であり、フォーマット自体に問題はありません。vmess://、ss://、trojan://で始まり改行やBase64で連結された長い文字列が見えたら、これは汎用サブスクフォーマット(いわゆるBase64サブスク)で、クライアントや変換サービスによる追加処理が必要になります。- HTMLページやエラーメッセージ、あるいは「ログイン期限切れ」「トラフィック使い切り」といった文言が表示される場合、問題はサーバー側にあり、クライアント設定とは無関係です。
- ブラウザが直接アクセス不可、接続タイムアウトと表示する場合、リンク自体が失効しているかネットワーク接続性に問題があります。
ブラウザ方式はアドレスバーが一部の文字エンコーディングを一貫して処理しない場合があるため、より厳密な方法はcurlコマンドで直接取得することです。コマンドラインの結果はブラウザのキャッシュや拡張機能に影響されず、サブスクが正常かどうかを判断する最も確実な手段です。
curl -v -o subscription.txt "あなたのサブスクリンク"-vパラメータを付けると、DNS解決、TLSハンドシェイク、HTTPステータスコードを含むリクエストの全過程を確認できます。返信されたステータスコードに注目してください:
200:リクエスト成功、内容はsubscription.txtに保存されるので、テキストエディタで開いて内容を確認します。401/403:認証失敗または権限不足で、リンク内のtokenパラメータが失効している場合によく見られます。404:リンクが指すリソースが存在せず、通常はサブスクアドレスが削除された、またはパスの記述ミスです。429:リクエストが頻繁すぎてレート制限されているので、数分待って再試行し、短時間で手動更新を繰り返さないでください。5xx:サーバー側自体のエラーであり、クライアントやローカルネットワークとは無関係で、サーバー側の復旧を待つしかありません。
curlリクエストにクライアント専用のUser-Agentを付けないと完全なノードが取得できない場合(一部のサービス提供者はUser-Agentによって返す内容を変えており、例えばClashクライアントと認識した場合のみノード情報を返し、それ以外は案内文言を返すことがあります)、明示的に指定できます:
curl -v -A "clash-verge/v2" -o subscription.txt "あなたのサブスクリンク"User-Agentを実際に使用しているクライアントの識別子に変更してから返信内容を再度比較し、今回は完全なノードが取得できてデフォルトのUser-Agentでは取得できなかった場合、サブスクサービス自体にUA許可リスト機能があることを示しており、これは正常な挙動で故障ではありません。
ステップ2:リンクの有効期限とトラフィック・デバイス数の制限を確認する
サブスクの返信内容が確かに異常であることを確認したら、次は有効期限と制限の問題を調査します。この種の制限は通常返信内容に直接記載されていますが、見落とされやすいものです:
- 有効期限:多くのサービス提供者はHTTPレスポンスヘッダーに
Subscription-Userinfoフィールドを含めており、expire(有効期限のタイムスタンプ)、total(総トラフィック)、upload/download(使用済みトラフィック)が入っています。curl -vを使うとこのレスポンスヘッダーが出力に表示され、有効期限と残りトラフィックを直接読み取れます。 - トラフィック使い切り:
upload+downloadがtotalに近づくか超えている場合、リンク自体はアクセス可能でも、サーバー側が能動的に空のノードリストや案内文言を返すことがあり、クライアントが「ノード0件」を解析するのは正常な現象で、解析エラーではありません。 - デバイス数制限:一部のサービス提供者は同一アカウントで紐付けられるデバイス数や同時接続数を制限しており、超過すると新規デバイスからのサブスクリクエストが拒否されたり簡易版のノードが返されたりします。最近デバイスを追加した、またはクライアントを変更した場合は、他のデバイスでサブスクを無効化してから再試行してみてください。
- IPまたは地域制限:少数のサブスクサービスはリクエスト元のIPに許可リストや地域制限を設けており、ネットワーク環境を変更した後(例えば会社のネットワークから自宅のネットワークに切り替えた場合)にサブスクが突然更新できなくなった場合、この種の制限が疑われます。
ステップ3:サブスクのフォーマット種別とクライアントの互換性を確認する
サーバー側の返信異常やアカウント制限を除外した後、サブスク内容自体は正常にダウンロードできるのにクライアントへのインポート時にエラーが出る場合、問題の大半はフォーマット互換にあります。よく見られるサブスクフォーマットは1種類だけではありません:
- 標準Clash / Clash Meta(mihomo)YAML:
proxies、proxy-groups、rulesを主なフィールドとする完全な設定ファイルで、クライアントは直接使用できます。フィールド間のインデントとコロン後の空白には厳密なルールがあり、手動編集時に最もミスしやすい部分です。 - Base64エンコードの汎用サブスク:内容は多数のプロトコルリンク(
vmess://、ss://、trojan://、hysteria2://など)がBase64エンコードで連結されたもので、直接Clash設定として使うことはできず、まずデコードしてYAML構造に変換する必要があります。Clash Metaコアをサポートする多くのクライアントには既にこの変換ロジックが内蔵されていますが、クライアントのバージョンが古い場合、hysteria2、tuicなどの新しいプロトコルを認識できず、インポート時に「未知のプロトコルタイプ」と表示されたり、そのノードがスキップされたりすることがあります。 - 特定パネル独自のフォーマット:一部のサブスクパネルは標準フィールドの他に独自パラメータを追加していることがあり、古いバージョンのクライアントが認識できないフィールドに遭遇した場合、単に無視するものもあれば、厳格モードでエラーになり中断するものもあります。
プロトコル互換性の問題かどうかを判断するには、エラー情報に具体的なフィールド名やプロトコル名が言及されているかを確認します。例えばunsupported typeや、あるフィールドが認識できないという表示です。この場合、まずクライアントが使用しているコアのバージョンを確認し、次にサブスクで使われているプロトコルがそのバージョンのサポートリストに含まれているかを確認します。多くの場合はクライアントを最新版にアップデートすれば解決します。新しいプロトコルへの対応は継続的に追加されているためです。
ステップ4:変換処理が原因の解析異常を調査する
多くのサブスクリンクは実際には「サブスク変換」サービスを経由しています。元のノード情報が変換サービスに読み取られ、Clashフォーマットで再生成された設定がクライアントに返される仕組みです。この変換の層自体もエラーを起こす可能性があり、よくあるケースは以下の通りです:
- 変換サービスが一時的に不調で、返されるYAML内容が不完全または途中で切れており、クライアントがファイル末尾の閉じ構造の欠落を検出してエラーになる。
- 変換ルールのテンプレート自体に誤りがある。例えばポリシーグループが存在しないノード名を参照している場合、YAML構文上は問題なくても、クライアントがポリシーグループを読み込む際に対応するノードが見つからずエラーになったり、そのポリシーグループが空になったりします。
- 変換サービスが特殊文字の処理を誤り、ノード名に含まれる絵文字、縦線、コロンなどの記号が変換後にYAML構造の整合性を破壊する。
この種の問題を調査するには、curlで取得した生の内容を丸ごと確認するのが最も直接的な方法です。ファイル末尾が完全かどうか、インデントが一貫しているかどうか、明らかな文字化けや途切れがないかを重点的に確認します。内容が確かに不完全だと分かった場合、基本的に変換サービスまたは元のサーバー側の問題であり、ローカルのクライアント設定とは無関係です。サブスク提供元に連絡するか修正を待つほかなく、ローカルでできることは前回正常に読み込めた過去の設定を一時的に使用することだけです。
クライアントが過去のサブスクキャッシュの保持をサポートしている場合(多くの主流クライアントにはこの仕組みがあります)、更新に失敗すると自動的に前回成功した設定にロールバックし、プロキシが即座に使えなくなることはありません。これが「サブスク更新」のエラーが既存のプロキシの即時無効化を意味しない理由であり、慌てて更新を繰り返し試す必要はありません。
よくあるエラー表示の対照表
クライアントでよく見られるサブスクのエラー表示と対応する調査方向を整理しました。表示されるキーワードから問題の範囲を素早く特定できます:
- timeout / 接続タイムアウト:まずcurlでリンク単独の到達可能性をテストします。多くはネットワーク経路やサーバー側の問題で、フォーマットの問題ではありません。
- yaml: line X: mapping values are not allowed:典型的なインデントやコロン後の空白不足の問題で、設定を手動編集した場合や変換サービスのテンプレートに誤りがある場合によく見られます。
- proxy group xxx not found:ポリシーグループが存在しないノードやグループ名を参照している状態で、通常は変換テンプレートの設定ミスなので、サブスク提供元に連絡して対処してもらいます。
- unsupported proxy type:クライアントのコアがサブスク内のプロトコルタイプを認識できない状態です。クライアントのバージョンをアップデートするか、プロトコルの記述が正しいか確認します。
- empty proxies list / ノード数が0:まずトラフィック使い切りやアカウント状態の異常を確認し、次にサブスクリンクが制限されて空リストを返しているか確認します。
この対照表とcurlによる確認を組み合わせて使えば、サブスク関連の問題のほとんどのシナリオをカバーできます。核心となる考え方は常に同じで、まずサーバー側が何を返したかを確認し、それが内容の問題かクライアント互換性の問題かを判断し、最後にローカル設定の調整が必要かどうかを検討します。この順序で調査すれば、クライアント設定での無意味な試行錯誤を避けられます。