Clashのサブスクリプション無効・解析失敗チェックリスト：リンク到達性からフィールド互換性まで確認

ダウンロード失敗・解析失敗・設定読み込み失敗を切り分ける

クライアントに「更新失敗」と表示されても、障害が起きている段階は3つに分かれます。第1段階は HTTPS リクエストでサブスクリプション内容を取得する処理、第2段階は応答内容を YAML、Base64 のノード一覧などとして識別する処理、第3段階は解析済み設定を Clash Meta（mihomo）コアに渡して読み込む処理です。画面に表示されるメッセージは似ていても、確認すべき点はまったく異なります。

障害の段階	よくある症状	優先して確認する項目
リンクへのリクエスト	タイムアウト、403、404、接続リセット	ステータスコード、DNS、システムプロキシ、サブスクリプションの有効期限
内容の解析	unexpected token、invalid YAML、設定が空	応答本文、インデント、エンコーディング、サブスクリプション形式
コアによる読み込み	設定はダウンロードできるが、切り替え時に失敗する	フィールド互換性、ポート競合、ルールセットとコアバージョン

完全なエラーメッセージ、発生時刻、現在のクライアントバージョンをまず記録します。次にクライアントのログを開き、ログレベルを一時的に「情報」または「デバッグ」に変更します。Clash Verge Rev 2.x では、通常「設定」→「ログ」から開けます。クライアントによって名称は多少異なり、「設定」→「診断」にある場合もあります。確認が終わったら通常のログレベルに戻し、大量の記録が長期間たまらないようにします。

手順1：サブスクリプション URL から内容を取得できるか確認する

HTTP ステータスコードとリダイレクト結果を確認する

ブラウザーのプライベートウィンドウでサブスクリプション URL を開く方法は、あくまで初期確認にすぎません。ブラウザーは Cookie を自動送信したり、リダイレクトに追従したり、ダウンロードファイルを表示したりしますが、クライアントは独立したネットワークリクエストを使用します。より確実なのは、最終的なステータスコードとレスポンスヘッダーを確認する方法です。Windows 11 では PowerShell で次のコマンドを実行できます。macOS と Linux では、システム標準またはローカルにインストールした curl を使用できます。

curl -L --max-redirs 5 --connect-timeout 10 \
  --max-time 30 -D headers.txt \
  -o subscription.txt \
  "https://example.com/api/subscription?token=REDACTED"

-L は 301、302、307、308 リダイレクトへの追従を許可し、--max-redirs 5 はリダイレクト回数を制限します。接続タイムアウトは 10 秒、リクエスト全体の制限は 30 秒です。コマンドはレスポンスヘッダーを headers.txt に、本文を subscription.txt に保存します。テスト時はサンプルアドレスをローカルで置き換え、実際のトークンを共有スクリプトに書き込まないでください。

200：サーバーから内容が返されています。続けて本文が本当にサブスクリプション設定か確認します。
301、302、307、308：リダイレクトが発生しています。最終的にもリダイレクトが続く場合はループの可能性があります。ログインページへ移動する場合、クライアントは対話式ログインを完了できません。
401、403：トークンの期限切れ、権限不足、アクセス元の制限、またはリクエストポリシーによるブロックです。
404、410：サブスクリプションのパスが無効化された、プラン移行後に旧 URL が使えなくなった、またはコピー時に URL が途中で切れた可能性があります。
429：リクエスト頻度が高すぎます。自動更新を停止し、サーバー側の制限時間が終わってから再試行します。
500、502、503、504：サーバーまたは上流サービスで一時的な異常が発生しています。サービスの稼働状況と、時間を置いて再試行した結果を合わせて判断します。

コピー中に URL が変わっていないか確認する

サブスクリプション URL には ?、&、=、% などの文字がよく含まれます。チャットアプリでの折り返し、リッチテキストエディターによるエスケープ、末尾文字の手動削除によって、トークンが無効になることがあります。URL の前後に引用符、全角スペース、改行を入れてはいけません。サービス提供元の管理画面に「サブスクリプションをコピー」ボタンがある場合は、完全な URL をもう一度コピーし、クライアントで新しい設定として登録します。古い記録を編集し続けないでください。

