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

1. まずエラーを記録し、失敗した段階を特定する

サブスクリプションの更新は一度の処理で完了するわけではありません。クライアントがURLにアクセスして応答を解析し、設定とコアの互換性を確認した後、ノードやプロキシグループ、外部リソースを読み込みます。画面に表示される「更新失敗」は、どの段階でも起こり得ます。クライアントを何度も再インストールするより、まず失敗箇所を特定しましょう。

クライアントの「サブスクリプション」または「プロファイル」画面を開き、エラーが出た設定カードを探して、最終更新日時と設定名を記録します。
「ログ」を開き、古い記録を消去するか現在時刻を控えます。設定カードに戻り、「更新」を一度だけクリックしてください。クライアントによっては「再読み込み」や「サブスクリプションを更新」と表示されます。
ログに戻り、操作後に最初に記録されたエラーを確認します。エラーの種類、HTTPステータスコード、行番号、フィールド名を控え、「失敗」と表示された最後の行だけを切り取らないでください。

ログまたは画面の表示	発生している段階	優先して確認する項目
`no such host`	ドメイン名の解決	サブスクリプションのドメイン名、使用中のネットワークのDNS
`timeout`、`deadline exceeded`	接続または応答待ち	取得先への経路、ネットワーク、サーバーの応答
HTTP 401、403、404、429	サーバーから拒否またはエラーが返された	URLのアクセス権、有効期限、リクエスト頻度
`yaml: line 12`	応答内容の解析	実際の応答本文、12行目付近のインデント
`unsupported proxy type`	設定の互換性チェック	プロトコルの種類と実際に動作しているコア
更新は完了したがノードが空	設定の読み込みまたはノードプロバイダーの更新	有効な設定、フィルター条件、providersのログ

2. URLを確認：コピーしたものがサブスクリプションURLか確認する

1. サービスの管理画面からClash形式のURLをコピーする

サブスクリプション提供元のアカウント画面を開き、「サブスクリプション」→「URLをコピー」を選択します。出力形式はClashまたはMihomoと明記されたものを選んでください。アカウントのトップページ、プラン購入ページ、QRコード画像のURLは設定URLとして使えません。QRコードにはクライアントを起動するためのインポートコマンドが含まれている場合もあるため、管理画面に表示された元のHTTPSサブスクリプションURLを使いましょう。

先頭が完全な https:// になっているか、末尾にスペースや改行、チャットアプリが付けた句読点が混入していないか確認します。
? 以降のクエリパラメーターは残してください。トークンはパラメーターやパスに含まれていることが多く、削除すると401または403が返る場合があります。
URLを再発行した場合、古いURLはすぐに無効になることがあります。既存設定のサブスクリプションURLを編集してから更新し、同じ名前の古い設定を誤って選ばないようにしてください。
アカウントの有効期限と通信量の状態を確認します。提供元によってはステータスコードや説明文で利用停止の理由が示されます。詳細はアカウント画面で確認してください。

2. ステータスコードだけでなく、応答内容も確認する

401は通常、有効な認証情報が必要であることを示します。403はアクセス制限、トークンの権限不足、セキュリティ対策によるブロックなどが考えられます。404はURLのパスが変更された場合のほか、無効なリソースを隠すためにサーバーが返すこともあります。429が返ったら、連続更新を止めてサーバーの案内に従って待ちます。応答に Retry-After が含まれている場合は、その値に従ってください。5xxは通常、提供元によるサーバー側の確認が必要ですが、中継ゲートウェイがエラーページを返していないかも確認しましょう。

HTTP 200はリクエストが成功応答を受け取ったことを示すだけで、本文がClashの設定とは限りません。本文が <!DOCTYPE html> で始まる場合や、ログイン画面、認証コード、プランの説明が含まれる場合、解析対象はWebページです。この状態でYAMLのインデントを直しても解決しません。まずURLまたはサーバーの応答内容を確認してください。

3. ネットワークを確認：直接接続・プロキシ・DNSを分けて試す

ブラウザーでアカウント画面を開けても、クライアントがサブスクリプションを取得できるとは限りません。管理画面とサブスクリプションで異なるドメインが使われている場合があります。また、ブラウザー、クライアントの画面プロセス、コアでネットワーク経路が異なることもあります。ほかの設定は変えず、項目ごとに比較して確認しましょう。

