Clashのサブスクリプション更新に失敗する原因と自動更新間隔の設定方法

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

Clashクライアントの「サブスクリプション更新」では通常、リモートの内容をダウンロードし、設定を解析して、保存または読み込む処理が行われます。ダウンロードに成功しても、設定が正常に動作するとは限りません。既存のノードで通信できていても、サブスクリプションURLが有効とは限りません。エラー内容を確認してから、URL、通信経路、コアのどれを見直すか判断しましょう。

1. 現在使える設定は残し、サブスクリプション名、最後に更新に成功した日時、現在選択中の設定を記録します。
2. サブスクリプションを1つだけ選んで手動更新し、操作時刻を記録してから、クライアントのログで該当する記録を確認します。
3. エラーがHTTPステータス、接続タイムアウト、証明書検証、YAMLやプロトコル項目の解析のどれに該当するかを切り分けます。
4. 一度に変更するのは1項目だけにします。更新経路を変更したら、まず再試行してください。DNS、ノード、コアを同時に変更するのは避けましょう。

エラーメッセージから確認箇所を絞る

これらの対応関係は原因を絞り込むための目安であり、ステータスコードだけで原因を断定することはできません。たとえば403はサイト側の防御措置による場合もあり、アカウントの期限切れとは限りません。200が返っても、実際には有効なサブスクリプションではなくログインページが表示されていることがあります。

URLが無効：認証情報、有効期限、レスポンス本文を確認

まず、サービス提供元の管理画面からClashまたはmihomo向けのサブスクリプションURLをコピーし直してください。ブラウザーのアドレスバーに表示される管理画面のURLや、QRコード表示用のページをサブスクリプションURLとして使わないでください。コピー時はクエリパラメーターを含めてURL全体を保持し、末尾の空白、改行、日本語の句読点が混入していないか確認します。

次の4項目を順に確認

• アカウントの状態：プランの有効期限、データ容量、サブスクリプションの利用権限を確認します。容量超過後に案内文を返すサービスもあれば、設定は返すもののノードが使えなくなるサービスもあります。
• URLがリセットされていないか：サブスクリプショントークンをリセットすると、古いURLがすぐに無効になる場合があります。更新ボタンを繰り返し押すのではなく、登録済みのサブスクリプションURLを変更してください。
• URLがリダイレクトされていないか：301や302でログインページに転送されると、クライアントが最終的にHTMLを取得することがあります。最初のリクエストのステータスだけでなく、最終レスポンスを確認してください。
• リクエスト制限にかかっていないか：複数の端末で同じURLを共有して頻繁に更新すると、429が返される場合があります。自動更新を一時停止し、制限が解除されてから端末ごとに再開してください。

ブラウザーでファイルをダウンロードできても、確認できるのはブラウザーの通信経路が使えることだけです。ブラウザーではログインCookieが使われていたり、システムプロキシや別のDNSが利用されていたりする一方、クライアントの更新機能は同じ設定を使うとは限りません。「ブラウザーで開ける」だけで判断せず、両方の通信がプロキシ経由かどうかを記録して比較しましょう。

証明書の期限切れ、発行者が信頼されていない、ホスト名が一致しないなどのエラーが出た場合は、まず端末の日付とタイムゾーン、現在のネットワークでログイン認証が必要かを確認します。サブスクリプションサービスの証明書の状態を確認してから対処してください。証明書検証を無効にして問題を回避してはいけません。サブスクリプションの認証情報もHTTPSで保護する必要があります。

形式が非対応：完全な設定ファイルとノードプロバイダーを区別する

「サブスクリプション」は特定のファイル形式を指す言葉ではありません。一般的な内容には、完全なClash YAML、ノードのみを含むプロバイダーファイル、Base64でエンコードされた共有リンクの集合があります。どの形式も、すべてのインポート画面で相互に使えるわけではありません。ダウンロード後に解析エラーが出たら、まず内容の種類を確認し、次にクライアントが使うコアを確認しましょう。

YAML構文エラーとプロトコルエラーは分けて対処する

インデントの誤り、Tab文字、特殊文字の引用漏れは、YAMLの解析エラーを引き起こすことがあります。ログに行番号が表示されたら、ローカルのエディターで該当行とその前の行を確認してください。完全なサブスクリプションには機密性の高いノード情報が含まれるため、公開オンラインのYAML検証ツールにアップロードしないでください。

