Clash Rule Providers 上級：サードパーティで精密分流

Rule Provider が解決する課題

Clash 系クライアント（特に Mihomo／Clash Meta）では、トラフィックをどのプロキシグループへ送るかを rules で決めます。ドメインや IP のリストが増えるほど、単一の設定ファイルは読みづらくなり、差分管理も難しくなります。Rule Provider（設定上は rule-providers ブロック）は、ルール本体を外部のルールセットとして切り出し、必要に応じて自動更新できる仕組みです。

ここでいう「サードパーティ」とは、自分以外がメンテナンスしているルールリストや変換済みルールセットを指します。利用にあたっては、配布元のライセンスと利用規約、ならびに職場・契約先・地域の法令とポリシーを順守してください。本稿は正当な用途での設計と運用に焦点を当てます。

コアの世代や用語の整理は Mihomo アップグレードガイド、ルール肥大化が体感速度に与える影響は高速化まわりの記事とあわせて読むとつながりが掴みやすいです。

RULE-SET と rule-providers の関係

設定ファイル内の rules に RULE-SET 行を書くと、その行は「指定したプロバイダが提供するルール集合」をまとめて参照します。プロバイダは rule-providers で名前付き定義し、取得元は HTTP(S) の URL やローカルパスにできます。精密分流とは、単に「全部プロキシ」ではなく、例えば国内 CDN や決済、社内ドメインは DIRECT、特定カテゴリだけ別グループ、残りは自動選択、といった意図どおりの優先順位をルールの並びで表現することを指します。

Mihomo では、ルールセットの形式として従来のテキスト系に加え、軽量なバイナリ形式（実運用でよく使われる配布物があります）にも対応する場合があります。GUI によっては「ルールセット URL を貼る」操作に抽象化されているため、裏側が rule-providers に落ちているだけ、ということも多いです。

rule-providers の基本形

典型的には、プロバイダごとに type・behavior・取得元（url または path）・interval（秒）を指定します。behavior はルールセットの解釈方法に関わるため、取り込むファイルの種類と一致させる必要があります。古典的な複数行ルールを束ねる場合は classical、ドメインリスト型は domain、CIDR 型は ipcidr といった対応が基本線です（利用するコアのバージョンとドキュメントに合わせてください）。

下記は構造理解用の最小例です。URL は架空のプレースホルダに置き換えてください。

rule-providers:
  my-rules:
    type: http
    behavior: classical
    url: "https://example.com/rules/example.yaml"
    path: ./rules/my-rules.yaml
    interval: 86400

rules:
  - RULE-SET,my-rules,PROXY

rules 側の RULE-SET,名前,ポリシーまたはグループ名 の第 3 引数は、プロバイダ内のルールがマッチしたときに適用される宛先です。ここを DIRECT にすればその集合は直結、別の select グループ名にすれば GUI から選べるチャネルに流せます。

精密分流の要は「評価順」

Clash のルールは上から順に評価され、最初にヒットした行で確定します。したがって、サードパーティの巨大な RULE-SET を先頭に置くと、そこで吸い尽くされてしまい、自分用の細かい例外が永遠に評価されない、という事故が起きがちです。現実的なパターンは次のとおりです。

（1）LAN やローカル、確実に直結させたいドメインを最優先で書く。（2）続いて、信頼できる小さめの自作リストや職域向けの固定ルール。（3）その後に、メンテのしやすいサードパーティのカテゴリ別 RULE-SET を、用途に応じたグループへ振り分ける。（4）最後に GEOIP や MATCH で全体のデフォルトを決める。

この「段階的にフォールバックしていく」イメージを頭に置くと、GUI のルールエディタで行をドラッグしたときの意味も説明しやすくなります。分流が粗く感じるときは、まずどの行で早期にマッチしてしまっているかを疑うのが近道です。

behavior とデータ形式を取り違えない

同じ「ルールセット」でも、中身がドメイン一行ずつなのか、古典ルールなのかで最適な behavior が変わります。取り違えると、期待どおりにヒットしない、あるいは読み込み時にエラーになることがあります。配布ページに「Mihomo 用」「classical」「domain」などの表示がある場合は、その指示に従うのが安全です。

また、プロキシグループ名は proxies 定義と完全一致している必要があります。サブスク由来の名前と衝突しないよう、グループ名は英数字で統一するなどの命名規則を決めておくと、RULE-SET を増やしても破綻しにくいです。

更新間隔とオフライン運用

interval を極端に短くすると、起動直後や定期更新のたびにダウンロードとパースが走り、モバイル回線や低スペック端末では体感に出ることがあります。更新が追いつけばよいなら 12〜24 時間程度から試し、問題があれば手動更新に寄せる運用も現実的です。ローカル path だけを参照する構成にすれば、外部依存は減りますが、リストの鮮度は自分で管理する必要があります。

信頼できるミラーや自前ホストにルールセットを置く場合でも、HTTPS の証明書検証を無効化するような設定は推奨されません。中間者攻撃のリスクが増え、ルールが差し替えられたときの影響はプロキシ全体に及びます。

サードパーティソースを選ぶときの観点

ルールセットは「接続先を決める指令」そのものです。入手元が改ざんされれば、機密ドメインを意図しない経路に流す、マルウェアドメインを直結させる、などのリスクが説明上は成立します。公開リポジトリやコミュニティ配布を使う場合は、（1）更新履歴やメンテ状況、（2）ライセンス、（3）自分の環境で本当に必要なカテゴリだけに絞れるか、を確認してください。

「とにかく有名なセットを全部足す」は、分流は細かく見えても、実際には重複マッチや順序の非効率でパフォーマンスを落としがちです。技術ブログの他記事でも触れているとおり、ルールは薄く保つほど扱いやすく、トラブル時の切り分けも速くなります。

うまく分流しないときのチェックリスト

まず、該当ドメインが想定の RULE-SET に含まれているか、別の上位ルールで既に決まっていないかを確認します。次に、コアのログレベルを上げ、どのルールにマッチしたかを追えるようにします（クライアントによって UI から確認できる場合もあります）。DNS モードが fake-ip のときは、ルールがドメイン基準か IP 基準かで見え方が変わるため、DNS まわりの整理とセットで見直すとよいです。

サードパーティセットを更新した直後だけ挙動が変わる場合は、キャッシュされた古いファイルと新ファイルの読み込みタイミングを疑い、一度アプリを再起動するか、ルールファイルのパスを確認してください。

覚えておきたいこと：RULE-SET は「魔法の一発解決」ではなく、プロバイダの中身と rules の順序という二つのレバーで挙動が決まります。変更は一度に一つずつ試し、ログで確認するのが安全です。

まとめ

Rule Provider を使うと、サードパーティが整備したルールセットを取り込みながらも、自前の例外を上に載せることで細かい分流を実現できます。behavior・取得元・更新間隔・評価順の四つをセットで設計することが、運用が長くなっても破綻しないコツです。

ルールと DNS、プロキシグループを同一クライアントで束ねられるのが Clash／Mihomo の強みです。GUI で購読を取り込みつつ、必要なら rule-providers を追記してチューニングする、という二段構えも現場ではよく使われます。→ Clash を無料ダウンロードし、ルール設計をじっくり試す

ソースコードや開発の話題は Mihomo の GitHub リポジトリで確認できます。インストール用パッケージの入手は、各 OS 向けの公式ダウンロードページを優先するとスムーズです。