システム時刻も確認します。HTTPS 証明書の検証は端末の時計に依存します。日付が数日ずれていると、ログに証明書がまだ有効でない、または期限切れという内容が出ることがあります。Windows では「設定」→「時刻と言語」→「日付と時刻」で時刻の自動設定を有効にし、すぐに同期します。Android では通常「設定」→「システム」→「日付と時刻」にあります。

システムプロキシのループと現在のノード障害を切り分ける

サブスクリプションへのリクエストは直接接続する場合もあれば、システムプロキシを引き継ぐ場合もあります。ローカルの混合ポートは 7890 が一般的で、一部のクライアントでは 7897 が初期値です。具体的な値は「設定」→「ポート設定」の Mixed Port を確認してください。クライアントのコアが停止しているのに、システムプロキシが 127.0.0.1:7890 を指していると、サブスクリプションへのリクエストは待ち受けていないローカルポートへ接続することになります。

クライアントの「システムプロキシ」を無効にしてから、サブスクリプションの更新を試します。
直接接続でサブスクリプションのドメインにアクセスできない場合は、コアを再起動し、利用できることを確認したノードを選んでから更新します。
TUN モードを有効にしている場合は、まず「設定」→「ネットワーク設定」で TUN を無効にし、通常のリクエストを1回実行して比較します。
ログに connection refused 127.0.0.1、i/o timeout、またはローカルポートへの転送が繰り返し出ていないか確認します。

TUN モード自体は YAML の構文解析には関与しませんが、サブスクリプションへのリクエスト経路を変えます。TUN を無効にした後だけ更新に成功する場合は、ルーティングの除外設定、システムプロキシの状態、現在のノードの可用性を確認します。サブスクリプション本文を直接変更してはいけません。

手順2：返された内容が実際に利用可能なサブスクリプションか確認する

ファイル拡張子ではなく本文の先頭を確認する

サブスクリプション URL の末尾に .yaml がないのは珍しくありません。判断基準はレスポンスの内容です。先ほど保存した subscription.txt をテキストエディターで開き、先頭20行を確認します。Clash または mihomo 向けの完全な YAML 設定には通常、proxies、proxy-groups、rules、proxy-providers などのトップレベルフィールドが含まれます。

mixed-port: 7890
mode: rule

proxies:
  - name: "Example Node"
    type: ss
    server: 203.0.113.10
    port: 443

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "Example Node"

rules:
  - MATCH,PROXY

本文が <!doctype html>、<html>、またはログインフォームで始まる場合、実際に取得したのはウェブページです。{"code":403,"message":"expired"} のような JSON エラーオブジェクトも Clash 設定ではありません。この場合は認証またはサーバー側の問題に対処する必要があり、YAML ファイルを編集しても解決しません。

Base64 のノード一覧と共有リンクを識別する

英字、数字、プラス、スラッシュ、イコールだけで構成された長い文字列は、Base64 でエンコードされた汎用サブスクリプションかもしれません。デコードすると、ss://、trojan://、vmess://、hysteria2:// の共有リンクが1行ずつ並んでいることがよくあります。一部のクライアントはこれらのリンクをインポートできますが、完全な Clash YAML として読み込むと、トップレベルの型エラーや proxies が見つからないエラーになります。

まずサブスクリプション提供元の管理画面に戻り、Clash、Clash Meta、または mihomo と表示された出力形式を選択します。形式変換ではノードの認証情報を扱うため、自分で管理するローカルツール、または信頼できるサーバー側 API を使用してください。変換後もプロキシグループ、ルール、DNS 設定を確認します。ノード一覧は接続パラメータを示すだけで、完全なルーティング設定ではありません。

文字エンコーディングとファイル先頭を確認する

YAML ファイルは UTF-8 で保存することをおすすめします。テキストエディターに文字化けが大量に表示される、またはログに制御文字関連のエラーが出る場合は、UTF-8 で再度書き出します。ファイル先頭の UTF-8 BOM は通常、最新のパーサーで処理できますが、一部の古いクライアントや外部変換スクリプトではフィールドの一部として扱われることがあります。確認時はファイルを「UTF-8」で別名保存し、比較用に元のファイルも残してください。

手順3：行単位で YAML の構文・構造エラーを特定する

まずログに表示された行番号と列番号を確認する

