ClashのサブスクリプションURLが無効・設定の解析に失敗する原因と確認手順

FAILURE LAYERS

ダウンロード失敗・変換失敗・設定読み込み失敗をまず切り分ける

「サブスクリプションの取得に失敗した」という表示は、単一の障害を意味するわけではありません。クライアントがサブスクリプションURLから設定を取得して適用するまでには、少なくともネットワーク通信、サーバーのレスポンス、内容の判定、YAML解析、フィールド検証、コアによる読み込みという段階があります。段階が違っても似たエラーが表示されることがありますが、対処法はまったく異なります。更新を何度も繰り返しても、通常は同じエラーを再現するだけです。

1つ目はダウンロード失敗です。クライアントが有効なレスポンスを取得できていない状態で、リクエストのタイムアウト、接続リセット、DNS解決失敗、HTTP 401、403、404、429、5xxなどが該当します。この段階ではまだYAML解析に進んでいないため、ローカル設定のインデントを直しても効果はありません。

2つ目はレスポンス内容が想定と異なるケースです。リクエスト自体は成功していても、本文がログインページ、アクセス認証ページ、プランの期限切れ案内、JSON形式のエラーオブジェクト、またはノードURIだけのテキストになっていることがあります。ブラウザでURLを開けても、ブラウザが何らかのレスポンスを受け取れたことしか分かりません。その内容が現在のクライアントで読み込めるClash設定だとは限りません。

3つ目は構文またはフィールドの解析失敗です。サーバーはYAMLを返しているものの、インデント、コロン、引用符、リストの階層、文字コードなどに問題がある状態です。また、現在のコアが認識できないフィールドを含んでいる場合もあります。ログには通常、YAML、unmarshal、decode、field、proxy、ruleなどのキーワードが現れます。

4つ目は読み込み後に利用できないケースです。サブスクリプションは設定一覧に追加され、ノード名も表示されるのに、設定の有効化に失敗したり、有効化後も接続できなかったりします。これは通常、ポリシーグループの不足、ルール参照エラー、プロキシプロトコルのパラメータ不足、DNS設定の競合、コアのバージョン差異などが原因です。「リンクを開けない」問題として調べ続けるべきではありません。

URL STATUS

サブスクリプションURLの状態とリクエスト条件を確認する

サブスクリプションURLには、アカウントや認証範囲を識別するクエリパラメータが含まれていることが一般的です。コピーする際に疑問符以降のパラメータを落としたり、接続部分を途中で切ったり、改行を混入させたりすると、サーバーから正しい結果が返りません。確認時はサービス提供元のサブスクリプション管理ページから完全なURLを再コピーしてください。手入力で組み立てたり、チャット履歴から一部だけ選択して使い続けたりしないでください。

URLが途中で切れたり変換されたりしていないか確認する

URLが http:// または https:// で始まっているか、ドメイン名とパスが完全かを確認します。
クエリパラメータが残っているか、特に疑問符、イコール、接続記号、パラメータ値末尾の文字を確認します。
QRコードの読み取りや端末間のコピーを行った場合は、URLの途中にスペース、日本語の句読点、改行が入っていないか確認します。
URLをYAMLの文字列に含める場合、特殊文字があるときは引用符で囲み、コメントや構文記号として解釈されないようにします。

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

401 / 403: 認証パラメータが無効、リクエスト条件を満たしていない、またはサーバーにアクセスを拒否されています。サブスクリプションURLを再取得し、アカウントの状態とサービス側の制限を確認してください。
404 / 410: パスが存在しないか、リソースがすでに無効化されています。古いURLはサーバー側で変更されている可能性があり、ローカルキャッシュを更新し続けても復旧しません。
429: 短時間に更新を繰り返しすぎています。連続更新を停止し、制限時間が過ぎてから1回だけテストしてください。
5xx: サーバーが一時的にリクエストを処理できない状態です。エラーが発生した時刻とステータスコードを控え、時間を置いて再試行するか、サブスクリプション提供元に連絡してください。

タイムアウトやDNS解決失敗の場合は、現在の基礎ネットワークも確認します。テスト時はいったんシステムプロキシとTUNを無効にしてからサブスクリプションのドメインへアクセスし、更新処理がまだ起動していないプロキシに誤って依存していないかを確認します。一部のクライアントでは、設定更新にDIRECTまたはプロキシのポリシーを指定できます。現在のネットワークからサブスクリプションドメインへ直接接続できない場合は、更新通信の経路を明示し、「設定を読み込むにはサブスクリプションへアクセスする必要があるが、サブスクリプションへアクセスするには設定を読み込む必要がある」という循環を避けてください。

