Clash カスタムルールの書き方:マッチ順序・優先度・MATCH フォールバック解説

ルールが振り分けを決める仕組み

Clash 内核は接続を受け取るたびに、宛先アドレス・ポート・送信元情報を取り出し、それらを設定ファイル内の rules リストと順番に比較します。最初にヒットしたルールがその接続の行き先を決定します。特定のプロキシノード、あるいはポリシーグループ、内蔵の DIRECT 直結、REJECT 拒否のいずれかです。判定はヒットした瞬間に確定し、以降のルールは一切参照されません。

つまり rules リストこそが Clash の振り分けにおける唯一の判断基準です。設定がサブスクリプションリンク由来であれ、クライアントの上書き機能由来であれ、手動編集であれ、最終的には1行ずつ並んだこのルール列に集約されます。実際にはルールタイプの選択ミスはそれほど多くなく、振り分け結果が想定と異なる原因はほぼ順序にあります。より広範囲にマッチするルールが前に置かれていると、本来後方の精密なルールが処理すべきトラフィックを先に奪ってしまうのです。ルールタイプを丸暗記するより、マッチ順序を正しく理解することのほうが重要です。

システムプロキシ、TUN モード、混合ポートのいずれから流入したトラフィックでも、比較対象は同じ rules リストであり、順序の仕組みは完全に共通です。

ルール1行分の構文構造

1つのルールはカンマで区切られた複数のセグメントから成り、完全形は4段構成ですが、大半のタイプは前半3段のみを使います。

タイプ,ペイロード,ポリシー[,追加パラメータ]

• タイプ:どの観点でマッチさせるかを指定します。例:DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP。
• ペイロード:マッチさせる具体的な内容です。ドメイン名、サフィックス、IP セグメント、国コードなど。
• ポリシー:ヒットした際の振り先です。内蔵ポリシーの DIRECT や REJECT のほか、proxies や proxy-groups で定義したノード名・ポリシーグループ名を指定できます。
• 追加パラメータ:現時点では no-resolve のみで、IP 系ルール専用です。詳細は後述します。

記述上の絶対ルールは4つです。1つ目、ルールは設定ファイルの rules セクション内にまとめ、YAML 形式ではハイフンで各行を始めます。2つ目、ポリシー名は設定内の定義と大文字小文字・空白を含めて完全一致させる必要があり、誤記があると設定全体の読み込みに失敗します。3つ目、ドメインのペイロードは小文字表記が原則で、プロトコル部分やパスを含めてはいけません。http:// を付けた書き方は絶対にマッチしません。4つ目、井桁(#)で始まる行はコメントであり、内核は解析しません。

rules:
  - DOMAIN,update.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,tracker,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

よく使うルールタイプ一覧

下表はカスタムルールで頻出するタイプをまとめたものです。GEOSITE や PROCESS-NAME などは mihomo 内核限定で、オリジナルの Clash Premium では非対応です。混在させると設定が読み込めなくなります。

大量のリストは rules に1行ずつ書くべきではありません。数万行に及ぶ広告ドメインやサイト分類リストは rule-providers に管理を任せ、rules 側では RULE-SET,リスト名,ポリシー という1行だけで参照します。内核が interval 周期で自動更新してくれるため、件数が増えてもマッチ位置は1つのままで、読み込みも保守も格段に楽になります。

マッチ順序:上から順に、ヒットしたら停止

内核は各接続を処理する際、rules リストの1行目から順に下へ比較していき、最初にヒットしたルールが即座に適用され、比較はそこで終了します。この仕組みから直接導かれる結論は3つです。

1. 精密なルールは範囲の広いルールより前に置く必要があります。update.example.com だけ直結にし、example.com のその他のサブドメインはプロキシ経由にしたい場合、DOMAIN の行を DOMAIN-SUFFIX の行より上に書きます。順序が逆だと、サフィックスの行が先にトラフィックを奪ってしまい、精密な行には出番が回ってきません。
2. 後に書いたルールが先に書いたルールを上書きすることはありません。Clash には後発優先のような上書きロジックはなく、先にヒットしたものが有効になります。優先度を変える唯一の方法は行の順序を入れ替えることです。
3. カスタムルールとサブスクリプションルールの優先関係は、最終的な有効リストにおける両者の位置関係で決まります。多くのグラフィカルクライアントの上書き機能はカスタムルールをサブスクリプションルールより前に挿入し、優先的にヒットさせます。逆にクライアントがカスタム行をサブスクリプションルールの後に追加する仕様で、サブスクリプション側に既に範囲の広い行が存在する場合、カスタム行には永久に出番が来ないこともあります。

