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

まず確認：サブスクリプション更新・ノード速度測定・接続状態の違い

Clashのサブスクリプション自動更新とは、クライアントが定期的にサブスクリプションURLへアクセスし、取得した内容でローカル設定やノードプロバイダーを更新する機能です。ノードの速度測定や、接続先の定期的な切り替えとは別の機能です。サーバー側で内容が変更されていなければ、更新に成功してもノード数が変わらないことがあります。

設定する前に、サブスクリプションをどこで管理しているか確認しましょう。Clash Verge Revなどのデスクトップクライアントでは、通常、画面上でリモート設定を管理します。mihomoコアを直接動かしている場合は、proxy-providersでノードを取得することがあります。どちらにも「更新間隔」の設定がありますが、対象や単位、タイマーを管理するプロセスは異なります。

• リモート設定の更新：設定ファイル全体をダウンロードします。ノード、プロキシグループ、ルール、DNS設定などが同時に変更される場合があります。
• ノードプロバイダーの更新：特定のproxy-providersに対応するノード一覧だけを更新します。メイン設定のルールは自動では置き換わりません。
• ヘルスチェック：ノードが利用できるかを確認します。health-check.intervalは検査間隔であり、サブスクリプションのダウンロード間隔ではありません。

Clash Verge系クライアントで自動更新を設定する場所

ここでは、Clash Verge Revでよく見られる画面を例に説明します。バージョンによっては、カードの右クリックメニューや「その他」メニューに設定項目があります。項目名も「更新間隔」や「自動更新」など異なる場合があります。編集対象がローカルのYAMLファイルではなく、リモートサブスクリプションであることを確認してください。

1. 左側の「サブスクリプション」を開き、使用中のサブスクリプションカードを探して、表示されている最終更新時刻を控えます。
2. サブスクリプションカードを右クリックし、「情報を編集」を開きます。「その他」メニューがあるバージョンでは、同じカードのメニューから編集画面に進みます。
3. サブスクリプションURLがサービス提供元の最新のものか確認し、「更新間隔」を見つけて、項目に表示された単位で値を入力します。
4. 自動更新の切り替え項目が別にある場合は、有効にして保存します。単位が分なら、12時間は720、24時間は1440です。
5. サブスクリプションカードに戻り、「更新」を一度実行します。ダウンロードや解析のエラーがないことを確認し、最終更新時刻が変わったかチェックします。

「情報を編集」と「ファイルを編集」は別の操作です。前者では通常、URL、名前、更新スケジュールを設定し、後者では設定ファイルの内容を変更します。完全な設定ファイルのトップレベルにinterval: 720と書き足しても、クライアント独自の定期更新タスクの代わりにはなりません。

更新間隔を設定したのに自動更新されないのはなぜ？

デスクトップクライアントの定期タスクは、通常アプリのプロセスが動作している間に実行されます。ウィンドウを閉じてもタスクトレイに残っている状態と、タスクトレイから終了した状態は異なります。パソコンがスリープ中は、予定どおりにネットワークへアクセスできません。復帰後すぐに更新されるかはクライアントの仕様によるため、スリープ前に設定した時刻だけでは判断できません。

• まずクライアントを起動したままにして、手動更新が成功するか確認します。
• 「スタートアップ時に起動」と「起動時に更新」は別の設定です。前者を有効にしても、後者が実行されるとは限りません。
• 同じ名前の別のサブスクリプションカードを編集していないか、変更した項目が現在有効な設定か確認します。
• 0を「すぐに更新」と決めつけないでください。定期更新の無効化や既定値の使用を意味する場合があるため、画面上の説明を確認しましょう。

更新間隔は何時間がいい？6・12・24時間の目安

更新間隔は、サブスクリプションの内容が変わる頻度を基準に決めます。速度測定の結果で決めるものではありません。ノードの遅延が大きくなっても、サブスクリプションが古いとは限りません。ノードが停止し、サービス提供元が代替先を公開している場合は、サブスクリプションの更新で解決することがあります。