RESPONSE BODY

レスポンス本文が本当にClash設定かを確認する

HTTP 200はサーバーがリクエストを処理したことを示すだけで、本文の形式が正しいことを意味しません。典型的なのは、サブスクリプションURLがログインページやアクセス認証ページへリダイレクトされ、クライアントがHTMLを受け取るケースです。その後、パーサーは先頭行の <!doctype html>、<html>、その他のタグ付近でエラーを出すことがあります。

完全なClash設定は通常YAMLテキストで、トップレベルには proxies、proxy-groups、rules、dns、proxy-providers、rule-providersなどのフィールドが含まれます。フィールドの組み合わせは用途によって異なるため、すべてのファイルに全フィールドが必要なわけではありません。ただし本文がウェブページ、エラー表示、アカウント情報ページになっていないことが重要です。

proxies:
  - name: "Example Node"
    type: ss
    server: example.invalid
    port: 443
    cipher: aes-128-gcm
    password: "example-password"

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "Example Node"
      - DIRECT

rules:
  - MATCH,ノード選択

もう1つよくあるレスポンスは、Base64でエンコードされたノードURIの集合です。デコードすると ss://、trojan://、vmess://などのエントリで構成されていることがあります。これは完全なClash YAMLではありません。一部のGUIクライアントはインポート時に変換処理を呼び出しますが、完全な設定しか受け付けないクライアントもあります。そのため、同じURLでもソフトウェアによって結果が異なる場合があります。サービス側のサブスクリプションページで、Clash、Mihomo、または互換形式と明記された出力を選び、任意の汎用サブスクリプションをYAMLファイルとして直接読み込まないでください。

リダイレクトにも注意が必要です。サブスクリプションURLが最初に301または302を返し、実際のダウンロードURLへ転送されることがあります。クライアントがクロスドメインリダイレクトを禁止している、転送先ドメインの証明書に問題がある、転送後に認証パラメータが失われるといった場合、ブラウザとクライアントで結果が異なる可能性があります。ログにredirect、certificate、TLS、hostnameが同時に現れる場合は、プロキシノードのフィールドを変更する前に、転送先とシステム時刻を確認してください。

レスポンスの文字コードは通常UTF-8である必要があります。ファイル先頭に異常な不可視文字が含まれていたり、本文が別の文字コードとして誤って読み込まれたりすると、先頭行のフィールドを認識できないことがあります。信頼できるローカルテキストエディターで文字コードを確認し、UTF-8で保存し直してから、ローカル設定としてテストできます。ローカルファイルは読み込めるのにリモートサブスクリプションだけ読み込めない場合、問題は通常、サーバーのレスポンスヘッダー、本文の文字コード、またはダウンロード経路にあります。

YAML PARSING

YAMLのインデント、引用符、リスト構造を順に確認する

YAMLはインデントで階層を表すため、スペースの数とフィールドの位置がデータ構造を直接左右します。Clash設定では通常、1段階のインデントに半角スペース2つを使います。YAML仕様上は別の一定幅も許容されますが、実際の調査では2スペースに統一すると読みやすく、断片をコピーした際の階層ミスも減らせます。インデントにタブは使わないでください。

よくある構文エラー

リスト記号の階層が誤っている：- name は対応するリストフィールドの下に置く必要があります。proxies: と同じ左端に置くと、パーサーは新しいルート階層として扱い、エラーになります。
コロンの後にスペースがない：フィールドは通常 port: 443 と記述し、port:443 とは書きません。後者は通常の文字列として解釈される可能性があります。
特殊文字を含む名前を引用符で囲んでいない：ノード名やポリシーグループ名にコロン、シャープ記号、角括弧、中括弧、先頭のアスタリスクが含まれる場合は、二重引用符で囲むことを推奨します。
コメントによる値の途中切れ：引用符で囲んでいないシャープ記号からコメントが始まります。パスワードや名前にシャープ記号が含まれていると、それ以降の内容が無視されることがあります。
重複キーまたは型の誤り：同じ階層で rules を重複して宣言したり、リストが必要なフィールドを単一の文字列として記述したりすると、解析またはフィールド検証の段階で失敗することがあります。

次の断片では、proxies 内のエントリのインデントが1段足りず、さらにポリシーグループが参照する名前と実際のノード名が一致していません。

proxies:
- name: "香港ノード"
  type: ss

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "香港ノード 01"

