まずは「ダウンロード失敗」「解析失敗」「設定の読み込み失敗」を切り分ける

Clashクライアントに「サブスクリプションの取得に失敗しました」と表示されても、URLの期限切れとは限りません。通常、インポートではURLへのリクエスト、コンテンツの受信、設定の解析、コアによる読み込みが順に行われます。どの段階でエラーが起きたかによって、ネットワーク、テキスト形式、コアとの互換性のどれを確認すべきかが変わります。

  1. 使えている設定は残しておく。古いサブスクリプションを削除したり、手元にある唯一のバックアップを上書きしたりしないでください。更新に失敗しても、既存の設定はそのまま使える場合があります。
  2. エラーの詳細を記録する。クライアントのログやインポート時のメッセージで、発生時刻、HTTPステータスコード、エラー項目、行番号を確認します。「失敗」とだけ書かれた画面では原因を特定できません。
  3. クライアントとコアを確認する。クライアント名とバージョン、コアがClash Meta（現名称：mihomo）かどうかを記録します。画面に表示されるクライアントのバージョンと、コアのバージョンは別です。
  4. 変更は一度に一つだけ。まずURLとレスポンスを確認し、次にYAML、最後にプロキシグループとルールを調べます。複数の設定を同時に変更せず、変更のたびに手動で更新してください。

エラーメッセージに応じて確認する

クライアントによって表示される文言は異なりますが、主な原因は次の表のように分類できます。ステータスコードが示すのはサーバーの応答であり、アカウント残高、契約期限、利用可能な端末数を単独で判断できるものではありません。

エラー・症状 まず確認すること 次の対応
401、403 認証失敗、アクセス制限、セキュリティ対策によるブロック サブスクリプションURLをコピーし直し、アカウントの状態とサービス提供元の案内を確認する
404、410 URLの無効化、パスの変更、リソースの削除 管理画面から現在のURLを取得する。古いブックマークは使わない
429 リクエストが多すぎる 連続で更新せず、サーバーの案内に従って待ってから再試行する
timeout、no such host 接続タイムアウト、またはドメイン名を解決できない ネットワークを切り替え、直接接続とプロキシ経由での更新結果を比較する
x509、証明書エラー システム時刻、証明書チェーン、HTTPS通信の検査・遮断に問題がある 時刻を合わせ、ネットワーク認証と証明書の状態を確認する
yaml: line … テキストの構文エラー、または設定以外のレスポンス 返された内容と、該当行の前後を確認する
unsupported proxy type コアがノードのプロトコルまたはフィールドの組み合わせに対応していない 設定の要件と、実際に動作しているコアを照合する
参照先のプロキシグループまたはルールが存在しない 名前の不一致、ノードのフィルタリング、設定の不足 ノード、プロキシグループ、ルールの参照関係を確認する

サブスクリプションURLを確認する：アドレス全体をコピーし、アカウントの状態も確認

コピー間違いとURLの選択ミスを確認する

サービス提供元の管理画面に戻り、サブスクリプションURLのコピー機能を使います。URLの先頭がhttps://か、末尾に改行、空白、日本語の句読点が混ざっていないか確認してください。疑問符以降のパラメーターを手動で削除したり、チャットアプリに表示された省略済みの文字列を完全なURLだと思い込んだりしないでください。

  • 管理画面とサブスクリプションAPIを区別する：アカウントページを開けても、クライアントが設定を取得するためのURLを入手できたとは限りません。
  • 単一ノードとサブスクリプションを区別する：ss://やvmess://などはノード共有用URIの場合があり、更新可能な完全なClash設定とは限りません。
  • URLが再発行されていないか確認する：パスワードの変更、サブスクリプショントークンの再発行、サービスの移行後は、古いURLが無効になっていることがあります。
  • サービスの状態を確認する：管理画面に期限切れ、通信量の上限到達、サービス停止などの明示的な案内がないか確認します。クライアントのエラーだけで判断しないでください。

ブラウザーでは開けるのに、クライアントで失敗するのはなぜ？

