Clashのサブスクリプションを読み込めない？解析エラー・リンク切れの確認方法

ダウンロードエラー・解析エラー・設定検証エラーを切り分ける

Clashのサブスクリプション読み込みは、ひとつの処理ではありません。クライアントがサブスクリプションURLにアクセスしてレスポンス本文を取得し、YAMLなど対応形式を解析した後、コアがプロキシ、プロキシグループ、ルールを検証します。画面に同じ「読み込み失敗」と表示されても、問題の発生箇所はさまざまです。まずクライアントの「ログ」を開き、エラーが起きた時刻と最初に記録された明確なエラーを確認してから変更を加えましょう。

Clash Verge Revなどのクライアントでは、画面上の項目名がバージョンによって異なります。通常は「サブスクリプション」画面でリモートサブスクリプションを追加し、URLを入力して読み込みます。登録済みのサブスクリプションは、該当カードのメニューから「更新」します。調査時はクライアントとコアのバージョンも記録し、「最新版」とだけ書かないようにしましょう。旧版のClashコア、Clash Meta（現mihomo）、その他の互換実装では、対応する設定項目が異なる場合があります。

ログ・症状	まず確認すること	次の手順
`timeout`、`lookup`、TLSエラー	ネットワーク、DNS、証明書	YAMLを変更する前に、有効なレスポンスを取得する
HTTP 401、403、404	認証、URL、サーバーの状態	アカウントページとサブスクリプションの設定を確認する
`yaml: line 12`などの行番号表示	レスポンス本文とYAML構文	エラー行とその数行前を確認する
未対応のプロキシタイプ、存在しないプロキシグループの参照	コアの互換性と設定構造	対応形式を選び、使用するコアでテストする
読み込みは成功したが、ノードが表示されない	サブスクリプションの内容、フィルター条件、provider	ノードの情報源が読み込まれているか確認する

手順1：コピーしたのがサブスクリプションURLか確認する

サービス提供元のアカウントページで、Clash、Clash Meta、mihomo用と明記されたサブスクリプションを選択します。アカウントのログインページ、プラン詳細ページ、招待リンクはサブスクリプションURLではありません。ブラウザーでページが開けても、そのページをコアが設定として読み込めるとは限りません。

URLを最初から最後までコピーし直します。先頭が https:// か、末尾がチャットアプリで切れていないか、前後に空白や改行、日本語の句読点が混ざっていないかを確認します。アカウントページのコピー機能を使うのがおすすめです。
クエリパラメーターはそのままにします。tokenやkeyなどのパラメーターをむやみに削除したり、URL全体を再度パーセントエンコードしたりしないでください。パラメーター名は、サービス提供元が発行したURLのとおりにします。
エスケープ文字を確認します。HTMLソースからコピーすると、パラメーターの区切り文字が&という文字列になっていることがあります。通常、URLの複数のクエリパラメーターは&で区切ります。元の画面からコピーし直し、トークンの内容を推測で一括置換しないでください。
URLがリセットされていないか確認します。サブスクリプションのトークンをリセットすると、古いURLはすぐに使えなくなる場合があります。古い項目の「更新」を繰り返すのではなく、クライアントに保存したURLを新しいものに更新してください。

サブスクリプションURLには、アカウントの認証情報と同等の機密性があります。公開のオンラインYAMLチェッカー、信頼できないサブスクリプション変換サイト、公開チケットに貼り付けないでください。サービス提供元に問い合わせる場合は、エラーの種類と発生時刻を伝え、必要な情報だけを非公開のサポート窓口から送ってください。

手順2：HTTPステータスコードと実際のレスポンスを確認する

サブスクリプションが無効かどうかを判断するには、ステータスコードと本文の両方を確認します。HTTP 200でも、ログインページ、アクセス制限ページ、JSON形式のエラーが返る場合があります。Content-Type: text/plainでも、有効なYAMLが含まれていることがあります。ファイル拡張子、レスポンスヘッダー、「ダウンロード成功」の表示だけで判断しないでください。

レスポンスをローカルに保存し、まずリダイレクトを自動追跡しない

ターミナルの操作に慣れている場合は、Bashで次のコマンドを実行できます。入力したサブスクリプションURLを表示せず、レスポンスヘッダーと本文をそれぞれカレントディレクトリに保存します。まず自分だけがアクセスできる作業ディレクトリに移動してください。保存したファイルには機密情報が含まれるため、アップロードしたり公開リポジトリに同期したりしないでください。Windowsでは、Bashを利用できる環境を使うか、クライアントのログで同様の情報を確認できます。

umask 077
read -r -s -p 'サブスクリプションURLを入力：' SUB_URL
printf '\n'
curl --connect-timeout 10 --max-time 30 \
  --dump-header subscription-headers.txt \
  --output subscription-body.txt \
  --write-out 'HTTP %{http_code}\n' \
  "$SUB_URL"
