Clash サブスクリプション失敗・解析エラーの切り分け:よくある原因とチェックリスト

サブスクリプションは Clash 利用中で最もトラブルが起きやすく、しかも一目では原因が分かりにくい部分です。同じ「サブスクリプション更新失敗」でも、原因はネットワークが繋がらない、リンクそのものが期限切れ、YAML フォーマットが壊れている、あるいはクライアントの設定スイッチひとつが原因の場合もあります。何度も試すより順番に切り分けるほうが早く済みます。本記事では4つの層に分けて、そのままチェックできるリストを整理します。

まず症状を具体的に分類する

サブスクリプション関連の問題は大きく3種類に分けられ、それぞれ切り分け方が異なります。まず自分がどのタイプに該当するかを判断すると、無駄な試行を大幅に省けます。

• 更新失敗・タイムアウト:「サブスクリプションを更新」をクリックしても長時間反応がない、またはネットワークエラーや接続タイムアウトが直接表示される。この種の問題は多くが通信状況またはリンク自体に原因があります。
• インポート成功だがノード一覧が空:クライアントは更新成功と表示し、バージョン番号やトラフィック情報も更新されているが、プロキシグループに選択可能なノードが一つも表示されない。この種の問題は通常、サブスクリプション内容のフォーマットやルール解析に関係します。
• 解析エラー:クライアントが明確なエラーを表示する。例えば YAML 構文エラー、フィールド欠落、エンコーディング異常など。この種の問題は元のサブスクリプション内容を一行ずつ確認する必要があります。

第1層:通信状況のセルフチェック

サブスクリプション更新は本質的にはクライアントがサブスクリプションサーバーに対して行う HTTP リクエストであり、このリクエストを妨げる要因があれば「更新失敗」として表れます。

1. まず端末のネットワーク自体が使えるか確認する。ブラウザで任意のサイトを開いて、ネット断・Wi-Fi 切断などの基本的な問題を排除します。
2. サブスクリプションのドメインにアクセスできるか確認する。一部のサブスクリプション事業者のドメインは、特定のネットワーク環境ではそもそも直接アクセスできないことがあり、これは Clash 自体とは関係なく、ドメイン解析または直結経路の問題です。ネットワーク環境を切り替えて(例えばスマホのテザリングに切り替えて)復旧するか試してみましょう。
3. システムプロキシとクライアントのプロキシが衝突していないか確認する。端末に他のプロキシソフトが同時に起動していたり、システムレベルのプロキシが失効したアドレスを指していたりすると、サブスクリプション更新リクエストが誤ったプロキシ経路で遮断される可能性があります。一度他のプロキシツールを終了させてから再試行することをおすすめします。
4. ローカルのファイアウォールやセキュリティソフトの遮断ルールに引っかかっていないか確認する。一部のセキュリティソフトは未知のプログラムからのネットワークリクエストを遮断することがあります。セキュリティソフトの遮断ログを確認しましょう。
5. 更新時にサブスクリプション自身が提供するノードを経由していないか確認する。クライアントで「プロキシ経由でサブスクリプションを更新」が設定されていて、現在選択中のノードがちょうど失効している場合、更新リクエスト自体が送信できず、デッドロック状態になります。この場合は一旦直結モードに切り替える、または一時的に別の使用可能なノードを選んでから更新を実行してみてください。

第2層:サブスクリプションリンクの有効性チェック

ネットワーク層に問題がないことを確認したら、次にサブスクリプションリンク自体が有効かどうかを確認します。

1. リンクが完全にコピーされているか確認する。サブスクリプションリンクは通常長く、末尾に token パラメータが付いていることが多いため、コピー時に途切れたり、余分な空白や改行が入ったりすると、リクエストパラメータが不完全になります。サブスクリプション事業者のパネルからもう一度完全にコピーし直すことをおすすめします。
2. サブスクリプションが期限切れ、またはトラフィックを使い切っていないか確認する。多くのサブスクリプションサービスは、トラフィック消耗後や期限切れ後もコンテンツの取得自体は許可しますが、内部のノードが空リストや案内用のノードに置き換わっており、「更新成功だが利用可能なノードがない」という状態になり、解析エラーと混同しやすいです。サブスクリプション事業者のユーザーパネルにログインしてアカウント状態を確認するのが最も直接的な方法です。
3. サブスクリプションリンクに対応するプランが現在のクライアントに対応しているか確認する。一部の事業者は異なるクライアント種別ごとにサブスクリプションアドレスを分けている場合があり、例えば汎用サブスクリプションと特定クライアント向けに最適化されたパラメータでは仕様が異なるため、アドレスを取り違えると内容の構造が一致しないことがあります。
4. ブラウザで直接サブスクリプションリンクを開いて返された内容を確認する。ブラウザで Base64 エンコードや YAML テキストが正常に表示されれば、リンク自体には到達できていることになります。404、403 や空白ページが返される場合、問題は基本的に事業者側にあると特定できます。
5. リンクのプロトコルヘッダーが正しいか確認する。一部のサブスクリプションアドレスは https を要求しており、クライアントに保存されているのが http バージョンの場合、事業者側で直接リクエストを拒否することがあります。

第3層:サブスクリプションフォーマットと解析互換性のチェック

リンクが正常に開けて、内容も取得できているにもかかわらず、クライアントが解析エラーを表示したり、インポート後にノードが空になったりする場合、問題は通常、内容のフォーマットとクライアントの解析ルールの互換性にあります。