表の値は設定の目安であり、サーバー側の動作を保証するものではありません。特別な理由がなければ、1分ごとの更新は避けましょう。1日あたり1440回のリクエストが発生し、複数の端末で同じURLを使うとリクエスト数はさらに増えて、サーバーのレート制限にかかる可能性があります。複数のノードで障害が起きた場合は、まず手動で一度更新してください。何度も更新ボタンを押しても、サーバーの復旧が早まるわけではありません。

サブスクリプションの応答やサービス提供元の案内に推奨周期が記載されている場合は、クライアントがその設定を反映しているかも確認しましょう。読み込み時に表示された既定値だけで単位を判断しないでください。特に旧クライアントから設定を移行した場合は注意が必要です。

mihomoのproxy-providers：intervalの単位は秒

mihomoの設定を自分で管理する場合、HTTPノードプロバイダーのintervalは各プロバイダーの設定内に記述し、単位には秒を使います。以下は、12時間ごとにノードをダウンロードし、5分ごとにヘルスチェックを行う例です。この2つの間隔はそれぞれ独立しています。

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

proxy-groups:
  - name: Subscription
    type: select
    use:
      - remote-nodes

例にあるsubscription.example.netは説明用のドメインで、ノードを取得することはできません。実際に利用する際は、自分のノードプロバイダーURLに置き換え、応答内容がプロバイダー形式に対応しているか確認してください。Clashの完全な設定ファイルと、ノードだけを含むプロバイダーファイルは、どの環境でも相互に置き換えられるわけではありません。ヘルスチェック先も、現在のネットワークからアクセスできるものを選びましょう。

• interval: 43200：プロバイダーのリモートデータを更新します。メイン設定全体のダウンロード間隔は制御しません。
• health-check.interval: 300：ノードの接続確認を行います。新しいノードはダウンロードしません。
• path：ローカルのキャッシュファイルを指定します。コアの実行ユーザーに、該当ディレクトリへの書き込み権限が必要です。
• use：プロキシグループからプロバイダーを参照させます。プロバイダーを定義しただけでは、そのノードがプロキシグループに自動追加されるわけではありません。

メイン設定を変更したら、mihomoに設定を再読み込みさせて、新しい更新間隔を反映します。メイン設定がクライアントのサブスクリプション更新で生成される場合、ダウンロード済みファイルを直接編集しても、次回の更新で上書きされることがあります。ローカルの変更を保持するには、クライアントが対応するオーバーライドやマージ機能を使いましょう。

更新に失敗する主な原因：エラーの種類から確認

1. タイムアウト・ドメイン名の解決失敗：サブスクリプションURLへの通信経路を確認

ブラウザーでサイトを開けても、それだけで分かるのはブラウザーからの通信が成功していることです。サブスクリプションのリクエストはクライアントのバックグラウンドから送信され、ブラウザー拡張機能や同じシステムプロキシを使うとは限りません。まずログに記録されたサブスクリプションのドメインとエラーを確認し、DNSの名前解決失敗、TCP接続のタイムアウト、TLSハンドシェイクの失敗を切り分けます。

自分の端末で、URLから返るHTTPステータスとコンテンツタイプを確認できます。ただし、サブスクリプションURL全体を公開の検査サイトに送信しないでください。ブラウザーにログイン画面や認証画面が表示される場合、ステータスが200でも、クライアントはHTMLをClashの設定として解析できません。

2. 使用中のプロキシが利用できない：更新リクエストが障害中のノードに依存

クライアントによっては「プロキシ経由で更新」などのダウンロード方法を選べます。ルールによってサブスクリプションのドメインが現在使えないノードに割り当てられていると、そのノード経由で更新しようとして行き詰まります。まず利用できることが分かっているノードに切り替えて手動更新してください。サブスクリプションURLが直接接続に対応している場合は、クライアントの機能で直結更新に切り替える方法もあります。

この問題だけを理由に、すぐにすべてのプロキシ設定を無効にしないでください。サブスクリプションサイトへのアクセスにプロキシが必要な場合、直結を強制すると同じ失敗が繰り返されます。また、TUNモードにすれば必ずサブスクリプションのリクエストがプロキシ経由になるわけではありません。実際の通信経路は、ルーティング、ルール、アプリのリクエスト処理によって決まります。

