rule-providers で解決すること：手書きリストとの違い

ローカルだけに並べた DOMAIN や IP-CIDR は、サイト側のCDN切替やリスト提供者の改版であっという間に古くなります。そこで rule-providers は、HTTPS など経由で配られたルールセットファイルをコア側が取り込み、キャッシュとして保持しつつ定期的に更新できる仕組みです。interval は、その「定期的」の秒数であり、運用モードによっては省略や既定値依存になることもありますが、読者が自分の更新ポリシーを明示できるレバーです。

検索クエリになりやすい 「ルールセット 自動更新」の本体は、この rule-providers とログ上の取得成功・失敗、そして rules での名前の対応関係に収束します。TUN の全体像やレイテンシ主導のポリシーグループ運用はそれぞれ別の論点ですから、混乱しやすいところは意図的に切り離して読み進められるように書きました。

心のモデル：rules が「辞書」を引くときの流れ

ざっくり言うと、rule-providers は名前付きでルールセットの取り込み設定を並べるブロックで、実際にトラヒック評価に使うときはrules がその名前を参照します。だから「プロバイダ定義だけ足したのに効かない」「逆に名前は合っているのに中身が空」といった現象は、だいたい①取得に失敗している ②参照名が食い違っている ③並び順や別ルールが先に刺さっているのどれかに集約されます。

💡

YAML のインデントはスペース数のズレだけで構造が別物になります。複数ウィンドウで編集中だと混入しがちなので、保存直前にもう一度だけ先頭列を眺める習慣が効きます。

編集前：アクティブなプロファイルと取得 URL の健全性

まず Clash Verge Rev がいま読み込んでいるプロファイルが、あなたがエディタで開いているファイルと一致しているかを確認してください。並行して試していると、「保存したつもりの設定が載っていない」が発生します。続けてルールセットの URL が、ブラウザで開いてステータス 200 で本文が返るか、企業環境ではプロキシ経由しか届かない配布かを見ます。後者では rule-providers 側で取得用の転送経路を指定する説明があるテンプレもあります（購読テンプレに従うのが確実です）。

path が指すオンディスク位置は、環境により既定が決まっていることが多いです。権限やウイルス対策のリアルタイムスキャンでファイル書き込みが遅れると、初回展開だけタイムアウトっぽく見える場合があります。その場合でもログには痕跡が残るので、感覚ではなくログで確定させます。汎用トラブルシュートのログ読みとも相性が良いです。

YAML の骨格：rule-providers と interval が担う仕事

実ファイルは購読提供者のひな型次第ですが、概念として押さえるべき項目は共通しています。type が http などどこから取るか。behavior が classical や domain／ipcidr など中身をどう解釈するか。url と path が取得元と保存先の対。interval が再取得までの間隔（秒）。

💡

チェックリスト（書いた直後に読む）

  • interval を短くすると更新は速く見えますが、配布側の運用にも配慮する
  • behavior とルールセット提供者の説明が一致しているか
  • path がユーザー権限で書ける場所か、既存キャッシュとの衝突がないか
  • url がリダイレクト連鎖で失敗しないか（企業フィルタ含む）

以下は読みやすさのための構成例であり、環境によってキー順や省略可能項目は異なります。実運用では購読の正式なひな型に合わせてください。

# Example only — confirm keys against your subscription template.
rule-providers:
  geo-cn:
    type: http
    behavior: classical
    url: "https://example.com/rules/geoip-cn.yaml"
    path: ./ruleset/geoip-cn.yaml
    interval: 86400

rules:
  - RULE-SET,geo-cn,DIRECT

例では RULE-SET が rule-providers のキー geo-cn を参照している点に注目してください。この名前の完全一致が崩れると、「定義したはずなのに存在しない」と扱われます。

interval の選び方：速さより再現とマナー

短い間隔は急なリスト差分への追従には有利ですが、配布サービス側のキャッシュヘッダやレートリミット、そして自分のブラウザセッションの安定性まで含めてトレードオフになります。現場では一日一回（86400 秒）前後から始めるような保守的な例も多く、問題が見えてからだけ短縮する、あるいはイベント時にだけ手動で再取得するのが運用として堅実です。

ここでのコツは、「更新が走った」のをログやファイル更新時刻で確認できるようにしておくことです。体感だけで短くすると、原因がリストなのか回線なのか区別できなくなります。

⚠️

注意：未知の第三者 URL を試すときはソースの信用性と変更履歴の透明性を確認してください。ルールセットは強い権限を持ちます。取り込み済みリストの異常だけで通信経路が大きく変わるためです。

rules との結線：並び順と PROVIDER の見え方