インデントの修正は第一歩にすぎません。ポリシーグループ内のノード名、ルール内のポリシー名、providerの参照名は、スペース、大文字・小文字、全角文字を含め、定義側と一字一句一致している必要があります。YAMLの解析に成功しても、これらの参照が有効とは限りません。参照エラーは通常、コアが設定を読み込む段階で初めて発生します。

ログに行番号と列番号が表示される場合は、まずエラー行を確認し、その上にある直近の親フィールドまでさかのぼって調べます。パーサーが示す位置は「解析を続行できなくなった場所」であり、実際の原因は前の行にあることがあります。たとえば引用符が閉じていない、配列の括弧が不足している、直前の階層が早く終了しているといったケースです。エラー行だけを削除すると、構文上は正しくても機能が欠けた設定になるため注意してください。

CORE COMPATIBILITY

ClashとMihomoのフィールド互換性を確認する

設定の構文が正しくても、コアの機能差によって読み込みに失敗することがあります。従来のClash、Clash Metaの後継実装であるMihomo、各GUIクライアントに組み込まれた異なるバージョンのコアは、同じプロトコルパラメータや拡張フィールドを完全にサポートしているとは限りません。サブスクリプション提供元が新しいMihomo形式で設定を生成していて、クライアントが古いコアを使っている場合、未知のフィールド、未対応のプロキシタイプ、デシリアライズできないパラメータなどのエラーが発生することがあります。

調査時は、クライアントの「バージョン情報」「コア」、またはログ冒頭で、実際に動作しているコアの名前とバージョンを確認してください。GUIクライアントの名前だけで判断してはいけません。クライアントによってはコアを切り替えられますが、設定更新後も古いコアが実行を担当していることがあります。また、クライアント本体は更新済みでも、コアファイルが同期更新されていない場合があります。

バージョン差が出やすい領域

プロキシプロトコルのフィールド：新しいプロトコルタイプ、トランスポート層のパラメータ、フィンガープリントのパラメータ、UDP関連オプションには、新しいMihomoバージョンが必要になることがあります。
TUN設定：ネットワークスタック、自動ルート、インターフェース検出、DNSハイジャックのフィールドは、バージョンによって値の要件が異なる場合があります。フィールドが存在していても、現在のプラットフォームに対応する権限があるとは限りません。
DNS拡張モード：fake-ip、redir-host、nameserver policy、fallbackに関する構造は、階層と型を正しく保つ必要があります。古い設定例が現在のコアに適用できるとは限りません。
ルールセットとprovider：rule-providers、proxy-providersのリモートURL、更新間隔、ファイルパス、behaviorは、コアがサポートする形式に従う必要があります。
スニッフィングと地理データ：sniffer、GEOSITE、GEOIP、geodataに関する動作は、コアの実装やデータファイルの状態によって変わります。

ログに field not found、unsupported proxy type、invalid valueなどのメッセージが表示された場合は、該当フィールドを現在のコアのドキュメントで確認します。未知のフィールドを一時的に削除して原因を確認することはできますが、機能への影響を理解しないまま長期的に使うべきではありません。たとえばTUNのルート設定を削除すると設定は読み込めても、システム通信がコアに入らなくなる可能性があります。DNS部分を削除すれば、名前解決の経路が変わることもあります。

サブスクリプションサービスがClash形式とMihomo形式の両方を提供している場合、Mihomoコアを使うクライアントでは、Mihomo対応と明記された設定を選ぶのが一般的です。逆に、旧バージョンのClashコアでは、認識可能な基本フィールドを使用してください。ファイル拡張子を何度も変更して互換性を解決しようとしてはいけません。拡張子を変えても設定構造は変換されません。

CACHE AND UPDATE

失敗したキャッシュを削除し、設定が確実に更新されたことを確認する

多くのGUIクライアントは、リモートサブスクリプションをいったんローカルファイルへダウンロードし、その後ローカルキャッシュから読み込みます。更新に失敗しても、前回成功したバージョンを使い続けることがあります。また、エラーページの内容だけが入った一時ファイルを書き込む場合もあります。そのため「ノード一覧が残っている」ことは直前の更新成功の証明にならず、「更新時刻が変わった」ことだけでも新しい設定がコアに受け入れられたとは判断できません。

まず現在利用できる設定の名前と更新時刻を記録し、必要なローカル上書き内容をエクスポートします。その後、クライアントログで更新処理に「リクエスト完了、ファイル書き込み、設定検証、コアの再読み込み」の各段階が含まれているか確認します。ダウンロード完了しか表示されず、reloadや設定切り替えの成功が確認できない場合、処理は検証段階で止まっている可能性があります。

安全なキャッシュ処理の手順