3. ローカルプロキシのポート異常：待ち受けポートと設定を照合

たとえばクライアントの混合ポートを7890に設定しているのに、外部ツールが古いポート7897へ接続していると、接続拒否が発生することがあります。ここに示した数字は切り分け用の例です。実際の値は現在のクライアント設定で確認し、どれか一つのポートをすべてのクライアント共通の既定値と思い込まないでください。

• プロキシクライアントを2つ同時に起動していて、別のプロセスが使用したいポートを占有していないか確認します。
• ログにaddress already in useまたはconnection refusedと表示されていないか確認します。
• ポートを変更した場合は、システムプロキシ、ブラウザーのプロキシ拡張機能、ターミナルのHTTP_PROXY・HTTPS_PROXY環境変数も確認してください。

ポートの競合が必ずサブスクリプションのダウンロードを妨げるわけではありません。更新リクエストがそのローカルプロキシポートを使っている場合に限り、この経路で失敗します。ログにサーバーからの403応答が記録されているなら、ポートを何度も変更するのではなく、URLのアクセス権を確認しましょう。

4. 401・403・404・429：権限、リンク、リクエスト制限を確認

401は通常、認証に関するエラーです。403はアクセス制限やサイト側の防御、404はURLのパスが無効になっている可能性があります。429はリクエスト過多を示します。これらのステータスだけで契約期間切れとは断定できないため、サービス提供元のアカウント画面や応答内容も確認してください。

サービス提供元のアカウント画面から、Clashまたはmihomo用のサブスクリプションURLをコピーし直し、URLのリセット状況、アカウントの有効期限、データ通信量の上限を確認します。429が返されたら、まず連続した再試行を停止してください。Retry-Afterが示されている場合は、その時間だけ待ち、各端末の自動更新間隔も長くします。

5. ダウンロードできても解析に失敗する：応答形式とコアの対応状況を確認

「解析エラー」と「ネットワークのタイムアウト」は別の問題です。応答がYAML形式か、Webページの共有URLを誤ってコピーしていないか、別のクライアント向けのサブスクリプション形式を取得していないか確認しましょう。新しいプロトコルやフィールドを使うには、mihomoコアの更新が必要な場合もあります。画面が開けても、コアがすべてのノード形式を認識できるとは限りません。

使える旧設定を、バックアップを取らずに削除しないでください。現在の設定を残したうえで、ダウンロード内容とエラー行番号を確認します。YAMLを調べる際は、インデントにスペースを使い、同じ階層の幅をそろえてください。特殊文字を含むURLは引用符で囲みます。

変更後の確認手順とサブスクリプションURLの保護

設定後は、「手動ダウンロードの成功」と「定期タスクの実行」をそれぞれ最低1回確認してください。前者でURLと現在のネットワークが使えることを、後者で自動更新の設定が有効になっていることを確認できます。サーバーから同じ内容が返される場合もあるため、ノード数だけで判断しないでください。

1. サブスクリプション名、更新時刻、設定した間隔（例：720分）を記録します。
2. 手動更新を実行し、ダウンロード、解析、設定読み込みのエラーがログにないことを確認します。
3. クライアントを起動したまま、更新周期が一周するまで待ち、更新時刻と該当するログを確認します。
4. ダウンロードに成功してもノードが変わらない場合は、現在有効な設定とプロバイダーの参照先を確認し、サーバー側で新しい内容が公開されているかも確認します。
5. 確認が済んだら通常の更新間隔に戻し、テスト用の短い間隔を複数の端末で使い続けないようにしましょう。

確認は「更新対象と単位を確認 → 手動更新 → エラーの種類を確認 → 通信経路を確認 → 定期実行を確認」の順に進めるとスムーズです。システムプロキシ、ルールモード、TUNの設定を確認する場合はトラブル対処を、サブスクリプションを初めて追加する場合は設定ガイドをご覧ください。