unset SUB_URL

ここでの10秒は接続タイムアウト、30秒はリクエスト全体の上限時間です。実測性能やクライアントの既定値を示すものではありません。コマンドには自動リダイレクトのオプションを付けていません。301、302、307、308が返った場合は、まずローカルでLocationがサービス提供元の正規ドメインを指しているか確認します。リダイレクト先にもトークンが含まれる場合があるため、レスポンスヘッダーをそのまま共有しないでください。コマンドラインとクライアントではリクエストの特徴が異なる場合があります。この結果は比較の参考であり、クライアントにも同じレスポンスが返ることを保証するものではありません。

ステータスコードから原因を絞り込む

200：本文を確認します。<!DOCTYPE html>や<htmlで始まる場合、通常はWebページであり、Clashの設定ファイルではありません。
204または本文が0バイト：解析できる内容がありません。URLとサーバー側の生成状態を確認してください。YAMLの項目を付け足して問題を隠さないようにしましょう。
401、403：トークンの無効化、権限不足、アクセス元の制限、セキュリティ対策などが考えられます。ステータスコードだけでアカウントの有効期限切れとは判断できません。
404、410：古いURLが移転または廃止されていないか確認し、アカウントページから新しいURLを取得してください。
429：連続して再試行するのはやめましょう。レスポンスにRetry-Afterが含まれている場合は、その指定に従って待ちます。
500、502、503、504：サブスクリプション生成サービスや上流ゲートウェイの障害が考えられます。発生時刻を記録して、サービス提供元に問い合わせてください。

本文がvmess://やss://などで始まるノード一覧、または長いBase64文字列の場合、汎用のサブスクリプション形式を選んでいる可能性があります。そのまま読み込めるかどうかはクライアントによって異なり、完全なClash YAMLとして扱うことはできません。サービス提供元が用意した適切な形式を選び直してください。

手順3：YAMLのインデント、項目の型、プロキシの参照先を確認する

レスポンスがYAMLだと確認できたら、構文を調べます。YAMLでは空白で階層を表すため、インデントにTabを混ぜてはいけません。エラーに表示された行番号は、パーサーが異常を検出した位置であり、原因はその前の行にあることもあります。たとえば、閉じていない引用符、コロンの後の空白不足、リストの一部がコピー時に欠落したケースです。

まず構文を確認し、次に設定の意味を確認する

インデント：同じ階層ではインデントをそろえます。通常は1階層あたり半角スペース2つです。リスト項目の-も、正しい階層に置いてください。
特殊文字：名前やパスワードに「コロンと空白」や#などが含まれる場合は、正しく引用符で囲みます。シングルクォートで囲んだ文字列にシングルクォートが含まれる場合は、YAMLの規則に従って2つ重ねて記述します。
項目の型：proxiesは通常ノードのリスト、proxy-groupsはプロキシグループのリスト、rulesはルールのリストです。YAMLとして解析できても、項目の型がコアの要件に合っているとは限りません。
参照名：ルールやプロキシグループが参照するノード名・グループ名が存在し、表記が一致していることを確認します。ノード名だけを変更し、参照先を古いままにしないでください。

解析の問題を切り分けるための、最小限の直接接続設定を以下に示します。独立したテストファイルとして保存し、通常使用するサブスクリプションを上書きしないでください。プロキシノードは含まず、すべての通信を直接接続します。テストに成功しても、確認できるのはこの基本設定が受け付けられることだけです。サブスクリプションやプロキシ回線の復旧を意味するものではありません。

mixed-port: 7890
mode: rule
log-level: info
proxies: []
proxy-groups:
  - name: DIRECT-TEST
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,DIRECT-TEST

ここでの7890は例として示す混合ポートであり、すべてのクライアントに共通する既定値ではありません。ポートの競合は一般にコアの起動や待ち受けに影響しますが、リモートの本文がHTMLになる原因ではありません。設定をテストするだけなら、システムプロキシの切り替え、TUNの有効化、DNSの変更は不要です。

実際に使用するコアでテストする

ローカルにmihomoの実行ファイルがある場合は、次のコマンドで保存した設定を検証できます。クライアントが実際に使用しているバージョンのコアを指定してください。別の新しいコアでテストに成功しても、古いコアとの互換性があるとは限りません。

mihomo -v
mihomo -t -f ./profile.yaml

-tは設定のテスト、-fはファイルの指定に使います。完全な設定がリモートproviderを参照している場合、初期化や検証中にリソースを取得することがあります。信頼できる設定を使い、管理された環境で操作してください。テストログにノード名やリソースURLが含まれる場合もあるため、そのまま公開しないでください。

手順4：コアの形式、provider、クライアントのオーバーライドを確認する

