Rule Provider実践：数百行のルールを手書きするのをやめよう
「よく使うサイトは直接接続、よくある広告ドメインはブロック、ストリーミングは特定のノードを経由」——これはほぼ誰にでも必要なルールですが、手書きするなら数百行の DOMAIN-SUFFIX が必要になり、その上メンテナンスも自分でやらなければなりません。Rule Providerはまさにこの問題を解決するために生まれました。
Rule Providerが解決する課題
ルールは本質的に「ドメイン/IPからアクションへ」のマッピング表であり、コミュニティではよくあるカテゴリ（広告ドメイン、よく使うサイト、各種ストリーミングサービスなど）を、公開・継続更新されるルールファイルとしてすでに整理しています。
rule-providers を使うとClashはリモートURLから直接このルールファイルをダウンロードし、設定した周期で自動的に更新します。設定ファイルでは一度参照するだけでよく、何百・何千というルールを自分で管理する必要はありません。
手書きのルールと比べたRule Providerの最大の利点は「手間が省ける」ことではなく「継続的なメンテナンス」です——ドメインは変化し、広告ドメインのリストも常に更新が必要ですが、それはルールセットのメンテナンス担当者が行っており、あなたは周期に合わせて同期するだけで済みます。
3種類のルールセットタイプ
| タイプ (behavior) | 内容フォーマット | 典型的な用途 |
|---|---|---|
domain | 1行1ドメイン、ワイルドカード対応 | ドメイン単位で分類（広告ドメイン、指定サイトなど） |
ipcidr | 1行1IPレンジ（CIDR） | IPレンジ単位で分類（特定地域や特定データセンターのIP範囲など） |
classical | 1行1標準Clashルール構文 | 混合タイプ。1つのファイルに DOMAIN、IP-CIDR など複数種のルールを同時に記述できる |
さらにファイル形式を決める format フィールドもあり、一般的なのは yaml と、より軽量で解析が速い mrs（mihomo独自のルールセットバイナリ形式）です。
実際の設定例
rule-providers:
reject:
type: http
behavior: domain
url: "https://example.com/rules/reject.txt"
path: ./ruleset/reject.yaml
interval: 86400
direct:
type: http
behavior: classical
url: "https://example.com/rules/direct.txt"
path: ./ruleset/direct.yaml
interval: 86400
rules:
- RULE-SET,reject,REJECT
- RULE-SET,direct,DIRECT
- MATCH,PROXY重要なフィールドをいくつか：
interval：ルールセットの自動更新周期（秒）。内容は時間とともに変化するため、1日程度（86400）で十分な場合が多く、頻繁に更新する必要はありません。path：ローカルキャッシュのパスです。ダウンロード後のルールセットはまずローカルに保存され、クライアントを再起動しても再ダウンロードは不要です。RULE-SET,名前,アクション：rulesの中で名前を指定してあるルールセットを参照します。アクションはDIRECT、REJECT、あるいは代理グループ名を指定できます。
rules は上から下へ評価され、最初にマッチした時点で処理が止まるため、ルールセットを参照する順序も重要です——一般的には優先度の高い完全一致ルール（自分で追加した例外など）を先頭に、ルールセットを中間に、兜底となる MATCH を最後に配置します。
ルールセットはどこから入手するか
ルールセットは自分で書く必要はありません。コミュニティには既に、よく使うサイトへの直接接続、広告ブロック、人気ストリーミングプラットフォーム、よく使われるAIサービスなどのカテゴリをカバーする、長期メンテナンスされ整理された公開プロジェクトが多数存在し、設定ファイルを組む際の「標準的な依存関係」といえる存在になっています。ルールセットの提供元を選ぶ際は、次の2点を重視してください：
- 更新が活発かどうか：ドメインやIPレンジは常に変化しているため、数ヶ月更新されていないルールセットは徐々に精度が落ちていきます。リポジトリの直近のコミット履歴で判断できます。
- 分類が十分に細かいか：ルールセットによっては「よく使うサイトの直接接続」と「広告ブロック」を分けて管理しているものもあり、必要な分だけ参照できて、巨大で何でも入った1つのファイルを丸ごとダウンロードする必要がなくなります。
ルールセットごとに分類基準が完全に同じとは限りません。複数のソースを混ぜて使う前に、まず数日間小規模でテストし、明らかな誤判定や漏れがないか確認してから、長期的に使うかどうか決めるのがおすすめです。
自動更新と手動での強制リフレッシュ
interval はClashコアがバックグラウンドで動作している間に定期的に更新を確認する周期を制御しますが、設定を変更してクライアントを再起動した直後に強制的にリフレッシュするわけではありません——ローカルに既にルールセットファイル（path が指すファイル）がキャッシュされている場合、コアはデフォルトでまずローカルキャッシュを使い、interval の周期が来たときに再ダウンロードします。
これは次の2つの場面で特に注意が必要です：
- ルールセットのURLをAからBに変更したばかりだが
pathをそれに合わせて変更していない場合、コアは古いファイルに対応するキャッシュパスをまだ使っている可能性があり、「設定を変えたのに反映されていない」ように見えることがあります。 - ルールセットのメンテナンス担当者が明らかな誤ブロックの問題を修正したばかりで、すぐに最新版を使いたい場合は、
pathが指すローカルキャッシュファイルを直接削除し、クライアントを再起動して強制的に再ダウンロードをトリガーできます。
Dashboardパネルを備えたクライアントの多くは「ルールを更新」ボタンも用意しており、これは手動でキャッシュを削除して再起動するのと同等の効果があり、日常使いにより便利です。
ルールセット vs 手書きルール：パフォーマンスはどうか
「数万件のルールをダウンロードするとマッチング速度が落ちるのでは」と心配する人もいますが、実際にはコアがルールセットを読み込む際に前処理を行います（例えばドメインルールをプレフィックスツリー構造に整理するなど）。そのため単一ルールのマッチングコストはルール数に比例して増えることはなく、数千件から数万件のルールでも現代のデバイスでは知覚できるほどの遅延差はほとんどありません。
実際に体感速度に影響するのはルールの並び順のほうです——マッチ率の高いルールほど上に置くことで、平均マッチング回数が少なくなります。だからこそ、よく使う直接接続ルールセットは先頭付近に置くべきで、何も考えずにルール一覧の末尾に置くべきではないのです。
実践上のアドバイス
- 異なるソースのルールセットを同時に重ねすぎないようにしましょう。同じドメインが複数のルールセットで異なる判定を受け、動作が一貫しなくなることがあります。1つのニーズに対して活発にメンテナンスされているルールセットを1つ選べば十分です。
- ルールセットで問題が起きた場合（例えば正常なサイトが誤ってブロックされた場合）、まず自分の設定を疑う前に、ルールセット自体の問題かどうかを確認してください——特定の
RULE-SET行を一時的にコメントアウトして調査できます。 - ストリーミング解除系のルールセットは最も頻繁に更新されます（プラットフォームがIPレンジやドメインを常に変更するため）。
intervalは少し短めに設定するのが合理的です。例えば43200（12時間）など。 - 参照しているルールセットの一覧を定期的に見直し、不要になったカテゴリは削除しましょう。設定ファイルがシンプルであればあるほど、問題が起きたときの原因特定が容易になります。
より詳しいルール構文と優先順位については、応用設定ガイドのルールエンジンの章をご覧ください。