Clash Verge Rev の rule-providers：interval（自動更新間隔）とキャッシュ path を Windows 11 で揃える実測メモ（2026）

rule-providers が担うレイヤーを誤解しない

ここで扱うのは、ドメインや IP 集合などをまとめたルール素材を HTTP 等で取りに行き、ディスクへキャッシュして rules 側の RULE-SET 行から参照する仕組みです。プロキシノード一覧そのものを更新する購読とはファイルの意味が異なり、設定画面のカードが別々になっているのはそのためです。ノード購読のタイマーだけ短くしても、リストに載っているドメイン行が古いまま、という状態は普通に起きます。逆にルールだけ真新しくても、出口ノードが枯れていれば体験は変わりません。この記事はルール集合まわり専用の間隔と保存場所にフォーカスし、購読側の整理は 購読の自動更新間隔ガイド に任せる二段構成で読むのが安全です。

proxy-groups の自動健全性テスト間隔や、接続ログに出るタイムアウトの切り分けはまた別の論点です。ルール集合の鮮度が疑わしいときと、ターゲット宛ての疎通が疑わしいときではログの見る場所も変わるため、接続系を深掘りする場合は Windows 11 でのログパネル稿 を併用してください。

YAML で見る rule-providers：path と interval の役割

典型的には、キー名は自由ですが、その下に type、取得元 url、ローカル側のファイルパス path、そして interval（秒）が並びます。path は「ダウンロードした中身をどの相対／絶対パスへ保存し直すか」を決め、以後の再取得が成功するとそのファイルが更新されます。interval は「前回の取得から最低どれだけ間を空けて次の自動取得を試すか」の目安です。起動直後の初回取得は別扱いで即時に走ることが多いですが、版やビルドで細部は揺れるため、運用ではログのタイムスタンプを一度拾って自分の環境の癖を把握するのが確実です。

rule-providers:
  example-domains:
    type: http
    behavior: domain
    url: "https://example.com/rules/example.yaml"
    path: ./ruleset/example.yaml
    interval: 86400

Windows 11 でキャッシュ path を実際に追うコツ

相対 path の基準は、実際にコアが読み込んでいるプロファイル（展開後の作業ディレクトリ）です。Clash Verge Rev ではそのルートを GUI から開ける導線（アプリデータやプロファイルディレクトリをエクスプローラーで開く操作）があることが多いので、まずそこを起点に path の断片をつなぎます。例として ./ruleset/example.yaml なら、プロファイル直下に ruleset フォルダが出来上がり、その中の更新時刻が直近の自動／手動取得と一致するかを見ます。

絶対パスを直接書く運用なら、OneDrive 下などクラウド同期の対象フォルダに置かない、読み取り専用マウントに置かない、ウイルス対策のリアルタイムスキャンが極端に重い場所に置かない、といったファイル I/O の前提だけは揃えてください。企業端末ではポリシーで %USERPROFILE% 以外の書き込みが制限されていることもあるため、書き込み不可で取得が黙って失敗するパターンは購読取得と同型です。初回セットアップの注意点は Windows 11 初回セットアップ稿 とも語彙が揃います。

interval の現実的なレンジと「短くしすぎ」問題

公開ルール集合は更新頻度が購読ほど激しくないことが多いので、現場では一日（八六四〇〇秒）前後を既定の足場にし、リストのメンテ情報や自分の運用（たとえば週一でしか見ない）に合わせて数倍長くする選択も合理的です。反対に、開発者がリストを差し替えた直後だけ短い interval を一時的に置き、落ち着いたら長めに戻す、という使い方はよくあります。

常時数分未満へ固定すると、CDN の頻度制限や公開側ポリシーに抵触しやすく、結果として「壊れた」ように見える原因は間隔ではなく 429 や一時ブロックであることがあります。複数端末やスクリプトで同じ url を並列に叩いていないかも含めて、トータルの取得回数で見積もってください。購読側で同じ話を深掘りするなら、前述の購読間隔稿とセットで読むと用語のブレが減ります。

失敗時のリトライをどう期待するか