rules は上から評価されるのが基本なので、広い許可／拒否を先に置きすぎると細かなルールセットが死にます。RULE-SET 系のアイテムをどこへ置くかは、購読テンプレの意図に従うのが最も安全です。もし自分で並べ替えたいときはログで狙い撃ちしているドメインがどこで決着したかを必ず確認し、期待と違えば順序調整またはより具体的な行を追加します。

DIRECT／REJECT／名前付きグループへの宛先選びも、リスト更新と独立ではありません。出口が異なる名前解決経路を踏むグループだったり、GEOIP とルールセットの優先競合があったりすると、リストは新しくても見かけだけ古い体感になります。その場合は別稿の DNS と TUNの整理に戻るのが合理的です。ポリシーグループと遅延テストの稿は出口選びに特化しているのでセットで読むと地図が埋まります。

Clash Verge Rev（Windows）の画面から辿るコツ

ビルドごとのラベル差は許容して、見つけ方としてはプロファイル一覧 → 使用中の編集 → テキスト表示が王道です。ドラッグ＆ドロップで外部エディタに出す構成もあるため、複数行の rule-providers を追うならそちらの方が疲れにくいです。保存後はコアの再読み込み を忘れないでください。TUN とシステムプロキシのどちらを前提にリスト取得の経路を書くかは、環境によります——取得だけが別出口に逸れていると「更新済み」のつもりが実は古いキャッシュのまま、という地雷になります。

  • ダッシュボードで異常終了や再起動保留がないか見る
  • 編集中のファイル名がアクティブ表示と一致するか確認する
  • rule-providers のキー集合とrules側の名前集合を突き合わせる
  • 保存 → 適用／再読み込み → ログまで一気に通す

動作確認：ログ・タイムスタンプ・簡単な疎通

確認の優先順位は次の三段です。(1) コアログに取得失敗／パース警告がない。(2) キャッシュファイルの更新時刻が意図したタイミングで進む。(3) 代表ドメインを開いて想定ポリシーへ刺さっている。この順に並べると、環境依存の細部があっても切り分けが速くなります。

✓

ヒント：mrs 形式など特殊な提供者に切り替えたときは、コア側の対応バージョンと購読文書を同じ版のセットで読むようにしてください。単体では正しそうに見える YAML が、実は前提がズレているパターンは意外と多いです。

テスト環境があるなら、本番と同じ interval ではなく検証だけ短めにしてログの周期を確認し、落ち着いてから本番値へ戻すと事故が少ないです。

長期運用：差分の読み方とロールバックの心構え

ルールセットは自動更新によって静かに挙動が変わります。だから「昨日まで通っていたサイトが今日ダメ」でも、自分のサーバ一覧だけを疑わずリスト差分にも目を向けるのがプロです。運用としては、(a)配布側の変更通知を追えるチャネルを持つ、(b)問題が出たらinterval を一時的に延ばすか手動のみに切り替えて時間を確保する、(c)ローカル検証プロファイルと本番プロファイルを分ける、が実用的です。

外部コントローラ経由での編集運用もあるので、複数入力源がある場合は最終的に読み込まれた YAML がどれかを Verge の表示で固定する癖をつけると早いです。関連話題はexternal-controller とバインドにも触れています。

よくある質問

名前は合っているのにマッチしない

RULE-SET と書く場所での区切りと大小文字、あるいは購読が要求する別タイプ宣言を見逃していないかを確認してください。並び順で上流の許可／拒否が先に決着していないかもログで確認します。

自動更新されているのに古い体感が残る

ブラウザやアプリ側の接続再利用、Secure DNS、およびTUN とプロキシの混線が典型です。Chrome と Secure DNS と併せて切り分けてください。

全部手動同期のほうが安全では

制御できる反面、人が忘れた瞬間にリストだけ劣化します。緩やかな interval と偶発的手動更新のハイブリッドが、多くのデスクトップ用途でバランスが良いです。

まとめ：rule-providers は「リストの寿命」を延ばすスイッチ

シンプルな常時オン型 VPN アプリはリストの粒度をユーザーにほとんど見せず、結果として振り分けの意図がブラックボックス化しがちです。一方でClash／Mihomo と Clash Verge Rev は、ルールセット取得を rule-providers と interval として明示でき、rules との名前対応まで含めて監査できるため、開発や長期運用で「どのリストが効いていたか」を追い込みやすいのが利点です。更新が遅い商用クライアントに縛られるとリストの陳腐化が避けられず、体感も不安定になりがちですが、OSS 側のコアへ追従しやすいスタックでは取得周期と並び順を自分で調整できる余白があります。

本稿で示した順にYAML を突き合わせ、名前とパスと間隔を点検し、ログで取得完了まで確認するだけでも、運用初期の地雷はほとんど避けられるはずです。検証済みビルドで環境を揃えるなら、こちらから入手できます：無料ダウンロード Clash で安定したブラウズ体験を始める。