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

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

Clashクライアントで表示される「更新に失敗しました」は、単一の障害を意味するとは限りません。リモートサブスクリプションの更新では、通常、ドメイン名の解決、TCPおよびTLS接続、HTTPリクエスト、コンテンツのダウンロード、設定の解析、カーネルによる検証、設定の切り替えが順番に行われます。画面に失敗メッセージが1つ表示されただけなら、更新を何度もクリックする前に、どの段階で止まったのかを確認してください。

最も有効な判断材料は、クライアントのログ、HTTPステータスコード、ダウンロードされた内容です。まず失敗した時刻を記録し、ログ画面を開いて、同じ1分間にサブスクリプションのドメイン名、timeout、certificate、401、403、404、parse、yamlを含む項目がないか確認します。段階によって、取るべき対処は異なります。

確認できる症状	該当する障害段階	優先して確認する項目
ドメイン名の解決に失敗する、ホストが見つからない	DNS	システムDNS、TUN DNS、ドメイン名の綴り、ローカルネットワーク
接続がタイムアウトする、またはリセットされる	ネットワーク接続	直接接続の可否、プロキシ経路、ファイアウォール、IPv6
HTTP 401、403、404、410	サーバーの応答	トークン、サブスクリプションの有効期限、アクセス頻度、URL全体の欠落
ダウンロードは成功するがYAMLエラーが表示される	設定の解析	返却内容、インデント、フィールドの互換性、カーネルのバージョン
更新成功と表示されるが、ノードが変わらない	設定の切り替え	現在有効な設定、キャッシュ、再読み込みの状態、既存の接続

リンク切れ、アクセス拒否、サーバー応答の異常

コピー時にURLが壊れていないか確認する

サブスクリプションURLは、改行、末尾の空白、チャットアプリによる途中切れ、HTMLエスケープなどが原因で無効になることがあります。よくあるのは、最初の & より後がコピーされていなかったり、末尾のトークンが数文字欠けていたりするケースです。サブスクリプションサービスの管理画面から完全なURLをもう一度コピーし、クライアントに登録した古いURLを置き換えてください。トークンを手作業でつなぎ合わせるのは避けます。

HTTPステータスコードを確認すると、原因を素早く絞り込めます。401は通常、認証情報またはトークンが無効になったことを示します。403はアクセス方針、頻度制限、接続元のネットワークが原因の場合があります。404はパスが存在しないこと、410はリソースが明確に無効化されたことを示すケースが一般的です。429は短時間にリクエストを送りすぎた状態です。429が出た後に高頻度で更新を続けても、通常は制限時間が延びるだけです。

ターミナルでHTTPリクエストを個別にテストする

デスクトップ環境では、curlを使ってネットワーク経由のダウンロードとクライアント側の解析を分けてテストできます。まずサブスクリプションURLを現在のターミナルの環境変数に保存し、次のコマンドを実行します。コマンドでは接続タイムアウトを10秒、全体のタイムアウトを30秒に設定し、HTTPリダイレクトにも追従します。

export SUB_URL='完全なサブスクリプションURL'
curl -L \
  --connect-timeout 10 \
  --max-time 30 \
  -D response-headers.txt \
  -o profile.yaml \
  "$SUB_URL"

response-headers.txtで最終的なステータスコードを確認し、続いて profile.yaml の先頭を確認します。標準的なClashまたはMihomo設定なら、proxies:、proxy-groups:、rules:などのYAMLフィールドが見つかります。内容が <html で始まる場合、実際にダウンロードされたのはログインページ、認証ページ、エラーページのいずれかです。JSON形式のエラーオブジェクトが返された場合も、設定としてそのままインポートすることはできません。

サービスによっては、Base64でエンコードされた汎用サブスクリプションを返しますが、クライアント側の入力欄はClash YAML形式しか受け付けないことがあります。この場合、ネットワークリクエスト自体は成功していても、解析には失敗します。サーバー側でClash、Clash Meta、Mihomoのいずれかに対応する形式を選択し、ファイル拡張子だけを変更するのは避けてください。

システム時刻とTLS接続を確認する

