Clashのサブスクリプション更新に失敗する原因と対処法｜リンク切れ・形式不一致・自動更新間隔

まず「サブスクリプションの取得失敗」か「設定の読み込み失敗」かを切り分ける

Clashのサブスクリプション更新は通常、クライアントがURLにアクセスし、応答内容を解析して、有効な設定をコアに読み込ませるという3段階で進みます。「更新失敗」と表示されても、ノードが無効になったとは限りません。以前の設定がメモリ上でそのまま動作している場合があります。反対に、ダウンロードに成功しても、新しい設定が現在のコアで読み込めるとは限りません。

まずクライアントの「ログ（Logs）」を開き、「設定（Profiles）」で対象のサブスクリプションを更新します。クライアントによっては、この画面が「サブスクリプション」と表示されます。実際の画面に合わせてください。操作した時刻、エラーのキーワード、サブスクリプションの最終更新日時を記録し、設定の削除やコアの切り替え、ネットワークのリセットを同時に行わないでください。

リクエスト段階の失敗：timeout、no such host、403、429 などが表示される場合は、まずURL、ネットワーク、サーバーの応答を確認します。
解析段階の失敗：yaml、unmarshal、invalid config などが表示される場合は、応答形式と設定内容を確認します。
読み込み段階の失敗：ダウンロード後に未対応のプロキシタイプが表示されたり、設定の適用に失敗したりする場合は、コアとの互換性を確認します。

リンク切れ・アクセス制限：HTTPステータスコードで原因を絞り込む

サービス提供元のページではなく、サブスクリプションURLをコピーする

サブスクリプション提供元のアカウントページで、有効期限、通信量の状態、「サブスクリプションURLのリセット」を実行したかを確認します。URLをリセットすると、古いURLのトークンがすぐに無効になる場合があります。コピーする際はClashまたはmihomo向けのサブスクリプションを選び、ログインページ、アカウントのトップページ、QRコード画像のURL、一時的なログイン状態を含むダウンロードURLは選ばないでください。

URLには通常、クエリパラメーターが含まれます。? 以降をむやみに削除したり、チャットアプリが付けた句点・引用符・改行まで一緒にコピーしたりしないでください。古いURLが無効と思われる場合は、既存のサブスクリプションを残したまま新しいURLで別項目を作成します。読み込みを確認してから古い項目を削除してください。

応答・エラー	まず確認する項目	次に行うこと
401 / 403	トークンの失効、権限の制限、アクセス制御、セキュリティ対策によるブロック	アカウント管理画面から新しいURLをコピーし、プランの状態を確認する。ステータスコードだけで期限切れと判断しない
404 / 410	APIのURL変更、古いURLの無効化	提供元のお知らせを確認し、サブスクリプションURLを再取得する
429	短時間に更新を繰り返しすぎている	再試行を止め、サーバーの案内またはRetry-Afterに従って待つ
500 / 502 / 503	サブスクリプションサービスまたは上流サーバーの一時的な障害	少し時間をおいて再試行し、更新ボタンを連続で押さない
200だが解析に失敗	ログインページ、セキュリティ対策ページ、エラーテキストが返されている	Content-Typeと応答本文を確認し、設定ファイルが返されているか確かめる

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

ブラウザーではログインCookieが送信されたり、人間確認を通過したり、クライアントとは異なるプロキシ経路を使ったりする場合があります。クライアントによる取得では、通常こうしたブラウザーの状態は引き継がれません。ブラウザーでURLが正常に表示されても、それはブラウザーからのリクエストが成功したことを示すだけで、クライアントのログにある結果の代わりにはなりません。

提供元がリクエストヘッダーやクライアントの種類を指定している場合は、公式ドキュメントに記載されたサブスクリプションURLを使ってください。User-Agentを手当たり次第に変更して試すのは避けましょう。サーバーから返される形式が変わり、アクセスの問題が形式の問題に置き換わることがあります。

形式の不一致：完全な設定・ノード一覧・コアの対応状況を確認する

サブスクリプションの形式は一種類ではありません。完全なClash YAMLには通常、proxies、proxy-groups、rules が含まれます。プロキシプロバイダー用のファイルは通常 proxies のみで、proxy-providers から参照します。共有リンクの一覧やエンコードされたテキストを返すURLもあります。どのクライアントでも完全な設定として読み込めるとは限りません。

エラーの内容に応じて確認する

