Rule Provider実践ガイド：ルールセットを自動更新し、手動管理から解放される

なぜRule Providerを使うべきか

数百件のDOMAIN-SUFFIXをrulesリストにそのまま並べても動作はしますが、メンテナンスコストは高くなります。ルールセットの作者が内容を更新すれば、それに合わせて手動で同期する必要があり、ルール数が増えると設定ファイル自体も読みづらくなります。Rule Providerはこの部分を独立したリモートファイルに切り出し、クライアントが設定した周期で自動的に再取得します。ルールセット本体のメンテナンスは配信元に任せられ、こちら側はrulesでその名前を参照するだけで済みます。

3種類のbehavior、選び方を間違えないように

Rule Providerを定義するときに最も間違いやすいのがbehaviorフィールドです。これはクライアントにこのルールセットの内容をどう解釈すべきかを伝えるものです。

• domain —— ルールセットの内容が純粋なドメインリスト（1行に1ドメイン、DOMAIN-SUFFIXと同じ意味）；
• ipcidr —— ルールセットの内容がIP範囲のリスト（1行に1つのCIDR、IP-CIDRと同じ意味）；
• classical —— ルールセットの内容が完全なルール（1行ごとにルールタイプを含み、rulesに手書きするものと同じ書式。最も柔軟だがファイルサイズも最大になる）。

設定例（全体）

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.txt
    interval: 86400

  local-ip:
    type: http
    behavior: ipcidr
    url: "https://example.com/rules/local-ip.txt"
    path: ./rules/local-ip.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,local-ip,DIRECT
  - MATCH,PROXY

pathはルールセットのローカルキャッシュの保存先で、初回取得時にこのファイルに書き込まれ、以降はinterval（単位は秒）に従って自動的に再ダウンロードし上書きされます。一時的に通信が切れても、クライアントはまずローカルにキャッシュされた古いバージョンを使い続けられるため、1回の更新失敗だけでルールを丸ごと失うことはありません。

複数のルールセットがある場合の並び順

Rule Providerに切り替えても、ルールが上から順に照合され一致した時点で処理が止まる、という基本原則は変わりません。実践上、比較的安定した順序はこうなります。

• まず広告・悪質ドメインをブロックするルールセット（rejectなど）を置き、不要なリクエストを早めに遮断する；
• 次に明確にプロキシが必要なルールセット（よく使われる海外サービスのドメインリストなど）を置く；
• 続いて国内・地域内向けの直接接続ルールセット（ドメインとIP範囲）を置く；
• 最後にMATCHで受け止める。多くの場合プロキシ経由にしておくと、新しく登場したサービスがどのルールにも一致せずに接続失敗する事態を避けられます。

更新頻度はどう決めるか

ルールセットはノードの速度測定のように頻繁に更新する必要はなく、多くの場面ではintervalを12〜24時間（43200〜86400秒）程度に設定すれば十分です。更新頻度を上げすぎてもルールセットのサーバーへの負荷が増えるだけで、実質的なメリットはありません。自分で管理している非公開のルールセットで、変更頻度がかなり低いのであれば、2〜3日程度まで延ばしても問題ありません。

よくある問題の調査方法

Rule Providerを導入した後、「設定したはずなのに効いていない」と感じたら、次の方向で一つずつ確認してみてください。

• ルールセットの取得失敗 —— urlをブラウザで直接開けるか確認してください。ルールセットの中には特定のホスティング先に置かれているものがあり、一部の通信環境ではそのアクセス自体にプロキシが必要になる「鶏と卵」のような状況が起こり得ます。この場合はより近いミラーサーバーが用意されているルールセットに切り替えることをおすすめします；
• behaviorと内容の不一致 —— 前述の通り、これが最もよくある失敗原因です。classical形式のファイルをdomainだと宣言してしまうと、クライアントは純粋なドメイン形式として解析しようとし、余分なルールタイプの接頭辞がドメインの一部として誤認されて、ルールセット全体が機能しなくなります；
• ローカルキャッシュが古い —— かなり前にキャッシュされたバージョンを使っている疑いがあるなら、pathが指すローカルファイルを直接削除すれば、次回起動時にクライアントが改めて完全な取得を行います；
• 新しいルールセットで順序が崩れた —— ルールセットを新たに追加したら、挿入位置が「具体的なルールを先に、受け止め用のルールを後に」という原則に沿っているか確認してください。挿入位置を誤ると、それまで正常に機能していた後続のルールが一致しなくなることがあります。

「ルールが効かない」という問題のほとんどは、この4つのいずれかに行き着きます。順番に確認していけば大抵は早く特定できます。ルール構文の全種類を体系的に把握したい方は、上級者向けドキュメントの完全なリファレンス表をご覧ください。