ブラウザーにはログインCookieが保存されていたり、Webページの認証を自動で通過していたりする場合があります。一方、クライアントからのリクエストには同じログイン状態が引き継がれないことがあります。ブラウザーに「アクセス成功」と表示されても、実際にはログインページ、認証画面、サブスクリプションの案内ページが返されている可能性があります。ページが開くかどうかだけでなく、レスポンスが設定テキストかを確認してください。

ステータスコードが200でも、レスポンスが<!DOCTYPE html>で始まるHTMLだったり、エラー説明を含むJSONだったりする場合があります。この場合、YAMLエラーは後から現れた症状にすぎません。対処すべきなのはAPIへのアクセスやアカウント認証です。

サブスクリプションの形式を確認する：Clash設定とノードリストは別物

完全なClash設定は通常YAMLのマッピング形式で、トップレベルにproxies、proxy-groups、rulesなどのフィールドを含みます。一方、Base64でエンコードされたノードリストや、ほかのクライアント専用の設定を返すサブスクリプションもあります。どれも「サブスクリプション」と呼ばれることがありますが、同じ方法でインポートできるとは限りません。

完全な設定、ノードプロバイダー、単一ノードの違い

  • 完全な設定：通常、クライアントの設定またはサブスクリプション管理からインポートし、プロキシグループやルールなどの動作設定を提供します。
  • ノードプロバイダーファイル：proxy-providersから参照するもので、通常はproxiesの一覧が中心です。単体で完結する設定一式とは異なります。
  • 単一ノードのURIまたはエンコード済みリスト：クライアントが該当するインポート方法に対応している必要があります。対応していない場合は、サービス提供元からClashまたはmihomoに対応した形式を入手してください。

現在使っているクライアントまたはコアに対応すると明記されたURLを優先してください。サービスによってはリクエストのUser-Agentに応じて異なる形式を返すため、同じURLでもブラウザーとクライアントでレスポンスが変わることがあります。適当にリクエストヘッダーを偽装して試すのではなく、まずサービス提供元の接続手順を確認してください。

YAMLを確認する：まずエラー行を見て、その直前も確認

レスポンスが実際に設定ファイルだと確認できてから、YAMLの調査に進みます。設定をローカルに保存し、行番号、スペース、タブを表示できるエディターで開いてください。パーサーが示す行番号は「解析を続けられなくなった場所」です。原因はその直前の行にある引用符、コロン、インデントかもしれません。

よくある構文エラーと正しい書き方

  1. インデントにはスペースを使う。各階層はスペース2つを目安にし、階層の指定にTabを使わないでください。同じ階層のフィールドは位置をそろえます。
  2. コロンの後にスペースを入れる。mixed-port: 7890はキーと値の記述です。mixed-port:7890では同じマッピング構造になりません。
  3. 半角の記号を使う。全角のコロン、曲がった引用符、全角スペースは構文を変えてしまいます。リッチテキストエディターで設定を編集しないでください。
  4. リストのハイフンを確認する。rulesなどのリスト項目には- が必要です。ハイフンの後のスペースを忘れないでください。
  5. トップレベルのキーを重複させない。同じ名前のdnsやrulesを2つ目として追加しないでください。重複キーの扱いはパーサーによって異なる場合があります。

以下は基本的なフィールドの構文例です。リモートノードは含まず、サブスクリプションの代わりにはなりません。ポート、モード、ネストしたフィールド、ルールリストの階層を示しています。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

ここでの7890は待ち受けポートの例であり、サブスクリプションのダウンロード用ポートではありません。変更しても、リモートサブスクリプションの解析エラーは通常解決しません。例にあるDNSアドレスがすべてのネットワークで利用できるとも限りません。実際の設定ではネットワーク環境に合わせて選び、インデントを直すために既存のDNS設定を丸ごと置き換えないでください。

構文を通過しても、名前の参照関係を確認する

YAMLを読み込めても、コアが必ず設定を読み込めるとは限りません。たとえばルールがMATCH,Proxyなら、設定内にプロキシグループなど、有効な送信先としてProxyが存在する必要があります。グループ名の大文字・小文字、空白、記号を一致させてください。ノードのフィルターですべての候補が除外されている場合は、プロキシグループに選択可能なノードが残っているかも確認します。

