サブスクリプションの自動更新：何が更新されるのか

Clashのサブスクリプション自動更新とは、クライアントまたはコアが設定した間隔でサブスクリプションURLに再接続し、サーバーから設定やプロキシノードの一覧を取得する機能です。クライアントのインストーラーを更新する機能でも、すべてのノードの速度を測定する機能でもありません。更新間隔を設定する前に、使用中の設定がリモートサブスクリプションなのか、PCから読み込んだローカルのYAMLファイルなのかを確認しましょう。

  • リモート設定のサブスクリプション：通常はクライアントが管理し、ノード、プロキシグループ、ルール、DNS設定などが含まれます。更新後にどの内容が反映されるかは、クライアントのマージやオーバーライドの仕組みによって異なります。
  • ローカル設定ファイル：ディスク上に設定内容があるだけで、リモートの配信元がなければ、定期チェックを有効にしても新しいノードは取得できません。
  • ノードプロバイダー：mihomoのproxy-providersはノードを個別に取得できます。更新頻度は各プロバイダーの設定で制御します。
  • ルールプロバイダー：rule-providersが更新するのはルールセットです。サブスクリプションアカウントのノード更新には使いません。

主要クライアントで自動更新を設定する場所

クライアントごとにサブスクリプション管理画面は異なり、同じクライアントでもバージョンによってボタン名が変わることがあります。まずサブスクリプションまたは設定一覧を開き、使用中のリモート設定カードを見つけて、そのカードの編集メニューを開きましょう。全般設定だけを探したり、アプリのバージョン自動確認をサブスクリプション更新と取り違えたりしないでください。

Clash Verge Rev：サブスクリプションカードから編集画面を開く

  1. 左側の「サブスクリプション」を開き、現在有効なリモートサブスクリプションカードを確認します。
  2. カードのその他メニューを開いて「編集」を選び、更新間隔や自動更新に関する項目を探します。
  3. まず項目の単位を確認してください。「分」と表示されている場合は、6時間ごとの更新なら360を目安に設定します。秒単位の21600をそのまま入力しないでください。
  4. 保存したら、同じカードから一度「更新」を実行し、リモートURLが有効であることを確認してから、その後の自動更新を見届けます。

カードにリモートURLがない場合は、ローカル設定を選んでいないか確認してください。サブスクリプションのグローバル拡張スクリプト、オーバーライド設定、リモートの元データはそれぞれ別の要素です。更新結果が想定と違うときは、リンクを何度も読み込み直すのではなく、ローカル側の処理も確認しましょう。

FlClash：設定の詳細画面で更新オプションを確認

「設定」を開き、対象のリモート設定の編集または詳細画面で、自動更新のオン／オフ、更新間隔、サブスクリプションURLを確認します。項目名はバージョンやプラットフォームによって異なるため、画面に表示されている時間単位に合わせて入力してください。使用中のバージョンに手動更新しかない場合は、設定項目の更新操作を使いましょう。YAMLの最上位にauto-updateという項目を独自に追加してはいけません。

Clash for Windows：旧版のProfiles画面を確認

旧版のClash for Windowsを使用している場合、リモートサブスクリプションはProfilesにあります。サブスクリプションカードを右クリックし、編集や更新に関する項目を確認できます。このクライアントはすでにメンテナンスが終了しているため、古い解説にあるボタンの場所が現在の他のクライアントにも当てはまるとは限りません。移行する前にサブスクリプションの配信元と必要なローカルオーバーライドを保存し、ダウンロードセンターからOSに合ったクライアントを選んでください。

更新間隔の決め方：まずは6時間、必要に応じて調整

サブスクリプションの提供元から指定がある場合は、その指示を優先してください。指定がなければ、6時間ごとを初期設定の目安にできますが、必須の基準ではありません。以下は設定の目安であり、クライアントの初期値や通信環境の実測値ではありません。

