Clashのサブスクリプション更新に失敗したときの対処法と自動更新間隔の設定

まず、どの段階で失敗しているか確認する

Clashのサブスクリプション更新は、単にファイルをダウンロードするだけではありません。クライアントがサブスクリプションURLにリクエストを送り、応答を解析して設定やノード一覧を保存し、最後にコアへ読み込ませます。どの段階で失敗しても、画面には「更新に失敗しました」とだけ表示されることがあります。エラーの原文、更新時刻、現在の設定名を記録しておくと、何度も更新ボタンを押すより原因を特定しやすくなります。

サブスクリプションには、GUIクライアントが管理するリモートの完全な設定ファイルと、mihomoの設定で proxy-providers が管理するプロバイダーの2種類があります。前者の更新間隔は通常クライアント側に保存され、後者はプロバイダー内の interval フィールドで指定します。別々のタイマーなので、一方を変更してももう一方には反映されません。

エラー・症状	まず確認すること	次に行うこと
`401`、`403`	トークン、アカウント権限、サーバー側のアクセス制限	サービス提供元の管理画面にログインし、リンクの状態を確認する
`404`、`410`	古いURL、無効化されたURL、コピーが不完全なURL	現在のサブスクリプションURLをコピーし直す
`429`	短時間での連続リクエスト、複数デバイスからの同時更新	再試行を止め、サーバー側の指定時間が過ぎるまで待つ
`timeout`、`EOF`	ネットワーク経路、TLS、中継機器	直接接続とプロキシ経由のリクエストを比較する
`yaml`、`unmarshal`	応答形式、フィールドの型	応答内容が目的の設定形式になっているか確認する
更新は成功するが、読み込みに失敗する	コアの対応範囲、プロキシグループの参照先	設定の検証結果と読み込みログを確認する

リンク切れ・サーバー側の拒否：まずステータスコードを確認

URLをコピーし直し、パラメーターを手作業で組み立てない

サブスクリプションサービスのアカウントページを開き、契約プラン、データ残量、有効期限を確認してから、ClashまたはClash Meta用のURLをコピーします。サブスクリプショントークンを再発行すると、古いURLはすぐに無効になる場合があります。クライアントに古いURLが残っていれば、自動更新を続けても失敗します。コピー時は前後の空白や改行に加え、チャットアプリによって & 以降のパラメーターが切り落とされていないか確認してください。

403 は、必ずしもプランの有効期限切れを意味しません。アクセス制限、リクエストヘッダーの制限、セキュリティ対策ページなどが原因の場合もあります。また、200 でも正常とは限りません。ログインページや認証ページ、エラーメッセージが返されていることもあります。ブラウザーでURLを開けるかだけで判断せず、応答本文も確認してください。

curlでHTTPエラーと接続エラーを切り分ける

以下のコマンドはBashで実行します。curl をインストールしておいてください。URLは非表示入力で読み込み、シェルの履歴に直接残らないようにします。出力ファイルは手元での確認にのみ使用してください。ノードの認証情報が含まれる可能性があるため、作業後は削除してください。ここで指定する20秒は今回の診断用タイムアウトであり、クライアントの標準設定ではありません。

umask 077
read -r -s -p 'サブスクリプションURL：' SUB_URL
printf '\n'
curl --noproxy '*' --location \
  --connect-timeout 10 --max-time 20 \
  --output subscription-response.txt \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  "$SUB_URL"

HTTP=000 はサーバーのステータスコードではありません。有効なHTTP応答を受け取れなかったことを示す場合が多く、DNS、接続、証明書の問題はcurlのエラーメッセージも併せて確認する必要があります。非表示入力でも秘密情報が完全に保護されるわけではありません。実行中はURLがローカルのプロセス引数に表示される可能性があるため、信頼できない共有ホストでは実行しないでください。

301 または 302 が返された場合は、最終的な遷移先がログインページではないか確認してください。上記の --location はリダイレクトをたどります。
429 が返された場合は、まず Retry-After の指示に従ってください。復旧を試すために毎分更新するのは避けましょう。
証明書エラーが発生した場合は、システム時刻と証明書チェーンを確認してください。TLS検証の無効化を恒久的な解決策にしないでください。

通信がブロックされる・更新がプロキシ経由にならない

ブラウザーからサブスクリプションにアクセスできても、クライアントの更新機能からアクセスできるとは限りません。ブラウザーはシステムプロキシを経由していても、更新機能は直接接続している場合があります。反対に、TUNや透過型ゲートウェイが有効な環境では、「直接接続」と表示されたリクエストもネットワーク層で中継される可能性があります。以下の比較で確認できるのは、curlがHTTPプロキシを明示的に使ったかどうかです。コマンド名だけで、通信がTUNを完全に迂回したとは判断できません。

ローカルプロキシポートを使って比較する

まずクライアントでHTTPまたはmixedの待ち受けポートを確認します。以下の例では 127.0.0.1:7890 を使いますが、このポートで実際に待ち受けている場合に限ります。設定が mixed-port: 7897 なら、コマンドのポート番号を 7897 に変更してください。

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --location --connect-timeout 10 --max-time 20 \
  --output subscription-via-proxy.txt \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  "$SUB_URL"