端末の時刻がずれていると、HTTPS証明書の検証に影響します。ログに certificate has expired、not yet valid、ハンドシェイク失敗などが表示されたら、まずシステムの自動時刻合わせを有効にしてください。Windowsでは「設定」→「時刻と言語」→「日付と時刻」で時刻の自動設定を有効にします。macOSでは「システム設定」→「一般」→「日付と時刻」で自動設定を有効にします。

ブラウザーではサブスクリプションURLを開けるのに、クライアントだけがタイムアウトする場合は、両者のネットワーク経路を比較してください。ブラウザーはシステムプロキシを使っている一方、クライアントの更新処理は直接接続していることがあります。逆のケースもあります。この違いは「ブラウザーでは開けるのにClashの更新に失敗する」場合によくある原因です。

プロキシループ、TUNモード、DNS経路を確認する

サブスクリプションの更新には、利用可能な起動経路が必要です。更新処理が現在のプロキシに依存しているのに、現在の設定にあるノードがすべて無効になると、起動依存が発生します。ノードを復旧するには先に更新が必要ですが、更新リクエストもそのノードを経由しなければなりません。別のループは、クライアントプロセスが発行したリクエストがシステムプロキシやTUNによって再び自身へ送られる場合に発生します。ログには、同じドメインへの接続、接続拒否、タイムアウトが連続して記録されることがあります。

直接接続でテストし、起動依存を解消する

現在の設定とモードを記録し、いったんTUNモードを無効にします。
システムプロキシを無効にし、ブラウザーまたはターミナルから一般的なWebサイトへ直接アクセスできることを確認します。
クライアントで対象のサブスクリプションを手動更新します。
更新に成功したら、システムプロキシまたはTUNを再び有効にし、元のルールモードへ戻します。

サブスクリプションのドメインにプロキシ経由でしかアクセスできない場合は、利用可能と確認できた起動用の経路を1つ残しておく必要があります。接続できるローカル設定へいったん切り替えてから、リモート設定を更新してください。利用可能な設定を最後の1つまで削除してから、リモートサブスクリプションをテストするのは避けます。

ローカルポートとシステムプロキシを確認する

一般的なデスクトップ設定では、HTTPまたはmixedのリスニングポートに 7890 が使われます。従来型の分離設定では、HTTPに 7890、SOCKSに 7891、外部コントロールポートに 9090 が使われることがあります。これらの値は変更できるため、現在のクライアントの「設定」または「ポート」画面に表示される実際の値を優先してください。

システムプロキシが 127.0.0.1:7890 を指しているのに、カーネルが動作していない、またはmixed-portが別の値に変更されていると、システムプロキシを経由する更新リクエストはすべて失敗します。まずカーネルが実行中であることを確認し、次にポートがリッスン中か確認してください。ポート競合のログには通常、address already in useが含まれます。

サブスクリプションドメインのDNS結果を確認する

TUNとfake-ipを有効にすると、アプリケーションから見えるアドレスがfake-ipアドレスプールのものになることがあります。これは正常な転送動作です。ただし、クライアント自身の更新処理では、実際のドメイン名を解決できなければなりません。ログにDNSタイムアウトが表示されたら、TUNを一時的に無効にして再テストし、システムDNSの経路とMihomo DNSの経路を切り分けます。

IPv6も確認してください。ネットワークによってはAAAAレコードを返せても、安定したIPv6の出口を利用できず、10〜30秒ほど待った後にタイムアウトすることがあります。システム側で対象ネットワークインターフェースのIPv6を一時的に無効にするか、クライアントのDNSと接続方針を調整して再テストします。長期的な変更は、テスト結果が明確にIPv6を指している場合だけ行い、別の障害まで隠してしまわないようにしてください。

ダウンロード成功後に解析へ失敗した場合の手順

ログにHTTP 200が表示されたら、確認の重点をネットワークから内容へ移します。まずダウンロードしたファイルが想定した設定か確認し、次にYAML構文、最後に現在のカーネルが各フィールドをサポートしているかを確認します。3つの段階を混同すると、DNSやプロキシ設定を何度も変更するだけで、解析エラーそのものに対処できないままになります。