本文がHTMLで始まる：<!DOCTYPE html> やログイン案内が表示される場合、取得したのはYAMLではなくWebページです。サブスクリプションのURLとアクセス権限を確認してください。
YAMLの行番号が表示される：該当行付近のインデント、コロン、引用符を確認します。YAMLのインデントにはスペースを使い、Tabは使いません。リッチテキストエディターから全角記号をフィールド名に貼り付けないでください。
プロキシグループがない、または参照先が見つからない：ルールが参照するグループ名や、グループ内のノード名が存在するか確認します。ノード一覧を取得しただけでは、ルールによる振り分けは自動で補完されません。
未対応のプロキシタイプやフィールドが表示される：実際に動作しているコアの種類とバージョンを確認します。クライアントのバージョンとコアのバージョンは別の情報です。「バージョン情報」や「コア」の設定で確認できます。

mihomoはClashの設定エコシステムを引き継ぎ、さらに拡張していますが、旧バージョンのClashコアは新しいプロトコルやオプションすべてに対応しているわけではありません。mihomo向けと明記されたサブスクリプションには、対応するクライアントとコアを使用してください。エラー行を全文保存し、アップグレード前に設定をバックアップします。エラーを消すために、理解できないプロトコルのフィールドを削除しないでください。

更新リクエストがプロキシに遮られる：直結とプロキシを分けてテストする

よくあるのは、現在のプロキシを経由しないとクライアントがサブスクリプションを更新できない一方、そのノードがすでに使えず、新しいノード情報の取得にもサブスクリプションが必要という状況です。この場合、Webページもサブスクリプションもタイムアウトすることがあります。逆に、現在のネットワークからサブスクリプションのドメインへ直接接続できないのに、クライアントの更新が直結を使っている場合もあります。

まず、どのプロセスがリクエストを送信しているか確認します。完全なリモート設定は通常、クライアントの管理プログラムがダウンロードします。一方、proxy-providers のリモートプロキシ一覧はコアが管理します。クライアントの「プロキシ経由で更新」設定が、コアによるプロキシ一覧の取得にも適用されるとは限りません。Rule、Global、システムプロキシを切り替えても、更新プロセスの通信経路が変わるとは限りません。

対象のサブスクリプションの編集メニューやクライアントの設定で、「プロキシ経由で更新」「プロキシを更新」などの項目を探します。独立した切り替えがないクライアントでは、更新ログや説明を確認してください。
現在の更新がプロキシ経由なら、まず利用可能と確認済みのノードを選んで更新します。それでも失敗する場合は、直結で一度テストしてください。
現在の更新が直結で、ログにサブスクリプションのドメインへの接続タイムアウトが記録されている場合は、利用可能なプロキシで試します。スマートフォンのテザリングに一時的に切り替え、現在のネットワークによる制限かどうかを比較する方法もあります。
テスト後は必要な設定に戻し、どの経路で成功したかを記録します。ネットワークの切り替えと設定変更を混同しないよう、一度に変更する項目は一つにしてください。

ポート・DNS・証明書のエラーを混同しない

connection refused 127.0.0.1:7890 は、リクエストがローカルの7890番ポートに接続しようとして失敗したことを示します。コアが動作しているか、実際の mixed-port が7890のままか確認してください。7897に変更済みなら、更新用プロキシの設定も合わせて変更し、古いポートを参照しないようにします。

no such host はドメイン名の名前解決に関係するエラーです。x509 や証明書の有効期限エラーの場合は、まずWindowsの日付、時刻、タイムゾーンを確認し、その後でネットワーク上のHTTPS検査やサーバー証明書の異常を調べます。問題を隠すために証明書検証を無効にするのは避けてください。接続タイムアウトも、すぐにDNSの障害と決めつけず、ログから名前解決・接続・TLSハンドシェイクのどこで止まったか確認します。

自動更新間隔：クライアントのサブスクリプションとプロキシ一覧を分けて設定する

完全なサブスクリプションの定期更新はクライアントで管理する

「設定（Profiles）」または「サブスクリプション」を開き、対象項目の右クリックメニューやその他のメニューから「編集」「情報を編集」、または更新設定を探します。自動更新が有効か、間隔の単位が何かを確認してください。メニュー名はクライアントごとに異なります。特定のクライアントの設定手順を、すべてのClashクライアントに共通するものと考えないでください。

提供元から特別な指定がなければ、まず12時間ごとの更新で様子を見ます。画面の単位が分なら720、時間なら12と入力してください。
1日1回は1440分または24時間です。数字だけを見て、単位を見落とさないようにしてください。
0を「すぐに更新」と解釈しないでください。自動更新の無効化、既定値の使用、その他の動作を示す場合があります。クライアントの説明を確認してください。
クライアントがサーバー推奨の更新間隔を読み取れる場合は、提供元の案内に従うのが適切です。ただし、すべてのクライアントがこの推奨を認識・適用するわけではありません。

