Clashのサブスクリプション更新失敗・設定解析エラーの原因と確認手順

まず失敗した段階を特定：リクエスト、解析、設定の読み込み

「サブスクリプションの更新に失敗しました」という表示は、クライアントが処理結果をまとめたもので、URLが無効とは限りません。通常、更新ではURLへのリクエスト、応答の受信、設定の解析、上書き設定の適用、コアへの読み込みという手順を踏みます。設定によってはリモートのプロキシ一覧やルール一覧も参照され、それぞれ別にダウンロードされます。

トラブルシューティングを始める前に、現在動作している設定を残してください。サブスクリプションをすべて削除したり、システムプロキシ、TUNモード、DNSを次々と切り替えたりしないでください。一度に変更する条件を一つに絞り、更新時刻と対応するログを記録すると、どの段階で失敗したのか判断できます。

バックアップ：「サブスクリプション」または「設定」画面から現在の設定をエクスポートし、ローカルの上書き設定、スクリプト、ルールも別に保存します。エクスポートファイルにはノードの認証情報が含まれる場合があるため、アクセスを制限したフォルダーに保管してください。
再現：「ログ」を開き、一時的にログレベルをinfoにして手動で一度更新し、その前後に記録されたエラーを確認します。情報が足りない場合に限り、一時的にdebugを使用してください。
分類：まずHTTPステータスコードやネットワークエラーの有無を確認し、次にYAMLの行番号を見ます。最後に、プロキシグループ、ルール、フィールドに関するエラーを確認してください。
記録：クライアントのバージョン、実際に使用しているコアの名称とバージョンを控えます。クライアントのバージョンとmihomoのバージョンは別です。コマンドラインではmihomo -vを実行すると、その実行ファイルのバージョンを確認できます。

サブスクリプションへのリクエスト失敗：URLとHTTP応答を確認

ステータスコードと次の対処

サービス提供元のアカウントページから、サブスクリプションURL全体をコピーし直してください。パラメーターを手作業で追加・変更しないでください。URL内のトークン、クエリパラメーター、パスは、いずれも応答に影響する可能性があります。チャットアプリによる改行、コピー時に入った空白、&を誤って&と入力することなどで、別のリソースを指す場合があります。

応答またはログ	よくある原因	確認する順番
`401` / `403`	認証失敗、トークンの無効化、アクセス制限による拒否	アカウントの状態を確認してURLを取得し直し、デバイスやクライアントの利用制限も確認します。403はゲートウェイやセキュリティ対策ページが返している場合もあります。
`404` / `410`	パスが存在しない、またはリソースが削除されている	アカウントページから新しいURLを取得してください。元のURLのドメインだけを書き換えても解決しません。
`429`	リクエスト回数の制限	続けてリクエストせず、`Retry-After`またはサーバー側の案内を確認してから再試行してください。
`500` / `502` / `503`	サーバーまたは上流サービスの障害	現在の設定を残して時間をおいて再試行し、サービス提供元のお知らせも確認してください。
`200`でも解析に失敗	応答は受信できても、内容が設定とは限りません	本文がログインページ、認証ページ、エラーを示すJSON、または別形式のサブスクリプションではないか確認してください。

ブラウザーで開けても、クライアントで更新できるとは限らない

ブラウザーではログインCookieが送信されたり、Webページの認証を通過したり、拡張機能によって別のプロキシ経路が使われたりすることがあります。一方、クライアントのサブスクリプション取得リクエストには、通常こうした条件がありません。そのため、ブラウザーで表示できても、クライアントからサブスクリプションAPIにアクセスできる証明にはなりません。301や302が返された場合は、遷移先がログインページではなくサブスクリプションリソースであることを確認してください。

元の応答を確認する必要がある場合は、macOSまたはLinuxのBashターミナルで次のコマンドを使用できます。URLはコマンド履歴に直接記録されず、リダイレクトも自動で追跡しません。まず応答ヘッダーを確認し、必要に応じて遷移先にアクセスしてください。このコマンドは直接接続経路の診断用です。すべてのクライアントが直接接続で更新するわけではありません。

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

response.headersとresponse.bodyには、機密情報が含まれる場合があります。ローカル環境だけで確認し、診断後は削除してください。サブスクリプションURLを公開変換サイトに貼り付けたり、応答全体を公開オンラインYAMLチェッカーに送信したりしないでください。

ネットワーク・TLSエラー：直接接続とプロキシ経路を分けて確認

HTTP応答を受信できていない場合は、まずネットワーク接続を解決してください。システムプロキシの設定が適用されるのは、その設定に従うリクエストだけです。クライアントが独自のダウンロード機能を使ってサブスクリプションを取得する場合もあります。TUNモードは一部の通信経路を変更しますが、期限切れのトークン、形式の不一致、YAMLの構文エラーは解決できません。

