ルールエンジンは「上から順」の一本勝負

Clash 系クライアント（Mihomo／Clash.Meta ファミリーを含む）の rules 節は、リストの先頭から順に評価され、最初にマッチした一行だけが採用されます。「より詳細なルールが自動的に優先される」わけではないため、並べ順そのものが設計の中核になります。ここを誤ると、DOMAIN で直行させたつもりが下の広い GEOIP 行に先に吸われる、RULE-SET の巨大な集合より前に無意味な MATCH が来てしまう、といった挙動になります。

本文では検索されやすい記法——DOMAIN 系、GEOIP、RULE-SET——に絞りつつ、実務で必ず踏むポリシー名の整合、ログでの当たり判定、rule-providers との組み合わせまでを日本語で整理します。クライアントのバージョンやコアにより利用できる語法や既定のGeoIPデータソースは差異がありますが、考え方は共通です。

用語メモ：ルール右側に書く DIRECT、REJECT、REJECT-DROP などはビルトインの振り分け先、それ以外のトークンは多くの場合 proxy-groups に宣言したグループ名と一致させます。名前が一文字でも違うと設定読み込み時にエラーか、意図しないフォールバックになります。

DOMAIN 系：ホスト名ベースで「ピンポイント指定」する

ドメイン系ルールは、HTTP／HTTPS のホスト名（TLS の SNI や HTTP の Host を分解した文字列）に対してマッチします。IP まで落ちた後の判定には基本的に効かないため、「名前では国内CDNだが実体IPは海外」といったケースでは GEOIP や IP-CIDR と組み合わせる必要があります。

DOMAIN

DOMAIN は完全一致です。www.example.com にだけ当てたいときに使います。サブドメインをまとめて拾いたい場合は下記の SUFFIX の方が保守しやすいです。

DOMAIN-SUFFIX

DOMAIN-SUFFIX,example.com,policy は www.example.com も a.b.example.com も、ゾーン example.com にぶら下がるホストにマッチします。サブスク型のリストで最も多いのがこの形です。PUBLIC SUFFIX（例：co.jp）を短く書きすぎると範囲が広がりすぎるので、ビジネスドメインの階層を実際の証明書と照合して選んでください。

DOMAIN-KEYWORD

ホスト名に部分文字列が含まれるかを見ます。安易に短いキーワードを入れると意図しないサイトにヒットするため、メンテナンスコストが高くなりがちです。どうしてもホワイトリスト／ブラックリストに使う場合は、ログで誤爆を定期的に棚卸しする前提にします。

DOMAIN-REGEX（コア依存）

正規表現でのマッチを許す実装があります。強力な一方パフォーマンスと可読性を落としやすいので、RULE-SET や DOMAIN-SUFFIX で足りるならそちらを推します。

# Domain rule examples (policy names must exist in your config)
DOMAIN,www.example.org,DIRECT
DOMAIN-SUFFIX,googlevideo.com,PROXY
DOMAIN-KEYWORD,youtube,PROXY

IP-CIDR と SRC-IP-CIDR：名前が解けた「あと」に効く

TCP 接続が確立する段階では宛先 IP が既に分かっていることが多く、その時点では IP-CIDR 系が有効です。VPN 内からの戻りや、特定データセンターブロックだけ別ポリシーに送りたいときに便利です。SRC-IP-CIDR は送信元（LAN 側の端末）を見る用途で、ゲストWi-Fiだけ別扱い、といった分割に使われます。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

no-resolve を付けると、その行の評価で余計な DNS ルックアップを避けられ、ループや遅延を抑えられることがあります。ドメインルールと IP ルールを混在させるときのオーケストレーションは、公式ドキュメントの推奨パターンに沿ってテストします。

GEOIP：国コードで大まかに塗り分ける

GEOIP,CC,policy は、宛先IPを国コード（例：日本なら JP、中国なら CN）のバケツに分類してマッチさせます。典型的には「自国は DIRECT、それ以外は PROXY」の二段構成の最後のほうに置かれ、残りの海外トラフィックをまとめて迂回します。

GEOIP に頼りすぎると次の問題が出やすいです。第一に、CDN のエッジが海外にあるとホスト名は国内でも IP 判定は海外、となり想定と逆振りになること。第二に、データベース更新頻度と実ネットワークのズレ。第三に、企業向きグローバルIPは登録国と利用国が一致しない例があること。対策としては、(1) よく使うサービスは DOMAIN か RULE-SET で先に固定、(2) 社内システムは IP 帯で明示、(3) 問題が出たらログで実IPとルールヒットを突き合わせる、の三段です。

GEOIP,JP,DIRECT
GEOIP,CN,DIRECT

（利用する国コードと並び順は自宅／出張／マルチISP環境ごとに調整してください。）