ルールを書いたのに効かないときは、まずクライアントが表示する最終的な rules リストを開き、その項目が実際に何行目にあるかを確認しましょう。構文を何度も見直す前に、まずここをチェックするのが近道です。

IP 系ルールと no-resolve パラメータ

ドメイン系ルールは接続が持つドメイン名をそのまま比較しますが、IP-CIDR と GEOIP は比較に IP アドレスが必要です。宛先がドメイン名の場合、内核はまず DNS 解決を行い、その結果を得てから判定を続けます。つまりリスト内に IP 系ルールが存在すると、前段のドメインルールで捕捉されなかった接続はすべて追加の解決処理を挟む可能性があり、遅延の増加とDNSクエリの露出拡大という2つの副作用があります。

no-resolve はこの挙動を無効化するためのものです。no-resolve を付けた IP ルールは、宛先そのものが IP リテラルである場合にのみマッチに使われ、内核はこのルールのためにドメイン名を解決しに行きません。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT,no-resolve

プライベートネットワークのセグメントやLAN機器のような純粋なIPシナリオでは、常に no-resolve を付けることを推奨します。逆に、まず解決してから所属国・地域で振り分ける GEOIP ルールにはこのパラメータを付けてはいけません。付けてしまうと、ドメイン名で発信された接続はそのルールを素通りしてしまい、後続の行に流れてしまいます。

MATCH フォールバックルール

MATCH はペイロードを持たない唯一のルールタイプで、書式は MATCH,ポリシー の2段のみです。前段のルールにヒットしなかった接続すべてにマッチします。使用上のルールは3つ。必ず rules リストの最終行に置くこと、1つの設定に MATCH は1行だけであること、内核のデフォルト挙動に依存せず常に明示的に書くことです。

MATCH を中間に書いてしまうと、残りのトラフィックをすべて奪ってしまい、それ以降のルールはすべて無効な死んだ行になります。これはカスタムルールの中で最も頻発し、かつ気づきにくいミスです。mihomo はヒットしなかったトラフィックをデフォルトで直結扱いにしますが、MATCH を明示的に書いておくことで最終的な振り先が確定・可読になり、後から設定を見直すときに内核の挙動を推測する必要がなくなります。

よく使われる2つの方針があります。MATCH,Proxy は、特別な指定のないトラフィックをすべてプロキシ経由にする書き方で、前段の直結例外と組み合わせるブラックリスト方式です。MATCH,DIRECT は、リストで明示的に許可したトラフィックだけをプロキシ経由にし、それ以外はすべて直結にするホワイトリスト方式で、プロキシが必要なサイトが少数だけの場合に適しています。

完全な設定例とマッチ確認

これまでのポイントをまとめると、典型的なカスタム rules セクションは次のようになります。

rules:
  # ローカル・LAN:.lan サフィックスとプライベートセグメントは直結
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  # 広告・トラッキング:キーワードにヒットしたら即拒否
  - DOMAIN-KEYWORD,tracker,REJECT
  # 個別例外:更新サーバーは直結
  - DOMAIN,update.example.com,DIRECT
  # example.com のその他のサブドメインはプロキシ経由
  - DOMAIN-SUFFIX,example.com,Proxy
  # 中国本土のアドレスは所属国・地域判定で直結
  - GEOIP,CN,DIRECT
  # フォールバック:残りのトラフィックはプロキシ経由
  - MATCH,Proxy

この例の GEOIP 行には no-resolve が付いていないことに注意してください。ドメイン名で発信され、前段の行に捕捉されなかった接続は、ここで一度DNS解決が行われてから所属国・地域が判定されます。この解決処理を完全に避けたい場合は、GEOSITE のカテゴリリストに切り替えてドメインの段階で振り分けを完了させ、GEOIP は no-resolve 付きで純粋なIP接続専用に使うとよいでしょう。

ルールが想定通り機能しているかどうかは、推測に頼る必要はありません。Clash Verge Rev の接続ページのようなグラフィカルクライアントの接続パネルや、各種 Dashboard の Connections 画面では、各接続がヒットした具体的なルールとポリシーがリアルタイムで表示されます。コマンドライン環境ではログレベルを info に設定すれば、内核がヒット記録を1行ずつ出力します。結果が想定と異なる場合は、パネルに表示されたルール名を手がかりにリストの行順を確認すれば、問題はたいてい即座に判明します。