自動更新を停止し、調査中にファイルが上書きされたり、レート制限が発生したりするのを防ぎます。
直近に正常動作したローカル設定のコピーを残し、基本ネットワークを復旧できるようにします。
クライアントから該当する失敗したサブスクリプションの登録を削除し、再コピーした完全なURLで追加します。
クライアントを完全に終了して再起動し、バックグラウンドのコアプロセスも終了していることを確認します。
手動更新を1回実行し、HTTPステータス、ファイルパス、最初に出たエラーをすぐにログで確認します。
更新が成功してから自動更新を有効に戻し、適切な間隔を設定します。

クライアントが上書き、マージ、前処理に対応している場合は、これらの機能も一時的に無効にします。元のサブスクリプションは解析できるのに、マージ後に失敗するなら、問題はローカルの上書きファイルにあります。よくある原因は、上書き後にポリシーグループが重複する、ルールが削除済みのグループを指す、リストがオブジェクトに置き換わる、古いコアに新しいフィールドを書き込むといったものです。

設定の保存先が誤判定の原因になることもあります。システム権限不足、処理できない文字を含むパス、ディスク容量不足、セキュリティソフトによる書き込み阻止などにより、クライアントはダウンロードできても古いファイルを置き換えられない場合があります。この種のログには通常、write、permission、rename、file in useなどが含まれます。リモートサブスクリプションを変更し続けるのではなく、ファイルを書き込める条件を修正してください。

DIAGNOSTIC ORDER

決められた順序でサブスクリプションのインポートを確認する

効率よく調査するポイントは、一度に1つの段階だけを検証し、各手順の結果を残すことです。以下の順序は、「サブスクリプションURLが無効」「設定の解析に失敗」「更新後に有効化できない」といった関連する問題に適用でき、ネットワーク、形式、クライアントの障害が互いに影響するのを抑えられます。

基礎ネットワークを確認：システムプロキシまたはTUNを一時停止し、通常のネットワークとDNSが利用できることを確認してから、サブスクリプションドメインへ接続できるかテストします。
URLを再取得：サブスクリプション管理ページから完全なURLをコピーし、途中切れ、期限切れ、手動変更を排除します。
リクエスト結果を記録：HTTPステータス、リダイレクト、TLSに関する表示、レスポンスの種類を確認し、ブラウザで「開ける」ことだけを判断材料にしません。
本文の形式を確認：返された内容が完全なClash YAML、providerファイル、URIの集合のどれかを確認し、対応するインポート方法を選びます。
YAMLを確認：エラー行を基準にインデント、引用符、コロン、リスト、参照名を確認し、まず読み込み可能な最小設定を作ります。
コアのバージョンを確認：クライアントが実際にClashとMihomoのどちらを使っているかを確認し、エラーのフィールドが現在のバージョンでサポートされているかを調べます。
ローカル上書きを無効化：元のサブスクリプションでテストし、その後ルールのマージ、スクリプト、DNS、TUNの変更を1つずつ戻します。
キャッシュを処理：利用可能なコピーを残してからサブスクリプションを再追加し、ダウンロード、検証、書き込み、コアの再読み込みがすべて完了したことを確認します。
実行結果を確認：ポリシーグループが完全か、ルールが意図どおり適用されるか、DNSが期待した結果を返すかを確認してから、実際の接続をテストします。

サブスクリプション提供元へ連絡する際は、発生時刻、クライアント名、実際のコアとバージョン、HTTPステータス、エラーログの前後数行、認証情報を伏せたレスポンス冒頭を伝えることを推奨します。「インポートできない」というスクリーンショットだけを送らないでください。具体的な情報があれば、問題がサブスクリプション生成、サーバーのアクセス制御、形式変換、クライアントの互換性のどこにあるかを迅速に判断できます。

同じローカルYAMLが現在のコアでは読み込めるのに、リモートURLからのインポートに失敗する場合は、ダウンロードリクエスト、リダイレクト、レスポンスの文字コード、キャッシュへの書き込みを重点的に確認します。複数のクライアントが本文をダウンロードできるのに、同じフィールドでエラーになる場合は、サービス側で生成された設定に構文または互換性の問題がある可能性が高いです。1台の端末だけで失敗する場合は、その端末のシステム時刻、ネットワーク、証明書、ファイル権限、クライアントのコアバージョンを引き続き確認してください。

修正後は、直近に利用できた設定を1つ保存し、サブスクリプション形式と対応するコアを記録します。次に更新異常が起きたとき、「リモートサブスクリプションが変わった」のか「ローカル実行環境が変わった」のかをすぐに切り分けられ、オフライン時に調査の手がかりをすべて失う事態を避けられます。