システム時刻を確認します。システムの「日付と時刻」で自動設定を有効にしてください。日付が大きくずれていると、TLS証明書の有効期間を確認できないことがあります。
取得方法を確認します。設定カードのメニューやサブスクリプション設定から、「プロキシ経由で更新」「更新方法」などの項目を探します。機能がある場合は、直接接続と現在利用できるプロキシ経由の両方で更新し、結果を記録してください。
別のネットワークで再試行します。利用が許可されたネットワーク環境で、パソコンを一時的にスマートフォンのテザリングへ接続し、同じサブスクリプションを更新します。特定のネットワークだけで失敗する場合は、そのネットワークの名前解決、認証、アクセス制限を優先して確認してください。
ローカルのプロキシポートを確認します。クライアントの「設定」でポート情報を開き、HTTPまたはmixedポートが実際に待ち受けていることを確認します。ネット上の既定値をそのまま使わないでください。

端末のコマンドで接続と応答の問題を切り分ける

コマンドラインに慣れている場合は、端末で2種類のリクエスト経路を比較できます。以下の例ではサブスクリプションURLを対話形式で入力するため、URL全体がコマンド履歴に残りません。プロキシポート 7890 は例です。クライアントに表示されているHTTPまたはmixedポートに変更してください。一般的なBash、Zsh環境で動作し、応答は現在のディレクトリにローカルファイルとして保存されます。

printf 'サブスクリプションURLを入力：'
IFS= read -r SUB_URL
curl --noproxy '*' --location --connect-timeout 10 --max-time 30 \
  --output subscription-direct.txt --write-out 'HTTP %{http_code}\n' "$SUB_URL"
curl --noproxy '' --proxy http://127.0.0.1:7890 --location \
  --connect-timeout 10 --max-time 30 \
  --output subscription-proxy.txt --write-out 'HTTP %{http_code}\n' "$SUB_URL"
unset SUB_URL

ここでは比較しやすい診断条件として、接続タイムアウトを10秒、全体の待ち時間を30秒に設定しています。すべてのクライアントに推奨する共通設定ではありません。ファイルにはノードのパスワードやトークンが含まれる場合があります。確認後は適切に削除し、公開リポジトリに同期しないでください。コマンドでのテストでは、クライアントのUser-Agent、リクエストヘッダー、コアのルーティングを完全には再現できません。結果に差があれば手がかりとして扱い、どちらかに問題があると即断しないでください。

ログに no such host と表示されたら、まずシステムでサブスクリプションのドメイン名を解決できるか確認します。リクエストがまだコアに届いていない場合、YAMLの dns: を変更しても反映されないことがあります。TUNは一部の通信を処理する経路を変えますが、期限切れのトークンや形式エラーは解決できません。確認中はTUN、DNS、ルールモードを同時に切り替えないでください。

4. 形式を確認：YAMLエラーとコアの非互換を切り分ける

受信したものが完全な設定か、ノード一覧かを確認する

Clashの完全な設定には、トップレベルに proxies、proxy-groups、rules などのフィールドがよく使われます。proxy-providers で外部ノードを参照する場合もあるため、ノードが設定内に直接記述されていないだけで内容が空とは限りません。一方、プロトコル形式の共有リンクが並んだもの、汎用Base64形式のサブスクリプション、provider専用のノード一覧は、そのまま有効化できる完全な設定とは異なります。

クライアントのインポート画面で必要な形式を確認し、サブスクリプション提供元の出力形式と照合してください。クライアントが自動変換に対応すると明示していない場合は、対応する形式を選びます。変換が必要な場合は、提供元が正式にサポートする方法か、信頼できるローカル処理を優先してください。見知らぬオンラインサービスにアクセストークンを渡さないようにしましょう。

エラー行のインデントとデータ型を確認する

ログの行番号は確認を始める目安で、エラーが必ずその行にあるとは限りません。たとえば12行目のエラーは、11行目の引用符が不足していることが原因かもしれません。YAMLのインデントにはスペースを使い、Tabは避けてください。コロンの後は適切に区切り、リスト項目の前にはハイフンを付けます。以下は階層を示す断片であり、単独では完全なサブスクリプションとしてインポートできません。

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "ノード A"
rules:
  - "MATCH,手動選択"

mapping values are not allowed：コロンやインデント、直前の行で引用符が閉じているかを確認します。
cannot unmarshal：フィールドが文字列、リスト、マップのどれを要求しているか確認します。スペースだけを調整しても解決しません。
プロキシグループが存在しない項目を参照していると表示されたら、ノード名とグループ名の大文字・小文字、スペース、記号が完全に一致しているか確認します。
リモートサブスクリプションをダウンロードした後のキャッシュファイルだけを変更しても、次回の更新で上書きされることがあります。元の設定またはクライアントが対応するオーバーライド層を編集してください。