unset SUB_URL

プロキシを明示したリクエストが成功し、前のリクエストが失敗した場合は、ネットワーク経路を優先して確認してください。ただし、GUIクライアントも同じ経路を使ったとは限りません。クライアントでサブスクリプション更新に関するログを有効にし、手動で一度更新して該当リクエストが記録されるか確認します。さらに、そのリクエストで使われたプロキシ、ルール、エラー内容を確認してください。クライアントによってはダウンローダーがコアから独立しています。接続一覧に記録がないだけで、リクエストが送信されていないとは断定できません。

サブスクリプション更新の循環依存を避ける

サブスクリプションに含まれるノードだけがサブスクリプションのドメインに接続でき、そのノードがすべて使えない場合、「更新時にプロキシを使用」を有効にしても接続は復旧しません。利用可能な代替経路を用意するか、サービス提供元が案内するアクセス可能なURLを使う必要があります。
ログでサブスクリプションのドメインが DIRECT に一致し、直接接続が失敗すると確認できた場合は、ネットワーク要件を踏まえてルールを調整し、実際にどのルールが適用されたか確認してください。
ドメイン解決エラーが出る場合は、サブスクリプションのホスト名とDNSログを先に確認してください。DNS、TUN、ルール、ポートを一度に変更すると、どの変更が効果を上げたのか判断しにくくなります。
特定のWi-Fiでのみ失敗する場合は、モバイル回線でも一度試してください。ネットワーク環境の違いを特定する手がかりになります。まずクライアントを再インストールする必要はありません。

形式の不一致：ダウンロード後も内容を検証する

サブスクリプションAPIは、完全なYAML、ノードだけを含むYAML、エンコードされた共有リンク一覧、または他のクライアント専用形式を返す場合があります。GUIクライアントが自動変換するかどうかは、実装によって異なります。mihomoのHTTPプロキシプロバイダーと完全な設定ファイルの読み込み機能では入力形式も異なります。同じ応答を確認せずにどこへでも読み込ませないでください。

応答内容を見て構造を確認する

応答ファイルをローカルのテキストエディターで開きます。先頭が <!doctype html> やログイン画面のテキストなら、問題はYAMLのインデントではなく、ダウンロードまたは認証の段階にあります。
完全な設定ファイルには通常、proxies、proxy-groups、rules などのフィールドが含まれます。ネイティブYAML形式のプロキシプロバイダーでは、通常 proxies: でノード一覧を定義します。必要なフィールドの組み合わせは、用途に応じて確認してください。
proxy-groups や rules が参照する名前が実在するか確認してください。ノードのダウンロードに成功していても、参照先のプロキシグループが存在しなければ設定を正常に使用できません。
サービス提供元がClash用とClash Meta用の出力を用意している場合は、現在使用しているコアに合ったものを選んでください。古いClashコアは、mihomoの新しいフィールドやプロトコルに対応していない場合があります。

mihomoがローカルにインストールされている場合は、完全な設定ファイルのコピーを使って構文と設定を検証できます。以下では、ファイルがカレントディレクトリに config.yaml という名前で保存されているものとします。プロキシプロバイダー用のファイルは、完全な設定ファイルとして検証できません。設定が外部ファイルを参照している場合は、作業ディレクトリと依存ファイルのパスも確認してください。

mihomo -v
mihomo -t -d . -f ./config.yaml

-v で実際のコアのバージョンを記録し、各フィールドが対応しているか確認できます。-t の検証を通過しても、すべてのノードに接続できるとは限りません。エラーの原文とコアのバージョンを記録してから原因を調べ、認識されないフィールドをすべて削除して無理に読み込ませないでください。形式変換が必要な場合は、信頼できる管理下の手段を使用し、不明な変換サイトにサブスクリプショントークン全体を送信しないようにしてください。

クライアントの自動更新間隔を設定する場所

自動更新はクライアントの画面機能のため、バージョンによって項目名や場所が異なる場合があります。まず「バージョン情報」画面でクライアントのバージョンを確認し、対象のサブスクリプションの編集画面を開いてください。「ノード遅延テストの間隔」とサブスクリプションのダウンロード間隔を混同しないようにしましょう。「すべてのサブスクリプションを更新」を実行しても、定期実行が有効になるわけではありません。

クライアント	設定を開く手順	確認する項目
Clash Verge Rev	「サブスクリプション」→対象のカードのメニューまたは右クリック→「編集」	更新間隔、使用中のバージョンにプロキシ経由で更新する設定があるか
Clash for Windows（旧バージョン）	「Profiles」→対象のリモート設定を右クリック→「Settings」	更新間隔、プロキシ経由でのダウンロード設定と画面上の単位
Clash for Android（旧バージョン）	「設定」→対象のリモート設定の編集ボタン	自動更新と間隔、全般設定のネットワーク関連項目
mihomo（コマンドライン）	設定ファイル内の `proxy-providers`	`interval` と `proxy`