デスクトップクライアントを終了すると、通常はプロセス内の定期タスクも実行されなくなります。Windowsがスリープ中も、通常どおりサブスクリプションが取得されるわけではありません。コアがバックグラウンドで動作していても、完全なサブスクリプションを更新する画面プロセスが動作し続けるとは限りません。定期更新が必要な場合は、クライアントを起動したままにし、スリープ解除後や再起動後の更新日時も確認してください。

proxy-providersのintervalの単位は秒

mihomoのリモートプロキシ一覧を使う場合、interval はコアの設定項目で、単位は秒です。以下は各フィールドの関係を示す例で、完全なサブスクリプションではありません。例にあるドメインは実際には利用できないため、使用時には信頼できる自分のURLを設定してください。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 86400

ここでは、86400 が24時間、43200 が12時間、3600 が1時間を表します。プロキシ一覧はプロキシグループから use で参照する必要があり、取得する内容もプロキシ一覧の形式に適合していなければなりません。この項目をYAMLのトップレベルに追加して、クライアントの完全なサブスクリプションの更新間隔を制御しようとしないでください。

プロキシ一覧の health-check.interval はノードのヘルスチェック間隔であり、サブスクリプションの取得頻度ではありません。ヘルスチェックを300秒に設定しても、対象のチェックタスクが変わるだけで、5分ごとにノード一覧を再取得するわけではありません。長期的な変更には、クライアントが対応する上書き・マージ機能を使い、次回のサブスクリプション更新でローカルの変更が上書きされないようにしてください。

手動更新：既存の設定を残して、新しい内容を確認する

手動更新は、URLが復旧したか確認したいときや、提供元からノード変更の案内があり、すぐに設定を取得したいときに便利です。「強制更新」は共通のメニュー名ではありません。「更新」だけのクライアントもあれば、「すべて更新」やローカルの更新間隔を無視する操作を用意しているクライアントもあります。サーバー側のキャッシュを回避できるわけではなく、無効なトークンも修復できません。

現状を記録する：現在適用中の設定名、更新日時、利用可能なノードを記録します。必要であれば、保護されたローカルフォルダーにバックアップをエクスポートしてください。
対象だけを更新する：設定一覧で該当するサブスクリプションを一度だけ「更新」します。複数のサブスクリプションを同時に更新して、原因の特定が難しくならないようにしてください。
結果を確認する：ログの時刻と照らし合わせてリクエストが完了したか確認し、最終更新日時が変わったか、解析エラーやコアの読み込みエラーがないかを調べます。
適用を確認する：クライアントが自動で再読み込みしない場合は、更新後の設定を選択して適用します。プロキシグループが存在するか、ルールモードが想定どおりかも確認してください。
実際に通信を確認する：直結するはずのサイトとプロキシ経由にする対象を一つずつテストし、接続ログで適用されたルールと出口を確認します。ノード数の変化だけでは判断できません。

更新日時が変わってもノード一覧が同じ場合、上流の内容に変更がなかっただけかもしれません。必ずしもキャッシュの問題ではありません。URLにランダムなパラメーターを繰り返し追加する方法も一般的な解決策ではなく、署名付きURLが無効になることがあります。新しい設定の読み込みに失敗した場合は、ログを残して利用可能な設定に戻し、設定フォルダー全体を何度も削除しないでください。

解決しない場合は、次の情報をまとめる

サブスクリプション提供元やクライアントの開発プロジェクトへ問い合わせる前に、必要最小限の診断情報をまとめてください。「更新できない」と伝えるより、原因の特定に役立ちます。エラーは原文のまま記録しつつ、サブスクリプションURL、認証ヘッダー、ノードの認証情報は公開しないでください。

実行環境：Windowsのバージョン、クライアント名と完全なバージョン番号、実際に使っているコアの名前とバージョン番号。
発生時刻：たとえば現地時間の09:20に手動更新したことと、タイムゾーンを記載すると、サーバー側でログを確認しやすくなります。
失敗した段階：リクエストの失敗、YAMLの解析エラー、ダウンロード成功後の適用失敗のいずれか。
比較結果：直結で成功したか、利用可能なプロキシで成功したか、テザリングに切り替えても失敗したか。
定期更新の設定：自動更新の有効・無効、間隔の数値と単位、障害発生時にクライアントを終了していたか、PCがスリープしていたか。

切り分けは、まずURLとアカウントの状態、次に応答形式、その後に更新リクエストの通信経路、最後に定期タスクの順に行います。こうすればサーバー、クライアント、コアの問題を分けて考えられ、一時的なサブスクリプション障害のためにWindowsのネットワーク設定をすべてリセットせずに済みます。