no such host：ドメイン名を解決できません。サブスクリプションのドメイン名に誤りがないか確認し、システムDNSとクライアントのDNSログも調べてください。名前解決の失敗をノードのプロトコルエラーと混同しないようにしてください。
connection refused：接続先から接続を拒否されています。ログに127.0.0.1:7890と表示されている場合は、サブスクリプションをすぐに変更せず、まずローカルプロキシがそのポートで待ち受けているか確認してください。
i/o timeout、context deadline exceeded：接続、TLSハンドシェイク、または応答の読み込みがタイムアウトしています。クライアントの直接接続による更新とプロキシ経由の更新をそれぞれ一度だけ試し、結果を記録してください。
x509、証明書の期限切れ、ホスト名の不一致：システムの日付、時刻同期、サブスクリプションのドメイン名、ネットワーク上でHTTPS通信を検査するソフトウェアを確認してください。証明書の検証を無効にして問題を隠さないでください。

更新にプロキシが必要なのに、現在のサブスクリプションを読み込めない場合、起動に必要な通信が循環依存することがあります。利用可能なノードがないため、代わりの設定をダウンロードできない状態です。その場合は、以前保存した利用可能な設定に戻してからプロキシ経由で更新するか、サービスが対応していればアクセス可能な直接接続用URLを使ってください。クライアントのデータを何度も消去するより、古い設定を残しておくほうが復旧しやすくなります。

応答形式の不一致：完全な設定とノード一覧を見分ける

HTTP 200はリクエストの成功を示すだけで、返された内容を現在のインポート方法で利用できるとは限りません。ローカルのテキストエディターで応答の先頭とトップレベルのフィールドを確認し、サービス提供元が案内する形式と照らし合わせてください。ファイルの拡張子だけで判断しないでください。

応答の特徴	考えられる内容	対処方法
`<!DOCTYPE html>`または`<html`	ログインページ、認証ページ、Webサイトのエラーメッセージ	正しいサブスクリプションAPIのURLを取得してください。WebページをYAMLとして保存してインポートしないでください。
長いエンコード文字列、または1行ずつ並んだプロトコルURL	他のクライアント向けのノードサブスクリプション	アカウントページでClash、またはサービスがmihomo互換として案内している出力形式を選択してください。
`proxies:`だけのノード一覧	ノード一覧ファイルの可能性があります	完全な設定として直接有効にするのではなく、`proxy-providers`から参照する形式か確認してください。
`proxy-groups:`、`rules:`などのフィールドを含む	完全な設定の可能性があります	構文、参照関係、コアとの互換性を引き続き確認してください。フィールドがあるだけでは動作するとは限りません。

メイン設定を読み込める一方、ログに表示された失敗URLがproxy-providersまたはrule-providersに属している場合は、問題が参照先のリソースにあり、メインのサブスクリプションとは限りません。ノード一覧とルール一覧では内容の構造も異なります。該当するproviderのurl、format、behaviorと実際の応答を確認し、ルール一覧をノード一覧として解析しないようにしてください。

YAMLの解析エラー：行番号、インデント、値の型を確認

yaml: line …、did not find expected key、cannot unmarshalは、テキスト構造やデータ型の問題を示すことが一般的です。ログの行番号は、パーサーが異常を検出した位置です。実際の原因は直前の行にある場合もあります。たとえば、引用符の閉じ忘れ、リストの階層の誤り、コロンの後にスペースがない場合などです。

まず確認する4項目

インデント：Tabではなく半角スペースを使います。各階層にスペース2個を使うのが一般的ですが、YAMLで許可される幅がそれに限定されるわけではありません。同じ階層のフィールドは位置をそろえてください。
句読点：フィールドには半角コロンを使い、キーと値の間にスペースを入れます。全角コロンや曲線引用符を設定にコピーしないでください。
データ型：ポートには通常、7890のような整数を指定します。真偽値はtrueまたはfalse、リスト項目は- で始めます。リスト全体を文字列として記述すると、型エラーが発生することがあります。
名前と特殊文字：名前に: や #などが含まれる場合は、適切に引用符で囲んでください。プロキシグループから参照する名前は、スペース、大文字・小文字、記号まで一致させる必要があります。

以下は問題を切り分けるための直接接続用設定で、サブスクリプションのノードは含みません。ローカルのコアが基本的なYAMLを読み込めるか確認するもので、プロキシの接続確認には使いません。ポート7890が使用中の場合は、使用しているプログラムを停止するか、テスト用コピーで空いているポートを指定してください。

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

rules:
  - MATCH,DIRECT