代表的なエラーには did not find expected key、mapping values are not allowed、cannot unmarshal、duplicate key があります。ログの行番号は、パーサーが最終的に構造を失った位置を示すことが多く、実際の原因はその1〜3行前にある場合があります。エラー行、直前の項目のインデント、引用符が正しく対になっているかを同時に確認します。

インデントにはスペースを使い、Tab とスペースを混在させないでください。
同じ階層ではインデントを統一します。一般的には1階層につきスペース2つです。
リスト項目のハイフンの後にはスペースを入れます。例：- name: node-a。
名前にコロン、シャープ、波括弧、または前後のスペースが含まれる場合は、引用符で囲みます。
ポートは port: 443 のように整数で記述し、余計な文字を含む値にはしません。

# 誤り：proxy-groups が proxies の項目内にインデントされている
proxies:
  - name: node-a
    type: ss
  proxy-groups:
    - name: PROXY

# 正しい：2つのフィールドがどちらもトップレベルにある
proxies:
  - name: node-a
    type: ss

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - node-a

構文が正しいことと、フィールドの型が正しいことを区別する

YAML の構文チェックを通過しても、コアがすべてのフィールドを受け入れるとは限りません。たとえば port: "443" は YAML では文字列であり、プロトコル設定では通常整数が必要です。udp: "true" も文字列で、正しい値はブール値の true です。ログに cannot unmarshal string into Go value が出る場合は、値の型を重点的に確認します。

フィールド	一般的に正しい型	間違えやすい形式
`port`	整数	`"443 tcp"`
`udp`	ブール値	`"true"`
`proxies`	リスト	カンマ区切りの単一文字列
`nameserver`	リスト	インデントが誤ったマッピングオブジェクト
`interval`	秒数を表す整数	`24h`

プロキシグループの参照とルールの宛先を確認する

構文解析が完了すると、コアは参照関係も検証します。ルール末尾のポリシー名は、既存のプロキシグループ、プロキシ名、または組み込みアクションに対応していなければなりません。たとえばルールが DOMAIN-SUFFIX,example.com,Proxy なのに、設定には PROXY という名前のグループしかない場合、大文字・小文字の違いによって宛先が見つからなくなります。プロキシグループ内のノード名も、proxies または use の参照先と一致させる必要があります。

RULE-SET を使う場合は、対応する名前が rule-providers に定義されていることも確認します。provider の behavior は内容に合わせます。ドメイン集合には通常 domain、IP ネットワーク集合には ipcidr、完全なルール文を含む集合には classical を使用します。リモートルールセットのダウンロードに失敗しても、メインのサブスクリプション自体は解析に成功している場合があります。そのときは provider の URL、ステータスコード、タイムアウト情報がログに個別表示されます。

手順4：Clash Meta コアのバージョンとフィールド互換性を確認する

クライアントの画面バージョンとコアバージョンを別々に確認する

デスクトップクライアント、モバイルクライアント、mihomo コアにはそれぞれ独立したバージョンがあります。画面をアップデートしても、コアまで同時に切り替わるとは限りません。同じサブスクリプションの結果が2台の端末で異なる場合も、コアバージョンの違いが原因であることがよくあります。「設定」→「バージョン情報」または「設定」→「コア」から完全なバージョン情報を記録してください。確認時は少なくともクライアント名、クライアントバージョン、コアの種類、コアバージョンを明記します。例：「Clash Verge Rev 2.x、mihomo 1.19.x」。

新しいプロトコルやトランスポートのフィールドには、対応するコアが必要です。設定に type: hysteria2、type: tuic、VLESS Reality、WireGuard、新しい DNS フィールドなどが含まれている場合、古い Clash コアでは未知の型や未知のフィールドとして扱われることがあります。対処方法は、サブスクリプションが想定する mihomo コアへ切り替えるか、現在のコアと互換性のある形式で出力するようサービス側に設定することです。認証、TLS、トランスポートのパラメータを無作為に削除してはいけません。

最小構成でノード固有の問題か全体設定の問題かを確認する

元のファイルをコピーして保存したうえで、既知のノード1つ、プロキシグループ1つ、MATCH ルール1つだけを残した最小テスト設定を作成できます。最小構成が読み込めたら、DNS、TUN、rule-providers、高度なプロトコル設定を少しずつ戻し、問題のブロックを特定します。ノード1つでもエラーになる場合は、そのノードの type、アドレス、ポート、認証フィールド、TLS パラメータを重点的に確認します。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: test-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - test-node
      - DIRECT