RULE-SET と rule-providers：巨大リストを「差し込みモジュール」にする

サードパーティ製の広告ブロックや「中国国内サイト直行」など、数千〜数十万行に及ぶ集合を毎回 rules: に直書きするのは現実的ではありません。RULE-SET は、あらかじめファイルまたは HTTP で配布された集合を、ローカルキャッシュとして読み込み、通常のルールと同じ先頭一致優先の列に参加させます。

宣言側は多くの場合 rule-providers ブロックで type: http または file、path、更新間隔、そして behavior（domain／ipcidr／classical など）を指定します。behavior は元ファイルのフォーマットと合っていないとヒット率が壊れるため、公開元の README を必ず読みます。

# rule-providers example (adjust to your client / core version)
rule-providers:
  remote-domains:
    type: http
    url: "https://example.com/rules/domains.txt"
    path: ./ruleset/remote-domains.yaml
    interval: 86400
    behavior: domain

rules:
  - RULE-SET,remote-domains,PROXY

クラシック YAML 形式の RULE-SET をそのまま束ねる場合と、SR 風に最適化されたバイナリ／圧縮形式を扱う場合があり、クライアントのバージョンによってはメニューから「ルールセット更新」相当の操作が必要です。更新失敗時は TLS インターセプト、証明書ピン失敗、プロキシ循環で配布URL自体が取得できないパターンが多いので、まず ブラウザ直叩きと ログの HTTP ステータスを確認します。

並べ順の実務テンプレと MATCH の落とし所

実運用で安定しやすい並びは次のような階層化です。(1) ループやローカル系の IP-CIDR で早期に DIRECT、(2) 例外ドメインを DOMAIN／狭い DOMAIN-SUFFIX で指定、(3) コミュニティ RULE-SET で業務ドメイン集合を注入、(4) GEOIP で地域の大分類、(5) 最後に MATCH,PROXY または MATCH,DIRECT でフォールバック。これをベースに、自分のプロバイダと勤務先の制約だけ上に足していくと迷いが減ります。

MATCH は「それまで何にも当たらなかった行」への最終行です。必ず存在させるのが無難です。省略できる実装もありますが、想定外の既定ポリシーに依存してトラブルシュートが難しくなります。

検証のコツ：ログで [RULE] 相当の行を拾い、どのキーでヒットしたかを追跡します。GUI によっては接続ごとにルール名をポップアップ表示できます。設定をいじった直後は DNS キャッシュや OS の接続プールが古い結果を抱えていることがあるため、ブラウザとクライアントの両方を一度閉じてから再計測してください。

PROCESS-NAME など：補助ルールをどう使うか

OS によってはプロセス名や送信元ポートで振り分けられる拡張ルールがあります。ゲームクライアントだけ DIRECT、開発用CLIだけ社内プロキシ、といった局所最適化に向きます。反面、プロセス名はアップデートで変わるため、長期的には DOMAIN／IP の方が壊れにくいです。併用するときは「プロセス例外を上、安定したドメイン规则を中、GEOIP を下」にするとデバッグしやすいです。

よくある誤解と対処

「ルールを大量に書けば精度が上がる」

ヒットするのは常に一行だけなので、リストが長いこと自体はメリットではなく、むしろ評価コストとレビュー負荷が増えます。DOMAIN-KEYWORD の乱発や重複する RULE-SET の二重取り込みは避け、ログで実際に効いている行だけを残すメンテナンスが重要です。

TUN をオンにしたらルールが変わったように見える

トラフィックの取り込みポイントが変わるため、同じ YAML でもヒット順や DNS の扱いが変化することがあります。切り替え実験では、モードごとにログを別ログファイルへ分けるなどして比較してください。

ルールDSLが読めると、他ツールとの差はどこに出るか

単純な「全体を一枚プロキシ」型アプリは初期設定は楽ですが、細かな例外——社内ポータル直行、動画だけ低遅延ノード、広告フィルタとの併用——をバージョン管理可能なテキストで追跡しづらい場合があります。更新が停止したクローズド派生だと、新しい RULE-SET 形式や Mihomo 固有のbehaviorに追随できず、設定例がそのままでは動かないことも増えます。

Clash メタスタックは、ポリシーグループとルールDSL、rule-providers が一体で設計されており、同じパターンを端末間でコピーしやすいのが強みです。頻繁に触るなら、GUI のトグルより config.yaml の diff を残せる運用の方が再現性が高くなります。パッケージの取得元を整理しつつ、ルール設計を磨きたい方は 公式のダウンロードページ から現行クライアントを揃え、本記事の順序立てをテンプレートにしてみてください。

公式経路から Clash を入手し、ルールベース運用を始める →