Clash サブスクリプションリンク失効・パース失敗チェックリスト:404 から YAML エラーまで徹底診断

まず問題の層を見極める:5段階診断の全体像

サブスクリプションの読み込みエラーはメッセージが曖昧なことが多く、クライアントは「パースに失敗しました」「接続できません」あるいは何も表示しないだけで、根本原因がリンク失効・内容フォーマットの不整合・ローカル設定の問題のどれなのかを直接教えてくれません。手当たり次第に試すのは時間の無駄で、リクエストの流れに沿って外側から内側へ順に切り分けていくのが効率的です。まずリンク自体にアクセスできるかを確認し、次に返ってきた内容が正しいサブスクリプションデータかどうかを見極めます。続いてリクエストヘッダーによる内容の差異を排除し、その後 YAML 構文が正しいかを確認、最後にクライアントのバージョン互換性を検証します。この5段階でほとんどのサブスク関連エラーはカバーできるため、順番に確認していけば、リンクを変更したりクライアントを再インストールしたりせずに原因を特定できることが多いです。

始める前に、サブスクリプションリンクを単体で取り出し、クライアント環境から離れてコマンドラインツールで直接テストすることをお勧めします。こうすることでクライアント側のキャッシュや表示の遅延といった要因を排除でき、サーバーから返ってくる生のレスポンスを確認できます。

ステップ1:サブスクリプションリンク自体の到達性を確認する

最初に排除すべきはネットワーク層の問題です。curl に詳細情報オプションを付けてサブスクリプションアドレスへ直接リクエストを送ります。

curl -v -o /tmp/sub.txt "https://your-provider.example/api/v1/client/subscribe?token=xxxx"

-v はリクエストとレスポンスのヘッダー全体を出力し、-o はレスポンスボディをローカルファイルに保存して後で確認できるようにします。まず HTTP ステータスコードを確認してください。

ステータスコード	よくある原因	対処方針
200	リクエスト成功	続けて返却内容のフォーマットを確認
401 / 403	トークンの期限切れ、またはアカウントに制限がかかっている	サービス提供元の管理パネルにログインしてリンクを再取得する
404	サブスクリプション用のパス変更、またはプラン自体が削除済み	管理パネルでサブスクリプションリンクを再度コピーする(ブックマークした古いアドレスは使わない)
429	リクエストが頻繁すぎてレート制限がかかっている	クライアントの自動更新頻度を下げる
タイムアウト、応答なし	DNS 解決の失敗、またはサービス提供元のドメインが汚染されている	システム標準以外の DNS 解決方式でテストする、またはサービス提供元にドメインの状態を確認する

ステータスコードが 404 の場合、問題はリンク自体にあり、クライアント設定とは無関係です。この状態でクライアント側の設定をいじり続けるのは時間の無駄で、サービス提供元の管理パネルに戻ってサブスクリプションアドレスを再取得すべきです。多くのサブスクリプションリンクには有効期限付きのトークンが含まれており、期限切れになると古いリンクはそのまま使えなくなります。これが「先週まで使えていたのに今週突然ダメになった」の最も典型的な原因です。

ステップ2:返却内容が正しいサブスクリプションフォーマットか確認する

ステータスコード 200 は内容が正しいことを保証しません。ステップ1で保存した /tmp/sub.txt を開き、まず先頭数行でフォーマットの種類を判断します。

