Clash カスタムルール完全ガイド:マッチタイプ・構文・優先順位

Clash の振り分け機能は最終的に設定ファイルの rules フィールドに集約されます。1 行のルールがどのトラフィックをどのプロキシグループに送るかを決め、順序を間違えたり適切なマッチタイプを使わなかったりすると、軽ければ特定サイトの振り分けが効かなくなり、重ければプロキシグループ全体が機能不全になったり DNS 解決が異常になったりします。この記事では mihomo コア(Clash Meta)の実装に基づき、よく使うルールタイプを一つずつ取り上げて構文と使い分けを整理し、ルールが「上から下へ」どのように評価されるかを解説し、最後にそのまま使える並び順の考え方を紹介します。

ルールシステムの基本構造と評価順序

Clash 設定ファイル内の rules は配列で、1 行が 1 条のルールです。形式は統一されており次のようになります。

ルールタイプ,マッチ内容,ポリシーグループ[,追加パラメータ]

例:

rules:
  - DOMAIN-SUFFIX,github.com,🚀 ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,🚀 ノード選択

コアは 1 件の通信要求を処理する際、配列の順序通り上から下へ 1 条ずつ照合していきます。あるルールにマッチした瞬間、そこで指定されたポリシーグループが即座に適用され、以降のルールはすべてスキップされ、それ以上の照合は行われません。この「ヒットしたら停止」という仕組みは、ルールシステム全体で最も見落とされやすく、最も問題を起こしやすいポイントです。多くの人は「より詳細な条件のルールが優先される」と思い込んでいますが、実際には配列内で前に書くか後ろに書くかだけで決まります。

そのため、ルールファイルの末尾にはほぼ必ず MATCH,ポリシーグループ という受け皿ルールが置かれます。これは「上記すべてのルールにマッチしなかった場合の既定の振り先」を表し、振り分け表の最終行に相当するため、必ず配列の最後に置く必要があります。前に置いてしまうと、それ以降のルールがすべて永久に無効になります。

よく使うマッチタイプを一つずつ解説

mihomo が対応するルールタイプは多数ありますが、日常の設定で頻出するのは以下の数種類で、マッチ対象によってドメイン系・IP 系・地理位置系・プロセス系に分けられます。

ドメイン系:DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD

• DOMAIN,www.example.com,ポリシーグループ —— 完全一致で単一ドメインのみにマッチし、サブドメインはヒットしません。特定の 1 ドメインだけを個別に処理したい場合に向いています。
• DOMAIN-SUFFIX,example.com,ポリシーグループ —— そのドメインおよびすべてのサブドメイン(www.example.com、api.example.com も含む)にマッチする、日常設定で最もよく使われるタイプです。1 行のルールでドメイン体系全体をカバーできます。
• DOMAIN-KEYWORD,example,ポリシーグループ —— ドメインにこのキーワードが含まれていればヒットします。マッチ範囲が最も広いため無関係なドメインを誤ってカバーしやすく、他のサービスと名前が重複しないキーワードに限定して使うことをお勧めします。

IP・サブネット系:IP-CIDR / IP-CIDR6

IP-CIDR,192.168.1.0/24,DIRECT,no-resolve のようなルールは CIDR 表記のサブネットで宛先 IP をマッチさせ、LAN のサブネット、社内サーバー、CDN の固定 IP レンジを直接通過させたり特定回線に固定したりする際に使われます。IPv6 アドレスには IP-CIDR6 を用い、書き方は完全に同じです。この種のルールは通常ルール表の前寄りに置く必要があります。多くの LAN アクセスがドメイン系ルールや GEOIP ルールに先に捕まってしまうと、逆に一度プロキシを経由してしまうためです。

地理位置系:GEOIP

GEOIP,CN,DIRECT は GeoIP データベースを用いて宛先 IP がどの国・地域に属するかを判定します。よくある使い方は GEOIP,CN を直接接続ポリシーに対応させ、中国本土の IP をプロキシ経由にしないというものです。この種のルールはマッチ範囲が非常に広いため、当然ながらルール表全体の後ろ寄りに置きます。前に置くと、本来細かく振り分けるべき大量のトラフィックが先に「まとめて」処理されてしまいます。

プロセス系:PROCESS-NAME / PROCESS-PATH

PROCESS-NAME,com.apple.WebKit.Networking,DIRECT はリクエストを発行したプロセス名でマッチさせます。特定のクライアントに個別のポリシーを割り当てる際によく使われ、例えばあるダウンロードツールを常に直接接続させたり、あるアプリを常に特定ノード経由にしたりできます。デスクトップ環境ではプロセス系ルールの粒度が最も細かいですが、プロセス名は OS やバージョンによって異なる場合があるため、効かない場合はまず名前が正しいか確認することを優先してください。

論理結合と受け皿:AND / OR / NOT / MATCH

mihomo は論理ルールにも対応しており、複数の子条件を組み合わせて 1 条にできます。例えば:

- AND,((DOMAIN-SUFFIX,example.com),(NETWORK,tcp)),ポリシーグループ