利用状況 設定の目安 追加操作が必要なタイミング
普段使いでノードの変更が少ない 6～12時間 ノード変更の通知を受けたら手動で更新
提供元が頻繁にノードを変更する 1～3時間 この頻度でのリクエストが許可されているか、まず提供元に確認
たまに使う予備のサブスクリプション 24時間 実際に使う前に手動更新して接続をテスト
契約更新、URLの再発行、プラン変更 更新間隔を常時短くする必要はありません 有効なURLを確認したら、すぐに手動更新

更新間隔を1分にしても、通常はメリットがありません。サーバーに新しい内容がないままリクエストだけが増え、429で制限されることもあります。リクエストが続けて失敗する場合、間隔を短くしてもエラーログが増えるだけで、無効なURLやDNS障害は解決しません。

分・時間・秒の単位を混同しない

  • 6時間 = 360分 = 21600秒。
  • 12時間 = 720分 = 43200秒。
  • 24時間 = 1440分 = 86400秒。

0を入力すれば必ず無効になるとは限りません。クライアントによっては、オフ、既定値の使用、無効な入力のいずれかとして扱われます。明示的なオン／オフ設定があればそちらを使い、項目の説明も確認してください。変更後は編集画面を開き直し、値が保存されているか確認しましょう。

mihomoのintervalとクライアントの定期更新の違い

GUIクライアントで通常のサブスクリプションを読み込んでいるだけなら、クライアント側の更新間隔を設定すれば十分です。mihomoの設定を自分で管理し、HTTP形式のproxy-providersでノードを取得する場合は、コア側のintervalも関係します。この項目の単位は秒です。クライアントの画面で分単位が使われていても、同じ設定ではありません。

たとえば、既存のHTTPノードプロバイダーを6時間ごとに更新する場合は、プロバイダーの既存設定にある次の1行を変更します。これは一部の項目だけを示す例で、単独で実行できる完全な設定ではありません。既存のサブスクリプションURL、パス、その他の必須項目はそのまま残してください。

interval: 21600

同じプロバイダー内のhealth-check.intervalはヘルスチェックの間隔であり、サブスクリプションの取得間隔ではありません。ルールプロバイダーにも独自のintervalが設定されることがありますが、更新対象はルールファイルです。同じ名前の項目を見つけたら、まず設定のどの階層にあるかを確認してから変更しましょう。

サブスクリプションの更新に失敗する場合：URL・ネットワーク・形式を切り分ける

「更新に失敗しました」と表示されたら、具体的なエラー、失敗した時刻、使用中のネットワークを記録します。トラブルの調査中にまだ使える古い設定を削除しないよう、元のサブスクリプションカードは残してください。何度も連続してクリックするより、状況を確認しながら一度手動更新するほうが原因を特定しやすくなります。

401・403・404：まずサブスクリプションの配信元を確認

  • 401：認証やトークンに関係することが多いため、アカウントの状態とURLが再発行されていないか確認します。
  • 403：アクセス制限、防御ポリシー、アカウント権限などが原因として考えられます。ステータスコードだけで料金未払いと判断することはできません。
  • 404：URLが途中で切れていないか、パスが変更されていないか、提供元のログインページURLを誤って使っていないか確認します。

提供元のアカウントページからサブスクリプションURLをコピーし直し、前後の空白や改行がないか確認します。URLにはアカウントのトークンが含まれることが多いため、チャット、問い合わせ用のスクリーンショット、オンライン変換サイトなどに公開しないでください。漏えいした場合は、提供元の管理画面でURLを再発行し、クライアントに保存したURLも更新します。

timeout・DNS・TLS：サブスクリプション取得時のネットワークを確認