1. サブスクリプションが返しているのが YAML か、それとも Base64 エンコードされたノード一覧かを確認する。これは全く異なる2種類のサブスクリプション形式です。Clash 系クライアントは通常、標準的な YAML フォーマットの設定ファイルを要求します。事業者が提供しているのが他プロトコル向けクライアント用の Base64 ノード一覧である場合、そのままインポートすると構造の不一致により解析失敗またはノードが空になります。
2. YAML のインデントが統一されているか確認する。YAML はインデントに極めて敏感で、同じ階層のフィールドは統一された数のスペースを使う必要があり、タブとスペースの混用は禁止です。サブスクリプション内容を手動で編集した場合、これが最もよくあるエラーの原因です。
3. 必須フィールドが揃っているか確認する。有効な Clash 設定には少なくとも proxies(ノード一覧)、proxy-groups(プロキシグループ)、rules(振り分けルール)という3つのトップレベルフィールドが必要で、いずれかが欠けるとクライアントが読み込みを拒否したり、機能が異常になったりすることがあります。
4. 特殊文字が正しくエスケープされているか確認する。ノード名やパスワードなどのフィールドにコロンや引用符など YAML の予約文字が含まれていて、それが引用符で囲まれていない場合、全体の構造解析が破壊されます。
5. プロトコルフィールドがクライアントの対応する種類かどうか確認する。異なるバージョンの Clash コアはプロトコル対応範囲が完全には一致していません。例えば新しめのプロトコル拡張フィールドは mihomo コアだけが認識できる場合があり、古いバージョンのクライアントが未知のフィールドに遭遇した際の処理は実装によって異なり、そのノードをスキップするものもあれば、そのままエラーになるものもあります。

以下は構造が完全な最小限のサブスクリプション例で、自分のサブスクリプション内容の構造が正しいかどうかを照らし合わせる参考にできます:

proxies:
  - name: "サンプルノード-01"
    type: ss
    server: example.your-domain.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - サンプルノード-01
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:
  - MATCH,自動選択

自分のサブスクリプション内容を上記の構造と照らし合わせて、どこかの階層のインデント、フィールド名、引用符の使い方に明らかな違いがあれば、おおよその位置を特定できます。一部のクライアントは解析失敗時にログで行番号を示してくれるので、ログと合わせて該当行を直接特定できます。

第4層:クライアント設定のセルフチェック

リンクとフォーマットに問題がない場合、最後にチェックすべきはクライアント自体の設定項目です。この層は見落とされがちですが、「サブスクリプションは更新されたのに反映されない」という問題の多くはここに原因があります。

1. 更新後、正しい設定ファイルに切り替わっているか確認する。一部のクライアントは複数のサブスクリプション設定を保存できるため、そのうちの一つを更新しても、現在有効になっている設定がその更新したものでない場合、画面上のノード一覧は当然変化しません。
2. サブスクリプションの自動更新間隔が長すぎないか確認する。自動更新間隔を24時間に設定していて、事業者側ではすでにノードが変更されている場合、手動で更新をクリックしない限り一覧の内容は自動的には更新されません。
3. 強制リフレッシュが有効になっているか確認する。一部のクライアントはサブスクリプション内容をローカルにキャッシュします。事業者が返す内容が変わっていない場合(例えば HTTP キャッシュヘッダーの設定が不適切な場合)、クライアントがローカルキャッシュを直接読み込んでしまい、再取得を行わないため、ノード一覧が古いバージョンのまま止まることがあります。
4. プロキシグループのフィルタリングルールが新しいノードを誤って除外していないか確認する。一部のクライアントはノード名のキーワードでプロキシグループのメンバーを絞り込む機能があります。サブスクリプション側がノードの命名規則を変更し、フィルタリングルールが追随していない場合、新しいノードがルールによってプロキシグループから除外され、一覧が「空になった」ように見えます。
5. クライアントの設定検証によるブロックが発生していないか確認する。一部のクライアントは新しい設定をインポートする前にフォーマット検証を行います。新しいサブスクリプション内容に軽微な不備があってエラーレベルには達していない場合、クライアントは静かに更新を拒否して旧設定を保持することがあり、この場合画面には明確なエラー表示が出ないため、「事業者側が更新していない」と誤解しやすいです。

習慣化して、次回の切り分けを減らす

サブスクリプション関連の障害を完全に避けるのは難しいですが、いくつかの日常的な習慣で切り分けのコストを大幅に下げられます。

• サブスクリプションリンクを変更した後は、まずブラウザで内容が正常に開けることを確認してからクライアントにインポートし、ネットワークの問題とフォーマットの問題を混同しないようにしましょう。
• クライアントが複数のサブスクリプション設定の保存に対応している場合、以前確認済みの動作する設定を一つバックアップとして残しておくと、新しいサブスクリプションで解析異常が発生した際にすぐ切り戻せて、通常利用に影響しません。
• サブスクリプション事業者の期限切れやトラフィックの通知に注意し、トラフィックを使い切った後にノード一覧の異常に気づくという事態を避けましょう。
• サブスクリプション内容を手動で編集する前に元のファイルをバックアップしておきましょう。YAML フォーマットは一度インデントを間違えると、原因を探すより新たにサブスクリプションを取得し直す方が早いことも多いです。

このチェックリストを一通りの手順として実践すれば、サブスクリプション関連の問題の多くは4つの層のいずれかで具体的な箇所を特定できます。切り分けの結果サブスクリプション事業者側の問題だと確認できた場合は、事業者に具体的な現象(リンクが開けるか、返される内容の詳細など)を伝えて直接連絡することをおすすめします。そのほうが相手もサーバー側の障害かどうかを早く確認できます。