設定をUTF-8のテキストファイルprofile.yamlとして保存します。mihomoでは、次のコマンドで設定をテストできます。Windows PowerShellでは、実行ファイルが現在のディレクトリにある場合、.\mihomo.exe -t -f .\profile.yamlを使用できます。

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

テストには、できるだけクライアントが実際に使用しているものと同じコアと作業ディレクトリを使ってください。リモートproviderや相対パスを含む場合、ネットワーク、キャッシュ、ファイルパスもテスト結果に影響することがあります。テストに通っても、その設定で今回のチェック時に致命的な問題が見つからなかったというだけで、すべてのノード、DNS、ルールのダウンロードが正常と確認されたわけではありません。

構文エラーがなくても読み込めない場合：コア、上書き設定、参照先を確認

クライアント名だけではコアとの互換性は判断できない

従来のClashとClash Meta（現mihomo）では、利用できる機能の範囲が異なります。また、プロトコル、通信方式のパラメーター、ルールのフィールドはバージョンによって対応状況が変わることがあります。unsupported proxy typeが表示された場合は、ノードの種類と実際に動作しているコアを確認してください。ファイル名を.yamlに変えても、プロトコルへの対応が追加されるわけではありません。

未知のフィールドをどう扱うかは、コアのバージョンと設定内の位置によって異なります。無視される場合もあれば、エラーになる場合もあります。そのため、「インポート成功」と表示されても、新しいフィールドが適用されたとは限りません。まずサービス提供元が互換性を明記している形式を使い、コアのリリースノートを確認して更新を判断してください。認識されないフィールドをむやみに削除しないでください。

エラーの対象に応じて依存関係を確認

proxy … not found：プロキシグループまたはルールが参照する名前を確認してください。サブスクリプションの更新後にノード名が変更され、ローカルの上書き設定が古い名前を参照していると、参照先が見つからなくなることがあります。
providerが見つからない：use:の参照先がproxy-providers内のキー名と一致しているか確認してください。設定のマージ時にprovider定義全体が上書きされていないかも確認します。
ルールの参照先が存在しない：ルール末尾のポリシー名とプロキシグループ名を照合してください。たとえばルールが特定のグループを参照する場合、完全に同じ名前のグループが必要です。似た名前のグループがあるだけでは使えません。
address already in use：通常は実行時のポート競合であり、サブスクリプション形式のエラーではありません。混合ポート、DNSの待ち受けポート、コントローラーのポートが他のプロセスと競合していないか確認してください。

ダウンロードした元の設定はテストに通るのに、クライアントで有効にするとエラーが出る場合は、「上書き」「マージ」「スクリプト」機能を重点的に確認してください。まず設定をエクスポートし、これらの機能を一時的に無効にして、加工していない設定をテストします。その後、一つずつ元に戻してください。スクリプトによるノード名の変更、proxy-groupsの上書き、存在しないルールの参照先の追加などに注意してください。

更新復旧後の確認と問い合わせ用チェックリスト

エラー表示が消えたら、最後に一通り動作を確認してください。「更新成功」だけではproviderのダウンロード失敗や空のプロキシグループを見落とすことがあります。Webページが開いても、通信が直接接続ルールを通っただけかもしれません。

サブスクリプションの更新時刻が変わったことを確認し、ノード数、プロキシグループ、ルールが想定どおりか確認してください。
対象の設定を有効にし、同じ時間帯のログを確認して、新たな設定読み込みエラーやprovider更新エラーがないことを確かめてください。
「接続」画面からアクセス先に一度接続し、適用されたルール、出力ポリシー、ノード名を確認して、実際の通信経路を特定してください。
一時的に無効にした上書き設定やスクリプトを戻し、一つ戻すたびに動作を確認してください。最後にログレベルを普段の設定に戻します。

クライアントの開発者やサブスクリプションサービスに問い合わせる際は、クライアントとコアのバージョン、OS、更新時刻、HTTPステータスコード、機密情報を伏せたエラー行全体を伝えてください。設定の一部を共有する場合は、該当箇所のインデントと参照関係を保ちつつ、サブスクリプショントークン、パスワード、秘密鍵、ノードのサーバーアドレスを削除してください。特定のバージョンへのアップデート後にだけ発生する場合は、更新前後のバージョンも記載します。

確認は、まずリクエストが届いているか、次に応答が想定した形式かを調べ、その後YAMLの構文とコアの互換性を確認し、最後に上書き設定と実行環境を調べる順に進めます。それぞれの段階で該当する情報に絞って対処すれば、ポート、DNS、TUNを同時に変更するより原因を特定しやすくなります。インストールや設定の手順を確認するにはクライアントガイドを、用語や基本事項を確認するにはよくある質問をご覧ください。