ログに非対応のプロキシタイプが明記されている場合、問題はインデントではなくコアの対応状況にある可能性が高いです。Clashはクライアントのエコシステムで広く使われる呼称で、Clash Metaは後にmihomoという名称になりました。クライアントによって内蔵コアとそのバージョンは異なります。古いコアは画面上の名称を変更しても、新しいプロトコルに対応できるようにはなりません。クライアントの「バージョン情報」またはコア情報の画面で、実際のコアを確認してください。

修正時は、まずサービス提供元が用意した対応形式を使うか、対象の設定に対応するクライアントを選んでください。エラーになったプロトコル項目をそのまま削除するのは避けましょう。解析を通過しても、接続時に失敗する可能性があります。リモート設定へのローカル変更は次回更新時に上書きされることがあります。変更を維持するには、クライアントが対応するオーバーライドまたはマージ機能を使ってください。

更新時にプロキシ経由にならない：システムプロキシとサブスクリプションのダウンローダーを区別する

システムプロキシを有効にしても、サブスクリプションのダウンロードが必ずプロキシ経由になるとは限りません。クライアントには独立したHTTPダウンローダーがあり、「プロキシを使用」「プロキシ経由で更新」「システムプロキシを使用」などの設定が別々に用意されている場合があります。コアが管理するproviderも別の通信経路です。TUNは一部の通信経路を変更できますが、すべての更新リクエストが特定のノードを使うとは限りません。

条件をそろえた2回のリクエストで経路を比較する

1. 使用可能な設定を1つ保存し、通信可能なノードを選択して、クライアントのローカルプロキシ待ち受けポートを確認します。
2. 対象のサブスクリプションの編集画面で現在の設定を記録し、更新専用のプロキシ設定をオフにして手動更新を1回実行し、ログを確認します。
3. 該当するプロキシ設定をオンにして、もう一度更新します。接続タイムアウト、HTTPステータス、最終的な解析結果を比較してください。
4. 直結では成功し、プロキシ経由では失敗する場合は、出口ノードとルールの選択を確認します。プロキシ経由では成功し、直結で失敗する場合は、有効な更新経路を維持してください。

実際のHTTPまたはmixedの待ち受けポートが7890の場合、プロキシアドレスを明示するにはhttp://127.0.0.1:7890を指定できます。ここでの7890は説明用のポート番号で、すべてのクライアントの初期値ではありません。クライアントのポート設定を確認してください。SOCKSポート、HTTPポート、コントロール用ポートはそれぞれ別のものです。

同じURLがモバイル回線では成功し、現在のWi-Fiではタイムアウトする場合、ネットワークへのログイン状態、DNSの名前解決、接続先サイトへの到達性を確認します。ネットワークの切り替えは原因を絞るための手段です。TUNを同時に有効にしたり、DNS設定全体を書き換えたりする必要はありません。DNSをテストする場合は、変更前後の名前解決結果も記録し、一時的な復旧を恒久的な解決と誤認しないようにしてください。

自動更新間隔：クライアントのサブスクリプションとproviderは別々に設定

完全なリモート設定の定期ダウンロードは通常クライアントが管理します。一方、mihomoのHTTPノードプロバイダーはproxy-providers内の設定で制御します。両方を併用できますが、時間の単位や実行条件は異なります。完全な設定のトップレベルにintervalを追加しても、クライアントが自動認識するとは限りません。

クライアントごとの設定確認場所

• Clash Verge Rev：「サブスクリプション」を開き、対象のリモートサブスクリプションカードのメニューから編集画面に進みます。サブスクリプションURL、更新間隔、ダウンロード時のプロキシ設定を確認してください。項目名はバージョンによって異なるため、画面に表示される単位を確認しましょう。
• Clash for Windows：「Profiles」でリモート設定を探し、右クリックメニューから設定の編集や更新に関する項目を確認します。旧バージョンでは画面や項目が異なるため、他のクライアントのメニュー手順をそのまま当てはめないでください。
• Clash for Android：「設定」を開いて該当するリモート設定を編集し、自動更新の有効・無効と更新間隔を確認します。OSがアプリのバックグラウンド動作を制限していないかも確認してください。間隔を設定しても、スリープ中に必ず実行されるとは限りません。
• mihomoを直接実行する場合：メイン設定のproxy-providersを確認します。HTTP providerのintervalの単位は秒です。メイン設定ファイル全体の定期的な再ダウンロードは、別途、外部の管理プログラムが行う必要があります。