Clash Verge Revでは、まずサブスクリプションの編集画面で「更新間隔」や「プロキシを使用」に相当する項目を探してください。そのバージョンで更新方法がカードのメニューにある場合は、メニューからプロキシ経由での更新を実行します。一度手動更新に成功しても、次回以降の自動更新でも同じ方式が使われるとは限りません。設定を開き直し、保存内容を確認してください。

Clash for WindowsとClash for Androidはすでにメンテナンスが終了した旧クライアントです。画面の項目は、使用しているバージョンによって異なります。現在の画面にプロキシ経由で更新する設定がない場合、他のクライアントのメニュー手順をそのまま当てはめないでください。ログで実際の更新経路を確認するか、現在の設定に対応したメンテナンス中のクライアントへ移行してください。

画面に表示される単位に合わせて間隔を入力する

まずは6時間または12時間に設定し、サービス提供元の制限に合わせて調整するとよいでしょう。単位が「分」なら6時間は 360、12時間は 720 と入力します。「時間」ならそれぞれ 6 と 12 です。入力欄の数字だけで単位を判断しないでください。保存後に手動更新を一度実行し、「最終更新」の時刻が変わったか確認します。

モバイル端末では、バックグラウンド実行、バッテリー最適化、システムのスリープも影響します。画面ロック後に定時更新が秒単位で正確に実行されるとは限りません。デスクトップ版も、クライアントを完全に終了すると通常は自動更新が続きません。アプリを開き直したときだけ更新される場合は、間隔をさらに短くするのではなく、まずアプリの実行状態を確認してください。

mihomoのintervalとプロキシ経由の更新設定

HTTPタイプの proxy-providers では、interval の単位は秒です。たとえば 21600 は6時間、43200 は12時間、86400 は24時間です。これはプロキシプロバイダーのダウンロード間隔であり、完全なリモート設定ファイルの自動更新間隔ではありません。

該当フィールドに対応したmihomoのバージョンでは、プロバイダーの proxy にダウンロードで使うプロキシまたはプロキシグループを指定できます。以下は既存のHTTPプロバイダーに追加できるフィールドのみの例で、完全な設定ではありません。元の url、path、プロバイダー名はそのまま残してください。PROXY は設定内に存在し、現在利用できる出力名である必要があります。

interval: 21600
proxy: PROXY
health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600

ここでの health-check.interval: 600 は600秒ごとにヘルスチェックを行う指定であり、10分ごとにサブスクリプションをダウンロードする意味ではありません。ヘルスチェックURLは、ネットワークからの到達性と用途に合わせて選んでください。例のURLは接続確認先であり、サブスクリプションURLではありません。

mihomoをコマンドラインで実行しても、設定ファイルのトップレベルに interval を追加するだけで設定全体が定期的に再ダウンロードされることはありません。完全な設定を更新する必要がある場合は、管理下の外部タスクでダウンロード、検証、バックアップ、再読み込みを行ってください。失敗時は元のファイルを残し、取得した応答で使用中の設定を直接上書きしないでください。

更新後に変化がない場合：次の6項目を確認

更新対象を確認する。カード名とサブスクリプションURLの取得元を確認し、予備のサブスクリプションを更新したのに別の設定を使い続けていないか確認してください。
時刻と内容を確認する。更新時刻が変わっても、クライアントに更新操作が記録されたことしか示さない場合があります。サーバーが同じ内容を返している可能性もあります。ノード数が変わらないことだけで失敗とは判断できません。
新しい設定が読み込まれたか確認する。クライアントによっては「ダウンロード」と「有効化」が別の操作です。設定を選択するか、再読み込みのログを確認してください。
ノード一覧の取得元を確認する。プロキシグループがローカルの固定ノードだけを参照している場合、リモートプロバイダーを更新しても新しいノードがそのグループに表示されるとは限りません。use とプロバイダー名を確認してください。
フィルター条件を確認する。地域フィルター、正規表現、除外ルールによって新しいノードが非表示になっている場合があります。まずプロバイダーの元のノード数を確認してください。
自動タスクが動作しているか確認する。クライアントを再起動した後、更新間隔の設定が保持されているか確認し、次回実行後に更新時刻を確認してください。

最後に、診断のために保存した応答ファイルを削除し、同期フォルダーや共有フォルダーに残さないようにしてください。メンテナーへの報告が必要な場合は、クライアントとコアのバージョン、エラー発生時刻、HTTPステータスコード、機密情報を伏せたエラー原文を伝えれば十分です。サブスクリプショントークン、ノードのパスワード、応答全体を公開の添付ファイルにしないでください。

rm -f subscription-response.txt subscription-via-proxy.txt

おすすめの対処順は、URLの有効性を確認 → リクエスト経路を比較 → 応答形式を確認 → 設定の読み込みを検証 → 適切な更新間隔を設定、です。自動更新で手動操作は減らせますが、無効なトークン、形式の不一致、接続できないダウンロード経路は解決できません。