実際に動作しているコアを確認する

「設定」→「このアプリについて」またはクライアントのコア情報画面を開き、クライアントとコアそれぞれのバージョンを記録します。両者は別のバージョン番号です。Clash Metaは現在、一般にmihomoと呼ばれています。系統やバージョンによって、対応するプロトコルやフィールドは異なります。unsupported proxy type が表示された場合は、エラーに記載されたプロトコルの互換性を確認してください。フィールドを削除して無理に読み込ませないでください。

クライアントやコアを変更する前に設定をバックアップし、信頼できる配布元から対応バージョンを入手してください。使用中の端末で必要なコアを利用できない場合は、提供元に互換性のある出力形式があるか問い合わせましょう。画面のアプリを更新しただけでは、実際に動作するコアが切り替わらないことがあります。更新後はコア情報画面で確認してください。

5. 更新済みなのにノードが空：有効な設定とprovidersを確認する

「サブスクリプションの更新完了」は、メイン設定をダウンロードできたことを示すだけで、設定が参照するすべてのリソースを取得できたとは限りません。特に proxy-providers を使う場合、ノードファイルは別のリクエストで取得されるため、URL、キャッシュ、更新間隔が独立していることがあります。

現在有効な設定を確認します。「設定」または「サブスクリプション」画面に戻り、選択中のマークが更新した設定に付いているか確認してください。設定Aを更新しても、設定BからAへ切り替わったとは限りません。
すべてのプロキシグループを確認します。「プロキシ」画面を開き、ノードを参照しているグループを展開します。ホーム画面には現在のポリシーだけが表示され、すべてのノードは表示されない場合があります。
providerの状態を確認します。クライアントに「プロキシプロバイダー」画面がある場合は、ノード数、更新日時、エラーを確認してください。専用画面がなければ、ログでprovider名とダウンロードエラーを探します。
フィルター条件を確認します。正規表現フィルターですべてのノードが除外されている可能性があります。まずバックアップまたはローカルオーバーライドで該当する条件を外してテストし、唯一の有効な設定を直接壊さないでください。
プロキシグループの参照先を確認します。provider名は、プロキシグループの use に指定した名前と一致している必要があります。providerにノードがあっても、プロキシグループから参照されていなければ画面に表示されないことがあります。

ログにルールプロバイダー rule-providers の更新失敗が記録されている場合は、ルールファイルのURLと形式を個別に確認してください。ルールリソースのエラーはノードサブスクリプションが空であることを意味しませんが、設定の読み込みや通信の振り分けに影響する場合があります。具体的なログを基に判断してください。

6. 復旧後の確認と問い合わせに必要な情報

修正後は「更新・読み込み・接続」の3段階で確認します。まず手動で一度更新し、サブスクリプション取得の新しいエラーがログにないことを確認します。次に対象の設定を有効にし、ノードまたはproviderの数が想定どおりか確認します。最後にノードを選び、普段使うサービスへ接続して、接続画面で実際の出口とルールの適用結果を確認してください。

更新の確認：操作時刻を記録し、設定の最終更新日時が変わったことを確認します。providerを使う場合は、その更新日時も確認してください。
読み込みの確認：YAML、プロトコルの種類、プロキシグループの参照エラーがないことと、対象の設定が実際に有効になっていることを確認します。
接続の確認：システムプロキシ、または必要に応じて有効にしたTUNが想定どおりの状態か確認します。通信がプロキシを経由していないことをサブスクリプションの不具合と誤認しないようにしてください。
設定保持の確認：適切な自動更新スケジュールに戻し、次回の更新後も必要なローカルオーバーライドが維持されるか確認します。

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

サブスクリプション提供元やクライアントの開発者に問い合わせる際は、OS、クライアントのバージョン、コア名とバージョン、失敗した日時とタイムゾーン、機密情報を伏せたエラー全文、直接接続とプロキシ経由で更新した結果を添えてください。HTTPエラー、Webページの内容、YAML解析エラーのどれが返されたかも記載すると、追加のやり取りを減らせます。

設定の一部を共有する場合は、再現に必要なフィールドだけを残し、サーバーアドレス、パスワード、アクセストークンを置き換えてください。サブスクリプション全体が漏えいした場合は、アカウント画面でURLを再発行し、クライアントに保存したURLも更新します。設定の整理にはサブスクリプションの詳しい解説も参考にしてください。リモートサブスクリプション、ノードプロバイダー、ローカルオーバーライドを同じ層で混在させないようにしましょう。