サブスクリプションから生成されたファイルをローカルで編集すると、次回の更新で変更が上書きされることがあります。変更を継続して維持するには、クライアントが対応するオーバーライド、マージ、拡張設定の仕組みを使い、適用範囲を事前に確認してください。

ネットワークを確認する：サブスクリプションの取得とノード接続を分けてテスト

ノードに接続できても、サブスクリプションのドメインにアクセスできるとは限りません。サブスクリプションをダウンロードできても、すべてのノードが使えるとは限りません。ログにタイムアウト、DNS名前解決、TLSのエラーがある場合は、まずリクエスト経路を確認してください。すぐにノードのプロトコルやルーティングルールを変更する必要はありません。

  1. 通常のWebページにアクセスできるか確認する。公衆Wi-Fiでは、先にブラウザーで認証が必要な場合があります。システムの日付やタイムゾーンが間違っていると、HTTPS証明書の検証に失敗することもあります。
  2. ネットワークを切り替えて比較する。たとえば、家庭のブロードバンド回線からスマートフォンのテザリングに切り替え、同じクライアントで手動更新します。ほかの設定は変えずネットワークだけを切り替えると、現在のネットワークによる制限かどうか判断しやすくなります。
  3. 直接接続とプロキシ経由の更新を区別する。クライアントでサブスクリプション更新時の接続方法を選べる場合は、それぞれを試してください。更新リクエストがシステムプロキシを経由しないクライアントもあります。システムプロキシのオン・オフだけで実際の通信経路を判断しないでください。
  4. 使われていないローカルプロキシを確認する。Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシのアドレスを確認できます。停止中の127.0.0.1:7890が設定されたままだと、その設定に従うリクエストは失敗することがあります。実際のポートはクライアントで確認してください。
  5. 更新できなくなる悪循環を避ける。既存のプロキシ経由でしかサブスクリプションを取得できない場合は、更新する前に使える設定をバックアップしてください。古い設定を削除すると、サブスクリプションのリクエストに使える経路まで失われることがあります。

429が発生したら、更新ボタンを何度も押すのはやめてください。サーバーがRetry-Afterを返している場合は、指定された時間だけ待ちます。5xxが発生した場合は、時刻とステータスコードを記録してサービス提供元に問い合わせてください。連続更新ではサーバー側のエラーは直らず、制限がさらに厳しくなる可能性があります。

インポート後の確認と問い合わせに必要な情報

インポートに成功したのは設定が受け付けられたという意味であり、通信がその設定で処理されているとは限りません。現在選択されている設定を確認し、プロキシグループ、ルールモード、システムプロキシまたはTUNの状態を確認してください。TUNは通信を取り込むための機能であり、サブスクリプションのテキスト形式を修正するものではありません。

3つの段階に分けて動作を確認する

  • 設定：最終更新時刻が変わったこと、ノードとプロキシグループが正常に表示されること、ログに構文エラーや参照エラーが残っていないことを確認します。
  • 接続：ノードを1つ選んで疎通をテストします。遅延テストの失敗とサブスクリプションの解析失敗は別の段階で起きるため、分けて記録してください。
  • 通信：プロキシ経由になる想定のサイトにアクセスし、接続ログで適用されたルールと実際の送信先を確認します。ルールモードでは、一部のリクエストが直接接続されるのは通常の動作です。

解決しない場合は、次の情報を添えて問い合わせる

サービス提供元またはクライアントの開発者に問い合わせる際は、クライアントのバージョン、コアのバージョン、OSのバージョン、エラー発生時刻、HTTPステータスコード、機密情報を伏せたエラー全文を伝えてください。YAMLの行番号が表示された場合は、該当行と前後3行を機密情報を伏せて共有します。ネットワークの問題なら、直接接続、プロキシ経由、スマートフォンのテザリングで試した結果も伝えてください。

「Clashが使えない」とだけ伝えたり、サブスクリプションファイル全体を公開したりしないでください。「リクエスト失敗」「解析失敗」「読み込み失敗」「接続失敗」を明確に分けて伝えると、状況確認のやり取りを減らせます。通信を取り込む設定を確認する場合は、システムプロキシの設定手順をご覧ください。設定項目や通信が途切れる問題は、トラブル対処ガイドのconfig.yamlの項目で確認できます。