まずYAMLの基本構造を確認する

YAMLはインデントに依存します。Tab文字、リストの階層ミス、閉じられていない引用符などが、設定の読み込み失敗を引き起こします。Mihomoのコマンドラインを使えば、プロキシのリスニングを開始せずに設定をテストできます。

mihomo -t -f profile.yaml

テストに成功すると、通常は設定の検証に成功したことを示すメッセージが表示されます。失敗した場合は、問題のフィールドまたは行番号が示されます。リモートサブスクリプションから自動生成された設定は、毎回上書きされるファイルをローカルで直接修正するのではなく、サブスクリプションの形式設定または変換ルールに戻って対処してください。

完全な設定とプロキシプロバイダーを区別する

完全なリモート設定には通常、ポート、DNS、プロキシグループ、ルールが含まれ、クライアントの設定として直接有効化できます。一方、proxy-providersは、独立したノード集合をメイン設定から参照する仕組みで、更新方法が異なります。ノードリストだけを含むproviderファイルを完全な設定としてインポートすると、proxy-groupsやrulesが不足する可能性があります。逆に、完全な設定をproviderのURLとして指定しても、構造が合わず失敗します。

Mihomoの設定では、providerの interval の単位は秒です。たとえば 21600 は6時間ごとに確認する設定を意味します。これはそのproviderだけを制御する値であり、グラフィカルクライアントがリモート設定全体に設定する更新間隔とは異なります。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.net/subscription/token-value"
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

フィールドの互換性はカーネルのバージョンと合わせて確認する

サブスクリプションサービスが新しいMihomoフィールドを追加した一方で、クライアントには古いカーネルが搭載されたままという場合があります。逆に、旧Clash用のフィールドが出力され、現在の厳格な検証ルールと合わないこともあります。まずクライアントの「概要」または「カーネル」画面で実際のMihomoバージョンを確認し、次に解析ログで示されたフィールドを確認してください。グラフィカルインターフェースを更新しても、カーネルまで同時に更新されるとは限りません。操作後はカーネルのバージョン番号をもう一度確認します。

古い設定は読み込めるのに、新しい設定だけがある日を境に一律でエラーになる場合は、まずサーバー側の生成形式が変わっていないか比較してください。1つのノードが原因で設定全体が失敗している場合は、ログからそのノードのプロトコルとフィールドを特定し、サブスクリプションサービス側で互換性のある形式を再生成してもらいます。

各クライアントで自動更新間隔を設定する方法

クライアントによって「自動更新」の呼び方は少し異なります。以下はClash Verge Rev 2.3.x、Clash Meta for Android 2.11.x、FlClash 0.8.xで一般的な画面をもとにした経路です。マイナーバージョンによってボタンの位置が変わることはありますが、設定対象はノードのヘルスチェックではなく、リモート設定そのものです。

クライアント	設定場所	一般的な間隔
Clash Verge Rev 2.3.x	「サブスクリプション」→対象設定カード→「編集」→「自動更新間隔」	720分または1440分
Clash Meta for Android 2.11.x	「設定」→対象リモート設定の右側メニュー→「編集」→「自動更新」	12時間または24時間
FlClash 0.8.x	「設定」→対象リモート設定→「編集」→「自動更新間隔」	720分または1440分
Mihomo proxy-provider	メイン設定→`proxy-providers`→対象provider→`interval`	21600秒または43200秒

普段使いなら12〜24時間がおすすめ

ノードやルールの変更が少ない場合、1440分に1回で日常的な更新には十分で、サーバーへのリクエストも抑えられます。サービス側が1日に何度もノードを変更する場合は、720分に設定します。明確に素早い同期が必要な場合だけ360分を推奨します。5分や10分に設定する必要は通常なく、HTTP 429を招く可能性もあります。

モバイル端末では、システムのバックグラウンド制御も影響します。Androidの省電力設定によってバックグラウンドタスクが停止されることがあり、iOSでも、クライアントを終了した後に分単位で正確に実行される保証はありません。したがって「12時間」に設定するとは、クライアントが実行できるタイミングでその周期に従って確認するという意味であり、システムが正確な時刻にアプリを起動するという意味ではありません。重要な更新は、クライアントを前面で開いて手動実行してください。