この書き方は複数条件を同時に満たす必要がある細かなシナリオに向いています。日常設定での出現頻度は高くありませんが、構文構造を理解しておくとコミュニティ公開のルールセットを読み解く際に役立ちます。最後に、MATCH,ポリシーグループ はマッチ内容を必要としない唯一のルールタイプで、受け皿ポリシーを表します。ルール表には 1 回だけ出現すべきで、必ず最終行に置く必要があります。

no-resolve パラメータと DNS 解決のタイミング

IP-CIDR および IP-CIDR6 ルールは末尾に no-resolve パラメータを付けられます。実践で最も見落とされやすく、ルールが「効いていないように見える」原因になりやすい細部です。

デフォルトでは、ドメインベースのルール(例:DOMAIN-SUFFIX)はヒット前に IP を事前解決する必要がなく、ドメイン文字列のまま照合します。一方 IP-CIDR 系のルールは本質的に「宛先 IP」をサブネットと照合するもので、リクエスト自体がドメインである場合、コアはまずそのドメインを IP に解決し、その IP を IP-CIDR ルールと照合します。no-resolve を付けると、コアはこの解決ステップをスキップし、リクエスト自体がすでに IP(ドメインではない)である接続にのみ適用されるようになり、ルールに合わせるために追加の DNS クエリを自ら発行することはなくなります。

実際にルールを書く際の判断基準はシンプルです。そのIP-CIDR ルールが対象とするのが明確に IP 形式で現れるトラフィック(社内デバイス、IP を直接公開しているサービスなど)であれば no-resolve を付けることをお勧めします。逆に対象がドメイン経由でアクセスされ、解決結果に依存して振り先を判断する必要があるシナリオであれば、前段のドメイン系ルールに任せるほうが直接的で、わざわざ IP-CIDR に回す必要はありません。

ルール並び順の実践原則とよくある間違い

「上から下へ、ヒットしたら停止」という仕組みを理解すれば、ルールの並び順にはある程度固定した考え方があります。マッチ範囲の狭いものから広いものへ並べます。

1. まず LAN・社内ネットワークの直接接続ルールを書く。プライベート IP レンジや社内ドメインを最前列に置き、後ろのより広範なルールに先取りされて社内アクセスまでプロキシ経由になるのを防ぎます。
2. 次に特別扱いが必要な個別ドメインやアプリを書く。特定ノード経由が必要な動画配信ドメインや、中国本土でよく使う直接接続が必要なサービスドメインなどを DOMAIN-SUFFIX で正確にカバーします。
3. 続けてルールセット(rule-providers)を配置する。コミュニティが管理する分類ルールセット(広告フィルタ、主要サービス分類など)を、必要な参照順に並べます。
4. 次に地理位置系ルールを配置する。典型例は GEOIP,CN,DIRECT で、前段のルールにヒットしなかった中国本土の IP を直接通過させます。
5. 最後の 1 行は必ず MATCH の受け皿。ヒットしなかったトラフィックはすべてここに集約され、通常はノード選択やプロキシグループを指します。

よくある並び順の間違いは主に 2 種類あります。1 つは GEOIP,CN,DIRECT を前寄りに置きすぎて、本来細かくプロキシに振り分けるべきサービスが、解決された IP がたまたま中国本土のレンジにあったせいで先に直接接続されてしまうケース。もう 1 つは MATCH の受け皿ルールを誤って中間位置に置いてしまい、その後にせっかく書いた全てのルールが実質永久に実行されないケースです。デバッグ時には特定のルールの構文ミスだと誤解しやすいですが、実際は並び順の問題です。こうした問題を調査する際は、まずルール配列の順序を確認し、それから具体的な構文を確認することをお勧めします。順序が間違っていれば、構文がどれだけ正確でも機能しません。

ルールセットで大規模なルールを整理する

カスタムルールが数十から百件規模に増えると、rules 配列に直接まとめて書くのは管理が難しくなります。mihomo は rule-providers フィールドに対応しており、ルールを独立したリモートまたはローカルファイルに分割し、rules 内で RULE-SET,ルールセット名,ポリシーグループ として参照できます。

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

rules:
  - RULE-SET,my-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,🚀 ノード選択

behavior フィールドは、このルールセットの項目をドメイン・IP サブネット・分類ルールのどれとして解釈するかを決めるもので、ルールファイルの実際の内容と一致させる必要があります。interval はどのくらいの頻度で自動更新を取得するかを決めます。この方式は「分類ロジック」と「具体的なルール内容」を分離するもので、ルールセット自体の更新はメイン設定ファイル内の並び順を変更する必要がなく、すべてのルールを 1 つの設定に手書きするより保守コストが明らかに低くなります。

ルールを書いた後に行いたい 2 つの確認

ルールを書き終えたら、実運用前に次の 2 点を確認することをお勧めします。1 つ目は、ルール配列内に MATCH が 1 件だけ存在し、末尾に置かれているかどうか。これは最も見落としやすい部分です。2 つ目は、新規追加した IP-CIDR ルールについて、no-resolve が想定通り付けられているか、または省略されているかを確認すること。特に社内アクセスに関わるルールでは、付け間違いや付け忘れが一見「ランダム」に見える接続異常を引き起こします。ログ上の振り分け結果が想定と食い違う場合は、まずルール配列を順番に読み直すことが、1 行ずつ構文をチェックするより速く原因を特定する近道です。