Clash サブスクリプションリンクが失効した場合の対処法:解析失敗と更新不可の完全チェックリスト
サブスク導入エラーや更新後ノード空白の原因は、リンク期限切れ・サーバー返却形式・User-Agent制限・ローカルネットワークの4種類が中心。診断順に手順を解説します。
サブスクリプションリンクの仕組みとよくあるエラーの種類
Clash系クライアント(オリジナルのClash、Clash Meta、そのコアであるmihomoを含む)のサブスクリプション機能は、本質的にはクライアントが定期的にサブスクリプションリンクへHTTP(S) GETリクエストを送り、サーバー側が設定テキストまたはBase64エンコードされたノードリストを返し、クライアント側がレスポンスを受け取ったあとproxies、proxy-groups、rulesなどの構造に解析してローカルキャッシュファイルに書き込む、という流れです。この一連の経路には、サブスクリプションサーバー、伝送経路(ローカルネットワークとDNS)、クライアント側の解析処理という3つの当事者が関わります。どの段階に問題があっても「導入失敗」や「更新後ノードが空になる」という症状として現れますが、原因はまったく異なるため、闇雲にクライアントを再インストールしたり更新ボタンを連打したりしても解決しないことがほとんどです。
よくあるエラーは4種類に分類できます。1つ目は導入時に直接「解析失敗」や「フォーマットエラー」と表示されるケース。2つ目はサブスクリプション自体は導入できるが、更新時にタイムアウトや接続拒否が表示されるケース。3つ目は更新が「成功」した(エラーポップアップが出ない)にもかかわらず、ノードリストが空になったり古いデータのまま変わらないケース。4つ目は一部のノードは接続できて一部だけエラーになるケースで、これは通常フォーマットの問題ではなくノード自体の失効が原因です。本記事は外側から内側へという診断順序に沿って、リンク自体、サーバー返却内容、リクエストヘッダー制限、ローカルネットワークとクライアント設定という4つの段階を順に確認していきます。読者はこの順に一つずつ切り分けていくことができます。
ステップ1:リンク自体の期限切れや帯域制限を確認する
これは最もよくある原因であり、最も見落とされやすい原因でもあります。ほとんどの提供元(サブスクリプションサービス業者)のリンクには有効期限やトラフィックリセット周期が設定されており、期限を過ぎるとリンク自体は「存在」していてもサーバー側がエラーページや空の内容を返すため、クライアントが予期しない形式のレスポンスを受け取り、当然解析に失敗します。確認方法は以下のとおりです。
- ブラウザで直接サブスクリプションリンクを開く
サブスクリプションアドレスをブラウザのアドレスバーに貼り付けてアクセスします。ログインページ、エラー表示、プラン期限切れの文言が表示された場合は、問題はサーバー側のアカウント状態にあり、クライアント側とは無関係です。Clash自体を調べるのではなく、提供元に連絡して対応や更新手続きを行う必要があります。
- レスポンスが空または長さが異常でないか確認する
正常なサブスクリプションのレスポンスは通常数百バイトから数十KBのテキストです。ブラウザで開いて真っ白だったり、バイト数が極端に小さい(数十バイト以内)場合は、ほとんどの場合アカウントのトラフィック消費、またはリンクがサーバー側からすでに無効化されたことが原因です。
- リンクが途中で切れていたり余分な文字が含まれていないか確認する
グループやチャットソフトからリンクをコピーする際、末尾に余分なスペースや改行が入ったり、自動的に短縮URLに変換されたりすることがあります。プレーンテキストエディタに一度貼り付けて、プロトコル部分(http/https)、ドメイン名、パスパラメータが完全かどうかを目視で確認し、それからクライアントにコピーすることをお勧めします。
- サブスクリプションにアクセス頻度制限がないか確認する
一部の提供元は同一サブスクリプションリンクに最短更新間隔(例:1時間に1回のみ取得可能)を設定しています。短時間に「サブスクリプション更新」を連打すると異常なリクエストと判定されて拒否されることがあります。10〜15分程度間隔を空けて再試行すればこの原因は排除できます。
ステップ2:サーバー返却フォーマットの問題を調べる
リンクが正常にアクセスでき、返却内容も空ではないのに、クライアントがまだ解析失敗と表示する場合、問題は通常返却内容のフォーマットがクライアントの想定と一致していないことにあります。Clashは2種類のサブスクリプション形式をサポートしています。1つは標準的なYAML設定(proxies:、proxy-groups:、rules:などのフィールドから始まる完全な設定ファイル)、もう1つはBase64エンコードされたノードリスト(Shadowsocks/Vmessシェアリンクの一括パッケージによく見られる形式)で、後者はクライアントまたはサブスクリプション変換サービスによってデコードしプロトコルフィールドに復元する必要があります。
判定方法は、サブスクリプションの内容全体をコピーして先頭の文字を観察することです。規則性のない英数字の混合(典型的なBase64の特徴)が表示された場合、オリジナルのClashやストリクトモードのClash Metaを使用していて提供元が変換パラメータを提供していないと、クライアントはそのままYAMLとして解析しようとしてエラーになります。この場合、通常はサブスクリプションアドレスの末尾に目標フォーマットのパラメータを追加する必要があります(パネルによってパラメータ名は異なり、よくある例として&target=clashや&flag=metaなど)。詳細は提供元のドキュメントを確認してください。提供元にこの種のパラメータがない場合は、サブスクリプション変換サービスを利用してClash用のフォーマットを生成してから導入することもできます。
もう1つのフォーマット問題はYAMLのインデントやフィールドエラーです。一部の提供元は設定に手動でカスタムルールやDNSセクションを追加していますが、インデントの階層が正しくない(タブとスペースが混在している、リスト項目のインデントが不揃いなど)場合、Clash Metaのパーサーが特定のフィールドでエラーを出して導入を中止します。この種の問題はクライアント側で自動修正できないため、提供元に連絡して元のファイルを修正してもらう必要があります。応急的な対応としては、カスタムルール部分を一旦削除してproxiesセクションだけを残して導入できるかテストし、どのフィールドが問題を起こしているかを特定する方法があります。
注意 NOTICE
ブラウザではサブスクリプション内容が正常に表示されるのにクライアントで解析失敗になる場合、大半はフォーマットの不一致(Base64ノードパッケージ vs YAML設定)が原因で、リンク失効ではありません。サブスクリプションを何度も更新するのではなく、まず目標フォーマットのパラメータが正しいか確認してください。
ステップ3:User-Agentとリクエストヘッダー制限を確認する
一部のサブスクリプション提供元はリクエストヘッダー内のUser-Agentフィールドに基づいてクライアントの種類を判定し、それに応じて異なるノード数や設定内容を返します(例:Clash、Surge、Shadowrocketなどを区別する)。サーバーが特定のUser-Agentホワイトリストのみを認識し、クライアントが送るリクエストヘッダーがそのホワイトリストに含まれていない場合、サーバーは簡易版の内容やエラーページを返す、あるいは接続を直接拒否することがあり、「更新後ノードが減った」「更新に失敗した」という症状として現れます。
オリジナルのClashクライアントとClash Meta/mihomoコアが送るデフォルトのUser-Agent文字列は完全には一致しておらず、クライアントのバージョンをアップグレードするとこの文字列が変わることもあります。これが一部のユーザーで「クライアントを更新したらサブスクリプションが突然おかしくなった」という現象の直接的な原因です。確認手順は以下のとおりです。
- クライアントがカスタムUser-Agentに対応しているか確認する
多くのClash Metaグラフィカルクライアントは、サブスクリプション設定内にUser-Agentをカスタム入力できる欄を用意しています。提供元が要求する文字列(例えば
clash-vergeを装う、または特定のバージョン番号形式を指定する)を手動で入力し、入力後に再度更新をテストしてください。 - アンチリーチまたはレート制限に引っかかっていないか確認する
一部のサブスクリプションパネルは、通常とは異なるUser-Agentや高頻度リクエストに対してアンチリーチ機構を作動させ、403ステータスコードを返すことがあります。この種の状況はクライアント側の画面上には通常「更新失敗」としか表示されず、具体的な原因は説明されないため、提供元のバックエンドログやサポートへの問い合わせで確認する必要があります。
- 中間のプロキシノードによってリクエストヘッダーが改変されていないか確認する
ローカル環境がすでに何らかの上位プロキシや企業ゲートウェイの背後にある場合、送信されるリクエストヘッダーがゲートウェイによって書き換えられたり削除されたりして、サブスクリプションサーバーに到達する時点でUser-Agentがすでに変化していることがあります。システムプロキシを一時的にオフにするか、プロキシのないネットワーク環境に切り替えて直接サブスクリプションを更新し、比較テストを行うことができます。
ステップ4:ローカルネットワークとクライアント設定を確認する
前の3つのステップをすべて確認して問題がなかったにもかかわらずサブスクリプションの更新が依然失敗する場合、問題の範囲はローカルネットワーク環境とクライアント自身の設定に絞られます。この種の原因として最もよくあるのは3つです。DNS解析の異常、システムプロキシとサブスクリプション更新リクエストの相互干渉、TUNモードでのルーティング乗っ取りです。
DNS解析異常とは、ローカル環境がサブスクリプションのドメイン名を正常に解析できない状態を指します。特にカスタムDNSサーバーへ変更した場合、何らかのDNS広告フィルタリングルールを有効にした場合、あるいはルーター側でドメイン名の乗っ取りが発生している場合、クライアントが送る更新リクエストはドメイン名解析の段階で失敗し、エラーは通常「フォーマットエラー」ではなく「接続タイムアウト」として表示されます。システム標準のドメイン名クエリツールを使ってそのドメインが正常にIPへ解析できるかテストし、異常があればパブリックDNSに切り替えたり、クライアントのDNS設定でサブスクリプションドメインだけ個別に解析方式を指定してみてください。
システムプロキシの競合はWindowsとmacOSでよく見られます。サブスクリプション更新リクエスト自体がクライアント自身のプロキシルールに捕捉されて転送されてしまい、「プロキシを使ってプロキシ設定を更新する」という循環的な判定エラーが発生することがあります。一部のバージョンではルールグループの判定順序の問題により、更新リクエストが利用不可のノード経由になってしまいタイムアウトすることもあります。クライアント設定内にサブスクリプション更新リクエスト専用の直接接続許可ルールがあるか確認するか、システムプロキシを一時的にオフにして手動でサブスクリプションを更新してテストすることをお勧めします。
TUNモードではこの問題がさらに複雑になります。TUNはシステム層のグローバルなトラフィックルーティングを引き継ぐため、ルール設定が不適切だと、サブスクリプション更新のようなクライアント自身が発する管理リクエストも誤ってプロキシチェーンにルーティングされてしまうことがあります。確認方法はTUNモードを一時的にオフにし、システムプロキシモードのみで更新が成功するかテストすることです。TUNをオフにすると正常に戻る場合、TUNモードの例外ルール(process-nameやローカルプロセスの直接接続ホワイトリストなど)にクライアント自身の設定漏れがないか確認する必要があります。
更新プロセスに関わる4つの段階——リンクの有効性、サーバーフォーマット、リクエストヘッダー制限、ローカルネットワーク——は互いに独立しています。この順序に従って一つずつ確認し、複数の設定を同時に変更しないことをお勧めします。同時に変更すると本当の原因を特定しづらくなります。
診断順序のまとめと予防策
以上の4ステップをつなげると、完全な診断順序は次のようになります。まずブラウザで直接サブスクリプションリンクにアクセスしてサーバー側のアカウント状態が正常かを確認し、次に返却内容がYAMLかBase64かを確認して現在のクライアントに合ったフォーマットパラメータかどうかを判断し、続いてUser-Agentホワイトリスト制限がないかを確認して必要であればリクエストヘッダーをカスタマイズし、最後にローカルDNS、システムプロキシ、TUN例外ルールなどローカル環境の要因を確認する、という順序です。この順序は「問題が発生する確率が高い順」に並べられており、無駄な確認作業を大幅に減らすことができます。
サブスクリプション失効による影響を減らすために、次の3つの習慣をつけることをお勧めします。1つ目は、サブスクリプションが完全に失効するまで待たずに確認すること。ほとんどの提供元は期限が切れる前にパネル上に残り日数やトラフィックを表示するので、定期的に確認しておけば事前に対応できます。2つ目は、ローカルにエクスポートした過去の設定を予備として保存しておくこと。サブスクリプション更新に失敗しても、問題が解決するまで古い設定で使い続けられます。3つ目は、現在使用しているクライアントのバージョンとコアのバージョンを記録しておくこと(Clash Meta/mihomoは更新頻度が高く、バージョンによってフィールドの解析の厳密さが異なります)。問題が発生した際は更新履歴を確認し、既知の解析仕様変更かどうかを確認することで、すでに報告済みの問題を重複して調査する手間を省けます。