まずクライアントの「バージョン情報」画面でバージョンを記録し、現在のバージョンに合った画面で操作してください。「更新時にプロキシを使用」という項目が見当たらなくても、初期設定で有効だとは限りません。そのバージョンの設定説明を確認するか、ログで更新機能の実際の動作を確認しましょう。

単位を換算して、過度な頻度のリクエストを避ける

個人で使う端末なら、まず6時間間隔に設定し、サービス提供元の推奨に応じて調整できます。常時稼働し、6時間ごとに更新するとサブスクリプション1件あたり定期リクエストは約4回です。10分ごとでは約144回となり、手動更新や失敗時の再試行は含まれていません。ノードの変更が少ないサブスクリプションでは、頻繁に更新してもリクエスト数が増えるだけになりがちです。

HTTP providerの名前がprimaryの場合、以下は更新間隔とダウンロード経路の項目のみを示します。これは設定の一部であり、単独で実行できる完全な設定ではありません。既存のtype、url、pathなどの項目は残してください。

proxy-providers:
  primary:
    interval: 21600
    proxy: DIRECT

この項目に対応するmihomoでは、providerのproxyでダウンロードに使う通信先を指定し、DIRECTは直結を表します。プロキシやプロキシグループを指定する場合は、名前が現在の設定に存在することを確認し、そのprovider自身からしか取得できないノードに依存しないようにしてください。この項目は、クライアントが外部から設定全体をダウンロードする動作には影響しません。

ノードのヘルスチェックに使うhealth-check.intervalは別のタイマーで、ノードの使用可否を確認するものであり、ノード一覧の再ダウンロードには使われません。同様に、rule-providersの更新間隔はルールセットにのみ適用され、サブスクリプションのノード更新間隔とは別です。

保存後に確認すること：更新時刻、ノードの変化、設定の読み込み

自動更新を設定したら、まず手動更新を1回実行して通信経路を確認し、次回の予定時刻に実行されるか観察します。端末のスリープ、プロセスの終了、Androidのバックグラウンド制限、クライアントのスケジュール方式などにより、実際の実行が設定時刻より遅れる場合があります。更新間隔をOSレベルの正確なスケジュールとして扱わないでください。

1. ダウンロードの完了を確認：対象のサブスクリプションの更新時刻とログを確認します。画面に一瞬表示される成功通知だけで判断しないでください。
2. 対象が正しいか確認：更新されたのが現在選択中の設定か、providerが更新されているかを確認します。
3. 内容が使えるか確認：ノード一覧とプロキシグループが引き続き有効か確認します。ノード数が変わらなくても、更新が失敗したとは限りません。サービス側の内容に変更がなかった可能性もあります。
4. 読み込み結果を確認：設定が正常に適用されたか、手動で選択していたノードが削除または改名されていないか確認し、必要に応じて出口を選び直します。
5. 定期実行を確認：予定された更新時刻と実際の実行時刻を記録します。手動更新しか成功しない場合は、自動更新の設定、バックグラウンド実行の権限、アプリの起動状態を確認してください。

解決しない場合に伝える情報

サービス提供元またはクライアントのメンテナーに問い合わせる際は、クライアントのバージョン、コアのバージョン、OSのバージョン、エラー発生時刻、HTTPステータスコード、直結とプロキシ経由でのテスト結果の違いを伝えてください。ログに含まれるサブスクリプションURL、ノードのパスワード、認証ヘッダーは事前に削除します。これらの情報があれば、サービス側の拒否、ダウンロード経路の異常、設定の解析エラーを切り分けられます。

対応の順番は、まずURLと権限を確認し、次にレスポンス形式を確認してから、更新経路を比較し、最後に適切な更新間隔を設定するのが基本です。手動更新が安定して成功して初めて、自動更新が役立ちます。間隔を短くしても、無効なURLや非対応の設定は解決できません。