サブスクリプション更新とヘルスチェックを混同しない

サブスクリプション更新はノード、ポリシーグループ、ルールの内容をダウンロードする処理です。ヘルスチェックはテストURLへリクエストを送り、既存のノードが利用可能か判定します。ヘルスチェックを600秒に設定しても、10分ごとにサブスクリプションがダウンロードされるわけではありません。逆に、サブスクリプションを1日1回更新していても、ノードの可用性を10分ごとに確認することは可能です。

100個のノードを含むproviderでは、ヘルスチェックの間隔が短すぎると大量の同時リクエストが発生します。まずは600秒または900秒から始め、端末の消費電力とノード数に応じて調整してください。遅延テスト用URLは軽量なレスポンスを返し、実際の出口への接続性を代表するものである必要があります。

手動で強制更新する正しい手順

強制更新の目的は、新しい設定を取得して読み込み済みであることを確認することです。進捗アイコンが回転しただけで完了と判断してはいけません。次の順番で実行すれば、同時リクエスト、キャッシュによる誤判定、古い接続による干渉を同時に避けられます。

クライアントのログを開き、現在の設定名、更新時刻、カーネルの状態を記録します。
進行中の重複更新を停止し、対象設定の更新ボタンだけを1回クリックします。
リクエストが完了するまで待ち、ログで最終的なHTTPステータスと解析結果を確認します。
設定カードの更新時刻が変わったか、ノード数やポリシーグループが想定どおりか確認します。
新しい設定を明示的に選択し、「設定を再読み込み」またはカーネルの再起動を実行します。
ポリシーグループのノードを選び直し、確認対象のアプリの接続を閉じてから再度開きます。
接続テストページへアクセスするか接続ログを確認し、新しい接続が想定したルールと出口に適用されたことを確認します。

更新に成功したのにノード一覧が変わらない場合は、まずサーバー側の内容が実際に変わったか比較してください。HTTPキャッシュにより 304 Not Modified が返ることがあります。これはクライアントが保持するバージョンが引き続き有効と判断された状態であり、ネットワーク障害ではありません。サーバー側で変更済みなのにクライアントが古い内容を使い続ける場合は、対象のリモート設定を削除して再インポートします。操作前に、ローカル上書き、ポリシーグループの選択、自作ルールを保存してください。

設定を切り替えても、既存のTCPまたはUDPセッションがすべて自動的に移行するわけではありません。ブラウザーの長時間接続、ダウンロード、インスタントメッセージの接続が、以前の出口を使い続けることがあります。確認時は該当アプリの接続を閉じ、必要に応じてアプリを再起動してください。同じ長時間接続を更新するだけでは不十分です。

それでも失敗する場合に残す診断情報

ここまで確認しても更新できない場合は、最小限の診断記録をまとめてください。クライアント名とバージョン、Mihomoカーネルのバージョン、OSのバージョン、失敗時刻、HTTPステータスコード、エラーログの前後各10行、TUNの有効・無効、システムプロキシのアドレス、リスニングポート、直接接続とプロキシ経由それぞれのテスト結果を記録します。

サブスクリプションURLはドメイン名だけを残し、トークンとクエリパラメータは隠してください。設定ファイルに認証情報が含まれていないかも確認します。特定のネットワークでだけ問題が起きる場合は、自宅の固定回線、モバイルデータ、職場のネットワークで比較した結果を追加してください。ネットワークを切り替えるとすぐ復旧するなら、クライアントを何度も再インストールするのではなく、DNS、IPv6、アクセス方針、ローカルゲートウェイを重点的に調べます。

診断の流れは、まずログで段階を特定し、次にURLへ到達できるかをテストし、その後に返却内容とYAMLを確認し、最後にカーネルの互換性、自動更新間隔、設定の再読み込みを確認する、という順番に整理できます。この順番なら、「サブスクリプションが無効」「ダウンロード失敗」「解析失敗」「設定が切り替わらない」を別々の問題として扱え、不要な変更を減らせます。