ネット瞬断や一時的な証明書検証エラーで一度失敗した場合、コアはだいたい次の interval 周期まで静かに待ち、そこでもう一度取得を試みます。その間も最後に成功したキャッシュが残っていれば、多くの構成では古いルール集合を読み続ける動きになります。ユーザーから見ると「更新されない」ように見える一方で、実際にはフェイルセーフとして動いている、という説明がつきやすいです。

すぐに同じ URL を再度叩きたい場合は、GUI 側のプロファイル再読み込みや、該当コンポーネントの手動更新（ビルドにより文言は揺れます）を使い、ログに新しい成功行が出たかを確認します。DNS の向き先や、ルール取得だけがプロキシ経由になる配置など、購読取得と経路が食い違っていないかもあわせて見ると、interval を短くする前に片付く失敗が減ります。

購読更新・GEO データ（MMDB 等）とのタイミング整合

起動直後やスリープ復帰直後に、購読・ルール・GEO 関連の HTTP が密集すると、一時的にタイムアウトが増えたように見えることがあります。設定の美しさとしてすべてを揃えたくなりますが、運用の安定性では十から数十分ずつ位相をずらすほうが効く場面があります。ノード購読はプロバイダ推奨へ寄せ、ルール集合は控えめ、GEO ライブラリはさらに長め、といった階層が典型的です。

GEO 系はアプリの別設定ファイルまたはパッケージマネージャ的な更新導線で管理されていることがあり、rule-providers の interval とキリの良い数字で揃えられないことも普通です。無理に数字を合わせず、「同じ秒にすべてが動く」状態だけ避ける、という割り切りで十分なことが多いです。プロファイルの断片を Mixin で足す立場なら、上書き順序の把握が重要になるため Mixin と Profile マージ稿 も参照してください。

GUI だけでは見えないときのソースエディタ運用

Clash Verge Rev は構成の可視化が進んでいますが、テンプレ作者が rule-providers を別ファイルへ分割していたり、インポート直後に自動整形で順序が変わったりすると、画面上のカードと interval の実体が一瞬ズレたように感じることがあります。その場合はテキスト検索で interval: を総当たりし、同名キーが二重定義されていないかを見ます。二重定義は後勝ちやマージ結果の読みにくさを生むので、名前空間の衝突に敏感になると長期的に楽です。

rules 側で参照している RULE-SET 名と、rule-providers のキー名が一致しているかも、トラブル時の第一スクリーンです。広いリストを複数束ねる設計になっているときは、どのリストがどのトラフィックに効いているかを意識して proxy-groups とルール順序の整理 に立ち返ると迷子になりにくいです。

実測ステップ：Windows 11 で一巡させる

以下は画面ラベルが版で変わっても再現しやすい順序です。(1) アクティブプロファイルを固定する。(2) rule-providers を含む YAML を開き path と interval を読む。(3) エクスプローラーで path 先の更新時刻を確認する。(4) 手動更新または再読み込みで成功ログを一度確認する。(5) 購読・GEO の他タイマーと重ならないよう分数をずらす、の五手順です。ここまで通れば「どれくらいで刷新されるか」「どこを見れば鮮度が分かるか」が言語化できるはずです。

よくある質問

まとめ

rule-providers の interval はルール素材の自動再取得ペース、path はそのキャッシュ実体の置き場所を規定します。Windows 11 ではプロファイルのルートから相対パスを辿り、ファイルの更新時刻とログを突き合わせるのが最小の実測セットです。失敗時は高頻度再試行より経路切り分けを優先し、購読や GEO 更新とはタイマーをずらして HTTP の山を避ける、という秩序だけ押さえれば運用はかなり安定します。

従来の単一用途 VPN 製品の一部は、ルールリストの内部更新を利用者にほとんど見せず、その分きめ細かいドメイン単位の制御まで自分で持ち込みにくいことがあります。Mihomo 互換スタックでは rule-providers とログの両方に触れられるため、間隔とキャッシュ場所を含めて自分のネットワークのリズムに合わせて調整しやすいのが強みです。GUI とテキストのいいとこ取りで運用を組み立てたい方は、各プラットフォーム向けのビルドを ダウンロードページ から一度確認し、更新ログと自分のプロファイル構造を照らし合わせながら選ぶと安心です。

→ 無料ダウンロードの入口で自分向けクライアントを選び、rule-providers を含むプロファイル運用全体を比較検討する