どちらもYAMLでも、「完全な設定」と「ノードプロバイダーファイル」は別物です。proxy-providersで使うファイルには通常、proxiesのノード一覧だけが含まれ、完全な実行設定ではありません。メイン設定からproviderを参照する必要があります。反対に、プロキシグループやルールを含む完全なサブスクリプションを、ノード一覧だけを受け付ける欄に入力しても、読み込みに失敗することがあります。

対象のコアを確認します。サービス提供元がClash用とClash Meta/mihomo用の入口を別々に用意している場合は、実際に使用しているコアに合う方を選びます。未対応のプロキシタイプや項目が表示されたら、まず対応状況を確認してください。セキュリティやプロトコルに関する項目を安易に削除しないでください。
追加のダウンロードを確認します。メイン設定の読み込み後も、proxy-providersやrule-providersのリソース取得が必要な場合があります。ログで失敗したURLの種類を確認し、サブスクリプション本体の取得失敗とリソース更新の失敗を区別してください。
参照関係を確認します。providerを使うプロキシグループは、useなど対応する項目で該当する名前を参照する必要があります。フィルター式ですべてのノードが除外されている場合も、グループ内に選択できるノードがない状態になります。
オーバーライドの影響を切り分けます。新しいテスト項目では、個人用のマージ設定、スクリプト、拡張機能によるオーバーライドを一時的に適用しないでください。元のサブスクリプションは正常で、最終設定だけが失敗する場合は、オーバーライドを一つずつ戻し、問題のある項目を特定します。

手順5：ネットワーク経路とアカウントの状態を確認する

ログに接続タイムアウト、DNSの名前解決エラー、TLS証明書エラーが記録されている場合は、リクエストの段階に戻って確認します。ブラウザーでは拡張機能のプロキシ、キャッシュ、ログイン済みセッションが使われる一方、クライアントの更新処理では別のネットワーク経路を使うことがあります。結果が異なっても、それだけでURLが本物かどうかは判断できません。

直接接続と、現在利用できるプロキシを比較します。クライアントにサブスクリプション取得用のプロキシ設定がある場合は、それぞれでテストし、結果を記録してください。すでに使えないノードにサブスクリプションの更新を依存させないようにします。利用可能な回線がない場合は、スマートフォンのテザリングで現在のネットワークと比較できます。
システム時刻を確認します。日付やタイムゾーンが大きくずれていると、証明書の検証に影響します。まず時刻を同期し、エラーを回避するためにTLS証明書の検証を無効にしないでください。
DNSとネットワークのログインを確認します。ホテル、学校、公共Wi-Fiの認証ページがリクエストを遮断している場合があります。まずネットワーク認証を済ませてから再試行してください。HTMLが表示されたからといって、すぐにサブスクリプションの形式を変更しないでください。
サービス提供元のアカウントページを確認します。プランの有効期限、通信量、サブスクリプションのリセット履歴、メンテナンスのお知らせを確認してください。通信量を使い切った後にエラーが返るか、ノードが引き続き表示されるかはサービス提供元によって異なります。一律には判断できません。

複数のネットワークで同じURLにアクセスして同一の403や固定のエラー本文が返り、アカウントページにも認証の問題が表示されている場合は、クライアントの再インストールよりサービス提供元への問い合わせが近道です。現在の端末だけで失敗する場合は、ローカルの時刻、プロキシ設定、クライアントのリクエスト設定、コアのバージョンを優先して比較してください。

復旧後の確認：読み込み成功とノードの利用可能状態は別

修正後は手動で一度更新し、ダウンロードや解析のエラーがログに出なくなったことを確認します。次にノード数、プロキシグループのメンバー、providerの最終更新時刻を確認してからノードを選び、実際に接続できるかテストします。遅延テストの成功は、そのテスト用リクエストが成功したことを示すだけで、普段利用するWebサイトへの接続を保証するものではありません。

検証済みの設定をバックアップし、復旧時に使用したクライアントとコアのバージョンを記録します。
現在有効なのが修復したサブスクリプションであり、以前の設定が引き続き使われていないことを確認します。
自動更新のスケジュールを元に戻し、短時間に何度もリクエストしてレート制限にかからないようにします。
ローカルに保存した一時レスポンスファイルを削除します。サブスクリプションURL全体が公開された場合は、サービス提供元のアカウントページでトークンをリセットし、すべての端末のURLを更新してください。

問い合わせには「発生時刻、クライアントのバージョン、コアのバージョン、HTTPステータスコード、機密情報を隠した最初のエラー、複数のネットワークで再現するか」を伝えれば十分です。サブスクリプションURL全体、ノードのパスワード、レスポンス本文全体を公開の場に載せないでください。「URL → レスポンス → 構文 → コア → ネットワークとアカウント」の順に確認すれば、問題の箇所を特定しやすくなり、URLの更新、設定の修正、サーバーの復旧待ちのどれが必要か判断できます。