timeoutはリクエストが制限時間内に完了しなかったことを示します。no such hostは通常、ドメイン名の名前解決に関するエラーです。証明書に関するTLSエラーが出た場合は、システムの日付と時刻、ネットワーク環境を確認してください。ホテルや学校のネットワークでWeb認証が済んでいないと、リクエストがログインページに転送されることもあります。

  1. 一般のWebページが開けることを確認し、現在のネットワークで必要なログイン認証を済ませます。
  2. システム時刻を確認し、競合を切り分けるため、他のプロキシやVPNツールを一時的に停止します。
  3. クライアントに「プロキシ経由で更新」などの設定がある場合は、サブスクリプション取得に使われる経路を個別に確認してから再テストします。クライアントによって、サブスクリプション取得時に適用される設定は異なります。
  4. スマートフォンのテザリングに切り替えて再テストします。テザリングでは成功し、元のネットワークで失敗する場合は、元のネットワークのDNS、認証、アクセス制限を優先的に調べてください。

TLSエラーをなくすために、証明書の検証を無効にしたまま使わないでください。現在のノードがすでに使えず、更新リクエストにもそのノードが必要な場合、復旧できない状態に陥ることがあります。その場合は、利用可能なノード、許可されている直接接続、または別のネットワークを試してください。定期更新の間隔を短くするだけでは解決しません。

YAML・解析エラー：実際に取得した内容を確認

HTTPリクエストが成功しても、有効な設定を取得できたとは限りません。サーバーから契約期限の案内、ログインページ、互換性のない形式のデータが返される場合があります。クライアントのログで解析結果を確認し、URLがClashまたはmihomoで使える設定形式を返しているか確かめてください。必要であれば提供元に問い合わせ、根本原因を隠すために生成済みサブスクリプションファイルのインデントをむやみに変更しないでください。

ログに429が表示されたら、連続更新を止めてサーバーの案内に従って待ちます。待ち時間が明示されていない場合は、更新間隔を延ばしてから再試行してください。複数の端末で同じサブスクリプションを使っていると、それぞれのリクエストが提供元の利用制限に合算されることもあります。

手動更新後に新しい設定が反映されたか確認する

  1. 正しいカードを更新する。サブスクリプション一覧で現在使用中の設定を見つけ、そのカードの更新または再読み込みボタンを押して、結果が返るまで待ちます。
  2. 更新時刻を確認する。表示されているのが前回の試行時刻ではなく、今回の成功時刻であることを確認します。ログがある場合は、成功記録も確認してください。
  3. 実際の変更点を照合する。提供元からの案内とノード名や数を比較します。ノードに変更がないからといって、更新失敗とは限りません。リモート側の内容が変わっていない可能性もあります。
  4. 現在有効な設定を確認する。無効なサブスクリプションを更新しても、通信に自動で反映されるとは限りません。アクティブな設定を自動で再読み込みするクライアントもあれば、再選択や適用が必要なクライアントもあります。
  5. 現在のプロキシグループをテストする。選択中のノードを確認し、遅延テストと実際のアクセスを試します。ノード一覧に新しい項目が表示されたことだけで、接続が正常だと判断しないでください。

契約更新後も利用量が古いまま表示されていても、ノード一覧が更新されていないとは限りません。通信量や有効期限の情報はサーバーから返されることがあり、表示の有無や更新タイミングはクライアントと提供元の対応状況によって異なります。アカウント画面の状態と更新ログを照らし合わせて判断してください。

自動更新が予定どおり実行されない：バックグラウンド動作とスリープを確認

更新間隔の設定は、常時稼働するサーバー上のタスクとは限りません。PCの電源が切れている、クライアントを終了している、スマートフォンのアプリがシステムによってバックグラウンド動作を制限されている場合、予定どおりにリクエストされるとは限りません。端末の復帰後に更新がすぐ実行されるかどうかも、クライアントのスケジューラーの実装によります。

  • PC：クライアントのプロセスが動作中か確認し、「ウィンドウを閉じる」と「アプリを終了する」を区別してください。OS起動時に自動起動させる場合は、該当する起動設定も有効にします。
  • Android：バッテリー最適化とバックグラウンド動作の権限を確認します。VPNサービスが動作していても、サブスクリプションの更新タスクが想定どおり実行されるとは限りません。
  • 長時間スリープしていた端末：使用を再開したら、まず手動で更新してください。スリープ中に更新されなかっただけで、サブスクリプションが無効だと判断しないようにしましょう。