内容が長い Base64 文字列の場合、通常はノード共有リンクの集合(ss:// や vmess:// などをエンコードして連結したもの)であり、クライアントや変換サービスでデコードしてから設定を生成する必要があります。純正の Clash コアはこの形式を直接読み込めません。
内容が proxies: や rules: などのフィールドで始まっている場合、標準的な Clash/mihomo の YAML 設定であり、クライアントで直接認識できます。
内容が HTML(<html> タグを含む)の場合、リクエストがサービス提供元のゲートウェイで遮断され、サブスクリプションデータではなくエラーページが返されていることを示します。プランの期限切れや、中間機器によるドメインの横取りで通信事業者側の案内ページが返されるケースがよくあります。

注意

返却内容がログインページや認証コードページ、あるいは単純なエラーメッセージだった場合、その内容を無理やり設定として読み込ませないでください。まずアカウントの状態とリンクの入手元が正しいかを確認しましょう。

取得したものが Base64 形式の集合リンクで、クライアントが標準の YAML フォーマットしか対応していない場合、「パース失敗」というエラーは実際にはフォーマットの不一致であり、リンクが壊れているわけではありません。この場合、サービス提供元に Clash 専用のサブスクリプションアドレス(通常 clash、meta、flag=clash のようなパラメータが付く)が提供されているか確認する必要があり、汎用のノード集合リンクとは異なります。

ステップ3:User-Agent とリクエストヘッダー制限による内容差異

多くのサブスクリプション提供元は、リクエストの User-Agent ヘッダーに応じて異なる内容を返します。ブラウザからのアクセスには説明ページを返し、Clash クライアントからのアクセスにのみ実際の設定を返すというケースです。これが「ブラウザでリンクを開くと空白ページやエラーページが表示されるのに、クライアントでは正常に読み込める」あるいはその逆の現象が起きる理由です。curl でクライアントのリクエストを再現する際は、対応する User-Agent を明示的に付けて再度テストすることをお勧めします。

curl -v -H "User-Agent: ClashforWindows/0.20.39" \
  "https://your-provider.example/api/v1/client/subscribe?token=xxxx" \
  -o /tmp/sub_ua.txt

UA を付けない場合と付けた場合の2回のリクエストで返却内容が一致するか比較します。明らかな差異があれば、サービス提供元が UA によって内容を区別していることになり、以降どのツールでテストする場合も対象クライアントの識別子を付ける必要があります。そうしないと取得したサンプルは参考にならず、リンク失効だと誤判定しやすくなります。

また、一部の企業ネットワークや家庭用ルーターは特定の UA やリクエストの特徴を遮断することがあります。この層の問題が疑われる場合は、別のネットワーク環境(スマートフォンのテザリングなど)に切り替えて同じコマンドを再度実行し、ローカルのネットワークポリシーによる影響を排除してください。

ステップ4:YAML 構文エラーを一つずつ確認する

返却内容が確かに YAML フォーマットであることを確認したら、次に構文が正しいかを確認します。Clash/mihomo はインデントやフィールドの型に対して比較的厳格で、よくあるエラーには以下のようなものがあります。

インデントの不統一:YAML はスペースによるインデントで階層を表しますが、同じ階層のフィールドはスペース数を完全に揃える必要があります。タブとスペースを混在させると即座にパースエラーになります。
コロンの後にスペースがない:name:node1 のような書き方は単なるテキストとして扱われ、キーと値のペアとして認識されません。正しい書き方は name: node1 で、コロンの後には必ずスペースを1つ入れます。
特殊文字が引用符で囲まれていない:ノード名やパスワードにコロン、シャープ、角括弧といった YAML の特殊文字が含まれる場合は、文字列全体を引用符で囲む必要があります。例えば password: "abc:123" のようにします。
リスト項目のインデントのずれ:proxies: の下では各項目が - name: で始まり、ハイフンの後のフィールドは統一されたインデント階層を保つ必要があります。どこか1項目でもインデントが1スペース多い、または少ないと、リスト構造全体が壊れます。

ローカルでの確認には、設定全体をクライアントに読み込ませて何度も試行錯誤するのではなく、コマンドラインツールで手早く構文チェックを行うのが効率的です。

python3 -c "import yaml,sys; yaml.safe_load(open('/tmp/sub.txt'))"

ファイルの構文に問題があれば、このコマンドは例外を投げてエラーが発生した行番号と列番号を明示してくれます。クライアント画面上の曖返な「パース失敗」表示よりずっと正確で、修正すべき具体的な行を直接特定できます。サブスクリプションがサービス提供元によって自動生成されている場合、一般ユーザーには編集権限がないことが多く、構文エラーに遭遇した場合は自分で内容を修正するのではなく、サービス提供元にフィードバックすべきです。次回の自動更新でその変更は上書きされてしまうためです。

ステップ5:クライアントのバージョンとフィールドの互換性問題

YAML の構文自体に問題がないのにクライアントでエラーが出る場合は、フィールドの互換性を考える必要があります。mihomo コアは継続的に更新されており、純正の Clash にはなかったフィールド(一部プロキシプロトコルの高度なパラメータやルールセットの差分更新構文など)が多数追加されています。古いバージョンのクライアントが未知のフィールドに遭遇すると、そのフィールドだけを無視して読み込みを続けるのではなく、設定全体の読み込みを拒否してしまう場合があります。逆に、サブスクリプションが旧仕様の構文で生成されている場合、比較的新しいクライアントは通常互換性がありますが、一部のフィールドが廃止扱いになって挙動が変わっているケースもあります。

確認の方向性:

クライアントのバージョン番号を確認し、使用しているコアが純正の Clash か mihomo(Clash Meta の後継プロジェクト)かを照合します。両者が対応するフィールドの集合は完全には一致しません。
クライアントの実行ログを確認します(通常は設定画面からログの入口やローカルログファイルのパスを見つけられます)。ログには通常、どのフィールドまたはどの行が読み込み失敗の原因かが明示されており、曖昧なエラーポップアップよりはるかに多くの情報が得られます。
サブスクリプションの内容にクライアントが認識できないプロキシプロトコル(比較的新しい伝送層の秘匿化方式など)が含まれている場合、そのノードがスキップされるか、設定全体の読み込みが失敗するかはクライアントの実装によって異なります。多くの場合、より新しいバージョンのクライアントにアップグレードすれば解決します。

推奨する確認順序

まずコマンドラインでリンクの到達性と内容の正当性を確認し、次に UA による差異を照合、続いて YAML 構文チェックを行い、最後にクライアントのバージョンを確認します。最初の4ステップで大半の問題は排除できるため、いきなりクライアントを再インストールしたり、サブスクリプションアドレスを何度も変更したりしないようにしましょう。

よくある誤解と推奨事項

実践でよく陥りがちな方向性は2つあります。1つはエラーが出るとすぐにサービス提供元に連絡して新しいリンクをもらうことですが、実は新しいリンクが指す先が同じ設定であり、問題は何も変わっていないというケース。もう1つはクライアント自体のバグを疑って何度もアンインストール・再インストールを繰り返すことですが、問題の本質はサブスクリプション内容のフォーマットにあることに気づいていないケースです。サブスクリプションリンクの生レスポンスを診断の証拠として保存しておき、問題が起きたらまずこの記事の5段階の手順を一通り試してから、サービス提供元への連絡やクライアントへのフィードバックが必要かどうかを判断することをお勧めします。日常的な運用では、サブスクリプションの自動更新間隔を適切に設定する(429 のレート制限を避ける)ことや、サブスクリプションアドレスの入手元を記録しておくことも、後々の診断コストを減らすのに役立ちます。