rules:
  - MATCH,PROXY

このサンプルは構造を読み込めるか確認するためだけのものです。127.0.0.1:1080 で実際に SOCKS5 サービスが待ち受けていなければ接続できません。構造テストは通るのにネットワークテストが失敗する場合、YAML の構成はコアに受け入れられています。以降はノードの到達性と認証パラメータを確認します。

ポートの使用状況と残存コアプロセスを確認する

設定の解析に成功した後、ログに address already in use と表示される場合、問題はサブスクリプション形式ではなく待ち受けポートです。よくある競合には、古いコアが 7890 を使用している、コントローラー用ポート 9090 を別のインスタンスが使用している、複数のクライアントが同時にシステムプロキシを有効にしているケースがあります。他のプロキシクライアントと残存コアを完全に終了してから設定を再読み込みします。また、比較のため Mixed Port を一時的に 7897 に変更することもできます。

Windows では netstat -ano | findstr :7890 を実行して使用中のプロセス番号を確認できます。macOS と Linux では lsof -iTCP:7890 -sTCP:LISTEN を実行します。プロセスの正体を確認してから終了し、ポート番号だけを根拠にシステムサービスを停止しないでください。

手順5：結果に応じて対処する

リンク無効または認証失敗

サービスの管理画面からサブスクリプション URL を再生成し、プランの状態と端末数制限を確認します。
クライアントから失敗した記録を削除してサブスクリプションを新規作成し、キャッシュされた URL を使い続けないようにします。
自動更新間隔を、たとえば1440分など適切な値に設定します。短時間に連続更新すると 429 が発生することがあります。
新しい URL でも 401 または 403 が返る場合は、ステータスコード、時刻、トークンを隠したログを保存してサービス提供元に問い合わせます。

ウェブページ、JSON エラー、または汎用ノード一覧が返る

コピーしたのがユーザーセンターのページ URL ではなく、サブスクリプション API の URL であることを確認します。
Clash Meta または mihomo 形式を選び、設定を再ダウンロードします。
共有リンク一覧しか取得できない場合は、ローカルの変換手順で YAML を生成し、プロキシグループとルールを自分で追加します。
変換後は新しい設定として先にインポートし、まだ動作している古い設定を上書きしないでください。

YAML フィールドまたはコアの互換性がない

ログの行番号を手がかりに、インデント、引用符、フィールドの型を確認します。
現在の mihomo バージョンが対応する設定構造と照合し、プロトコルの種類と DNS フィールドを確認します。
最小構成から少しずつ戻し、特定のノード、ルールセット、DNS ブロックのどこに問題があるかを絞り込みます。
コアを更新したらクライアントを再起動し、新しい接続を確立してからテストします。古い接続の結果を引き継がないでください。

修復後の検証記録

完全な検証では、サブスクリプションへのリクエストが 200 を返す、本文が想定形式である、設定が mihomo コアに読み込まれる、実際の接続がルールに従って対応するプロキシグループへ振り分けられる、という4項目を確認します。ノード数が増えただけでは、ルールセット、DNS、TUN が正常に動作しているとは限りません。

手動で1回更新し、所要時間を記録します。たとえば同じネットワークで3回連続して1.2秒、1.4秒、1.3秒なら、結果は比較的安定しています。
ログを開いた状態で、直接接続するドメインとプロキシ経由のドメインにそれぞれアクセスし、ルールの適用先が想定どおりか確認します。
プロキシグループを切り替えた後に新しい接続を作成します。古い TCP 接続では、以前の出口がそのまま使われることがあります。
クライアントを再起動してから設定をもう一度読み込み、メモリ上だけに残っている一時状態を除外します。
適切な自動更新間隔に戻し、システムプロキシと TUN の状態が普段の利用方法に合っていることを確認します。

確認の順序は固定します。まず HTTP ステータスとレスポンス本文を確認し、次に YAML の構文と参照関係を調べ、最後にコアのバージョン、ポート、実行状態を確認します。こうすれば、リンクがすでに期限切れなのに設定を何度も編集したり、ポート競合をサブスクリプション解析エラーと誤認したりするのを防げます。