rule-providers で分岐ルールを自動更新、手動での設定変更が不要に

手書きの rules の問題点

rules に DOMAIN-SUFFIX や IP-CIDR を直接書くのは問題ありませんが、ルール数が数百〜数千件に増える（例えば「国内サイトは直結、海外サイトはプロキシ」を細かく区別したい場合）と、2つの問題が生じます。設定ファイルが肥大化して保守が難しくなること、そしてルール自体が継続的な更新（ドメイン追加や誤判定の修正）を必要とし、手動同期では漏れが起きやすいことです。

rule-providers が解決すること

rule-providers は大量のルールを単独のファイル（ローカルまたはリモート URL）としてホストします。メイン設定ではその名前を参照し、更新間隔を設定するだけで、クライアントが周期的に自動で再取得します。ルール内容が更新されても何もする必要はありません。

behavior フィールドがルール形式を決める

• domain：ルールセットの内容はドメインのリストで、1行に1つのドメインまたはドメインサフィックスを記載します。
• ipcidr：ルールセットの内容は IP 範囲のリストで、1行に1つの CIDR を記載します。
• classical：ルールセットの内容は完全なマッチング構文（rules フィールドと同じ書き方）が可能です。最も柔軟ですが、サイズも最大になります。

interval が取得頻度を決める

単位は秒で、86400 は24時間ごとの更新を意味します。ルールセット自体の変化はそれほど頻繁ではないため、毎日または数日おきに設定すれば十分で、短く設定しすぎるとルールセットのサーバーに不要な負荷をかけてしまいます。

よくある使い方：広告ブロック + 地域直結

典型的な組み合わせは2つのルールセットを用意することです。1つは広告やトラッキングドメインをブロックする用（マッチしたら REJECT）、もう1つは自国内のサイトや IP 範囲を識別する用（マッチしたら DIRECT）です。残りのトラフィックはすべてプロキシのポリシーグループに流すことで、2つのルールセットの維持だけで大半の振り分けニーズをカバーできます。

複数のルールセットを組み合わせて使う

実際の設定には複数のルールセットが使われることが多く、よくある順序は次のとおりです。まず広告ブロックのルールセットを最優先で判定し、続いて国内直結のルールセット、その後各プロキシポリシーグループに対応する振り分けルール、最後に MATCH で受け止めます。rules フィールドは上から順に1件ずつマッチングし、一致したら停止するため、順序が非常に重要です。「すべてプロキシへ」のルールを最初に置くと、それ以降のより細かいルールセットは一切チェックされなくなります。

この順序は「まず除外し、最後に受け止める」と理解できます。明らかにブロックすべき、または明らかに直結すべきトラフィックを先に処理し、前段のルールでカバーされなかった残りだけが最後の MATCH でデフォルトのポリシーグループに渡されます。

ルールセットの更新と移行に関する注意点

ルールセットファイルはダウンロード後、path で指定されたローカルパスにキャッシュされます。一時的にネットワークが切断されても、クライアントは前回キャッシュしたバージョンで動作を続けるため、取得失敗によってルールが全て無効になることはありません。デバイスを変更したりクライアントを再インストールした場合は、path に対応するキャッシュディレクトリも一緒に移行することを忘れないでください。そうしないと初回起動時に再度リモートダウンロードが発生し、ネットワークが不安定な場合は一時的にルールが欠落することがあります。

また、各ルールセットの behavior はその内容の形式と一致していなければなりません。domain と宣言しながら classical 形式の内容を提供すると解析エラーになります。クライアントは通常ログに明確なエラーを表示するので、修正後に再起動するか、次の interval を待てば反映されます。

まとめ

rule-providers は「ルールの内容」と「ルールの参照」を分離します。内容は独立して更新・保守でき、メインの設定ファイルには参照関係だけが残るため、長期的には数百行の rules リストよりはるかにすっきりし、複数のデバイスで同じルールセットを共有しやすくなります。