ダウンロード失敗・解析エラー・ノードなしを切り分ける
Clashのサブスクリプション読み込みは、クライアントからURLへリクエストを送り、応答本文を取得し、内容を変換または解析して設定として読み込み、最後にコアへ渡すという複数の段階で行われます。画面上の「更新失敗」だけでは、どの段階で問題が起きたのか分からないことがあります。まずクライアントのログを開き、失敗した時刻とエラー内容を記録してから、URLと設定のどちらを確認するか判断しましょう。
Windowsクライアントではメニュー名が統一されていません。サブスクリプションの項目は「サブスクリプション」または「プロファイル」、ログは通常「ログ」画面にあります。エラーが出たサブスクリプションを一度更新し、直後に同じ時刻付近のログを確認してください。ノードの遅延テスト失敗を、読み込みエラーと取り違えないようにしましょう。
| ログ・症状 | まず確認すること | すぐに行わないこと |
|---|---|---|
timeout、Could not resolve host | ネットワーク接続、DNS名前解決、更新リクエストの通信経路 | 最初にYAMLのインデントを変更しない |
| HTTP 401、403、404 | サブスクリプションのトークン、アクセス制限、URLの有効性 | クライアントを何度も再インストールしない |
yaml: line ...、unmarshal | 応答本文、フィールドの型、エラー行付近の構造 | ファイルの拡張子だけで形式を判断しない |
| 読み込みは完了したが、選択できるノードがない | proxies、proxy-providers、プロキシグループからの参照 | DIRECTを追加してノードを復旧させようとしない |
unsupported proxy type | コアの名称・バージョン・ノードのプロトコル | プロトコル名を別のプロトコルに安易に変更しない |
手順1：サブスクリプションURLとHTTP応答を確認する
アカウントページではなく、サブスクリプションURLをコピーする
- サービス提供元のサブスクリプションページに戻り、「Clash」または「Clash Meta／mihomo」と明記されたURLを選びます。
- URLを最初から最後までコピーし、先頭が
https://、またはサービスが明示しているhttp://であることを確認します。末尾に改行、日本語の句読点、余分な空白がないかも確認してください。 - クエリパラメーターがすべて含まれているか確認します。
&を含むURLが途中で切れると、最初のパラメーターしか残らないことがあります。ページのソースからコピーした場合は、&という文字列が混入していないかも確認してください。 - サブスクリプションのトークンを最近再発行した場合は、クライアント側のURLも更新してください。古いURLは、再度更新ボタンを押しても有効にはなりません。
URLに.yamlが付いていなくても、形式が誤っているとは限りません。逆に、末尾が.yamlでも、ログインページやエラーメッセージが返されることがあります。確認すべきなのは、サーバーのステータスコードと応答本文です。
Windowsで実際の応答内容を保存する
以下のコマンドはWindows PowerShellで実行します。PowerShellのバージョンによって異なるコマンドエイリアスとの混同を避けるため、システムのcurl.exeを使用します。まず、自分だけが使う一時フォルダーに移動してから実行してください。トークンを含むURLは入力プロンプトから読み込むため、コマンド履歴に直接残りません。
$url = Read-Host 'サブスクリプションURLを貼り付け'
curl.exe --location --max-time 30 --dump-header response-headers.txt --output subscription-response.txt -- "$url"
Get-Content .\response-headers.txt
Get-Content .\subscription-response.txt -TotalCount 12
Remove-Variable url--locationはリダイレクトを追跡し、--max-time 30はリクエスト全体のタイムアウトを30秒に設定します。応答ヘッダーが複数ある場合は、最後のステータスを確認してください。ファイルの保存に成功しても、有効なサブスクリプションを取得できたとは限りません。応答ヘッダーに機密性の高い転送先URLが含まれる場合もあるため、調査後は関連ファイルを削除してください。
- 200：応答本文を確認します。ログインページやサービス側のエラーでも200が返ることがあります。
- 301、302：最終的な転送先がログインページや認証ページではなく、サブスクリプションの内容であることを確認します。
- 401、403：トークンとアクセス制限を確認します。サーバー側の保護機能にリクエストを拒否されている可能性もあります。
- 404、410：サブスクリプションのURLが変更されていないか確認し、提供元にURLの状態を問い合わせます。
- 429：連続して更新するのをやめ、サーバーの案内に従って待ちます。リクエスト制限がさらに厳しくなるのを防ぎましょう。
ブラウザーで開けても、クライアントがダウンロードできるとは限りません。ブラウザーにはログインCookieが付与されていたり、別の通信経路が使われていたり、Web認証が済んでいたりする場合があります。ブラウザーで「正常」と表示されたアカウントページを、サブスクリプションが有効である根拠にしないでください。
手順2：応答がYAML・ノード一覧・Webページのどれかを見分ける
応答ファイルの冒頭を確認すると、原因を絞り込みやすくなります。Content-Typeは参考になりますが、YAMLを通常のテキストとして返すサービスもあるため、ヘッダーだけで判断しないでください。
| 内容の特徴 | 考えられる形式 | 対処方法 |
|---|---|---|
proxies:、proxy-groups:、rules: | Clashの設定またはその一部 | 構造、フィールド、コアとの互換性を確認する |
<!DOCTYPE html>、<html | ログインページ、認証ページ、エラーページ | サブスクリプションURLを修正するか、提供元に問い合わせる。YAMLに書き換えない |
ss://、vmess://などのリンクが1行ずつ並んでいる | ノード共有リンクの一覧 | クライアントが対応するインポート方法を選ぶか、Clash形式のURLを取得する |
| 長いエンコード済みテキスト | Base64形式のノード一覧、または別のデータ | 提供元の案内を確認する。見た目だけで設定ファイルとして読み込まない |
| JSON形式のエラー、期限切れの通知、または空の本文 | APIエラー、またはサブスクリプションが利用できない状態 | ローカル設定を調べる前に、サーバーの応答を解決する |
「ノードプロバイダーファイル」と「完全な設定ファイル」は別物です。前者にはproxiesの一覧だけが含まれ、メイン設定からproxy-providersで参照する形式がよく使われます。プロキシグループやルールが含まれないこともあるため、完全な設定として読み込めば、すべての振り分け先が自動生成されるとは限りません。
形式を変換する必要がある場合は、機能の説明が明確なクライアント内蔵の変換機能か、提供元が用意した形式別のURLを優先してください。トークン付きのサブスクリプションURLを、正体の分からないオンライン変換サービスに入力しないでください。変換サービスからURLや応答に含まれるノードの認証情報を読み取られるおそれがあります。
手順3：YAMLのインデント、引用符、フィールドの型を確認する
エラー行だけでなく、そのひとつ上の階層も確認する
エラーメッセージに表示される行番号は、パーサーが問題を検出した位置であり、最初に誤りが生じた位置とは限りません。たとえば、直前の行で引用符が閉じていなかったり、インデントがずれていたりすると、次の行でエラーになることがあります。ローカルのテキストエディターでファイルを開き、行番号と空白文字を表示して、該当行の前後5行を確認してください。
- 階層のインデントにはスペースを使い、Tabは使わないでください。各階層をスペース2個で統一すると読みやすくなりますが、最も重要なのは同じ階層の位置をそろえることです。
- フィールド名の後には半角の
:を使い、値との間に通常はスペースを入れます。例：mode: rule。 - リスト項目には半角ハイフンとスペースを使います。例：
- DIRECT。全角ダッシュでは代用できません。 - 文字列にコロンとスペース、特殊記号、誤認しやすい内容が含まれる場合は、引用符で囲みます。例：
name: "香港: 01"。 - 同じマッピング階層で
dnsやrulesなどのキーを重複して記述しないでください。重複キーの扱いはパーサーによって異なる場合があります。
階層構造の確認用として、直結テスト用の設定を以下に示します。リモートノードは含まれていないため、サブスクリプションが復旧したか、プロキシに接続できるかの検証には使えません。ローカルのテスト用コピーでのみ使用し、通常使っているサブスクリプションを上書きしないでください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: "ローカルテスト"
type: select
proxies:
- DIRECT
rules:
- MATCH,ローカルテストproxy-groupsはリストで、各プロキシグループはマッピングです。グループ内のproxiesもリストになります。rulesとproxy-groupsは同じトップレベルに置き、プロキシグループの中にインデントしないでください。ここでの7890は説明用の待ち受けポートです。実際のポートはクライアントの表示を確認してください。
構文が解析できても、フィールドの型が正しいとは限らない
リストを文字列として記述しても、YAMLとしては有効な場合がありますが、コアが要求する形式とは異なります。たとえば、proxies: "DIRECT"は上記のリスト形式とデータ型が異なります。cannot unmarshalと表示された場合は、空白だけでなく、該当フィールドが文字列・数値・真偽値・リスト・マッピングのどれを求めているかも確認してください。
元のサブスクリプションは読み込めるのに、オーバーライドを追加するとエラーになる場合は、まず対象サブスクリプションに関連付けられたオーバーライド、マージ、スクリプト処理を無効にし、その後ひとつずつ戻してください。クライアントに保存された元のサブスクリプションと、最終的にコアへ渡される設定は異なる場合があります。実際に適用される最終設定も確認してください。フィールドの詳しい説明はルール構文リファレンスとDNS設定リファレンスをご覧ください。
手順4：User-Agentとmihomoコアの対応状況を確認する
同じURLでも応答形式が変わることがある
サブスクリプションAPIの中には、リクエストヘッダーのUser-Agentからクライアントの種類を判定するものがあります。ブラウザー、コマンドラインツール、クライアントでは異なる内容が返る場合があるため、先ほどのコマンド実行結果は一度の確認にすぎず、クライアントが実際に受け取る応答と一致するとは限りません。
クライアントに「サブスクリプションのリクエストヘッダー」や「User-Agent」の設定がある場合は、まず現在の値を記録し、提供元のドキュメントを確認してください。以下のコマンドは比較用にリクエストヘッダーをmihomoに設定するものです。すべてのサービスに使える修正値ではなく、古いクライアントをmihomoコアに変えるものでもありません。
$url = Read-Host 'サブスクリプションURLを貼り付け'
curl.exe --location --max-time 30 --user-agent "mihomo" --output response-mihomo.txt -- "$url"
Get-Content .\response-mihomo.txt -TotalCount 12
Remove-Variable url標準のリクエストではノードリンク一覧が返り、ヘッダーを指定するとYAMLが返る場合、サーバー側で形式を振り分けていると考えられます。提供元が明示的にサポートするURLまたはリクエストヘッダーを使用してください。さまざまな識別文字列を次々に試すのは避けましょう。どちらのリクエストでも認証ページが返る場合、YAMLの変更やヘッダーの切り替えでは、通常サーバー側のアクセス制限を解決できません。
クライアントとコアのバージョンを別々に記録する
Clash、Clash Premium、Clash Meta（現名称：mihomo）では、対応する機能が異なります。設定にtype: hysteria2やtype: vlessなどのノードタイプがある場合は、現在のコアが該当プロトコルと各パラメーターに対応しているか確認してください。クライアントの画面を更新しただけでは、実行中のコアも切り替わっているとは限りません。
- クライアントの「バージョン情報」または「このアプリについて」画面で、クライアントのバージョンを記録します。
- コア情報または起動ログで、コアの名称と完全なバージョン番号を記録します。
- 該当バージョンの設定ドキュメントを参照し、特にプロトコルタイプと通信パラメーターを確認します。
- コアに対応したサブスクリプション形式を選ぶか、クライアントが正式に提供する更新機能でコアを更新します。
エラーを回避するためにtypeを削除したり、プロトコル名を書き換えたりしないでください。プロトコルタイプによって接続方式が決まるため、安易に変更すると、構造チェックを通過しても接続できないことがほとんどです。
手順5：読み込み成功後にノードがない場合は、参照関係を確認する
ノード一覧が空の場合は、まずサブスクリプションの元データにノードが含まれているかを確認し、次にクライアントの最終設定にもノードが残っているかを調べます。「ノードがダウンロードされていない」状態と、「ノードはあるが現在のプロキシグループから参照されていない」状態を区別してください。
- 直接ノード：
proxiesが空のリストになっていないか確認します。応答自体がproxies: []の場合は、まずアカウントの利用状態とサブスクリプションのフィルター条件を確認してください。 - リモートのノードプロバイダー：
proxy-providersのダウンロードログを確認します。メイン設定の取得に成功していても、各プロバイダーの更新に成功しているとは限りません。 - プロキシグループからの参照：
useでプロバイダーを参照する場合、名称はproxy-providers内のキーと一致させます。proxiesでノードを参照する場合も、ノード名が一致している必要があります。 - フィルター条件：自分で追加した名称フィルターを一時的に無効にします。正規表現、大文字・小文字、地域名の変更などにより、ノードが0件になる場合があります。
- マージ順序：オーバーライドによって、元のサブスクリプションのノードやプロキシグループが空のリストに置き換えられていないか確認します。クライアントごとにマージの仕組みは異なるため、リストが常に自動で追加されるとは限りません。
たとえば、プロキシグループでuse: [プロバイダーノード]を指定している一方、プロバイダー名がサブスクリプションノードになっている場合、両者は自動的に一致しません。参照関係を修正したら、該当するプロバイダーを更新してログを確認してください。メインのサブスクリプションだけを何度も更新しないでください。
再テストの手順と問い合わせ時のチェックリスト
どの変更が有効だったかを把握するには、一度にひとつの条件だけを変更してください。まずサブスクリプションの応答が正しいことを確認し、次にYAMLとコアの互換性を確認してから、オーバーライドや通信制御機能を戻します。以下の順で再テストすると、DNS、ポート、TUNを同時に変更するより原因を特定しやすくなります。
- テスト用サブスクリプションに元のURLを登録し、個人設定のオーバーライドを無効にして、一度更新します。
- ダウンロードや解析のエラーがログにないことを確認し、ノード数とプロキシグループの内容を調べます。
- 実際に使えるノードをひとつ選び、遅延テストを行います。テスト失敗はその後の接続に関する問題であり、サブスクリプションの解析エラーとは異なります。
- 必要に応じてシステムプロキシを有効にし、ブラウザーで接続を確認します。TUNが必要な場合は、別途有効にして対象アプリで動作を確認してください。
- カスタムルール、オーバーライド、フィルター設定をひとつずつ戻し、保存するたびにコアが正常に設定を読み込むか確認します。
サービス提供元やクライアントの開発プロジェクトへ問い合わせる際は、Windowsのバージョン、クライアントのバージョン、コアの名称とバージョン、失敗した時刻、HTTPステータス、エラーの種類をすべて記載し、「元のサブスクリプションだけで読み込めるか」も伝えてください。YAMLの問題については、階層構造を保った機密情報のない抜粋と元の行番号を添えると役立ちます。
サブスクリプションのトークン、サーバーのパスワード、UUID、ノードの完全なURL、応答ファイル全体を公開しないでください。URLが漏えいした場合は、まず提供元でトークンを再発行し、クライアントのサブスクリプションURLも更新してください。読み込み後の確認手順はサブスクリプションのインポート手順と接続確認ガイドをご覧ください。