Clash カスタムルールの書き方:マッチタイプ・構文・優先順位を解説

SEC-01

ルールの基本構造と記述位置

ClashとmihomoコアのルーティングはすべてコンフィグファイルのRules機能を基盤にしています。1つのルールは実質1行のテキストで、「マッチタイプ,マッチ内容,ターゲットポリシー」の3段構成をカンマで区切って記述します。最も一般的な例は以下の通りです。

rules:
  - DOMAIN-SUFFIX,google.com,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

1つ目はマッチタイプで、どの次元でトラフィックを判定するかを決めます。2つ目は具体的なマッチ値で、ドメインのサフィックスやIPレンジなどです。3つ目は一致した場合にどのポリシーグループ・ポリシーに渡すかを指定し、よく使われる値にはDIRECT(直接接続)、PROXY(あるポリシーグループ経由)、REJECT(ブロック)があります。一部のマッチタイプは4つ目の任意パラメータもサポートしており、例えばIP-CIDRの後のno-resolveはDNS解決をスキップして宛先IPで直接判定することを意味し、不要なドメイン解決リクエストを避けるためによく使われます。

ルールフィールドは基本的にコンフィグファイルの末尾、通常はproxy-groupsの直後に配置されます。カスタムルールとサブスクリプションから取得したルールは1つのリストに統合され、統合後の順序がそのままルーティング結果を決定します。この点は第3節で詳しく説明します。

SEC-02

よく使うマッチタイプ一覧

ドメイン系マッチ

DOMAINは完全一致するドメインのみに有効です。例えばDOMAIN,api.example.com,PROXYはこの1つのサブドメインのみをブロックし、www.example.comには影響しません。

DOMAIN-SUFFIXはドメインのサフィックスにマッチする、最もよく使われるタイプです。DOMAIN-SUFFIX,google.com,PROXYはgoogle.com、www.google.com、mail.google.comなど、このサフィックスで終わるすべてのドメインに一致し、サイト単位でポリシーを分けるのに適しています。

DOMAIN-KEYWORDはドメインに含まれるキーワードに一致し、位置を問いません。記法はDOMAIN-KEYWORD,youtube,PROXYのようになります。マッチ範囲が広いため無関係なドメインを誤って引っかけやすく、キーワードが十分に特徴的な場合のみ使うことをお勧めします。

DOMAIN-REGEXは正規表現によるドメインマッチをサポートし、規則性はあるがサフィックスやキーワードでは網羅できないドメイン群の処理に適しています。記述とデバッグのコストが高く、通常のプロジェクトでは出現頻度は低めです。

IP・ネットワークセグメント系マッチ

IP-CIDRはIPv4のネットワークセグメントでマッチし、書式はIP-CIDR,開始アドレス/マスク長,ポリシーです。ローカルネットワークのアドレス帯を通過させる際によく使われ、例えばIP-CIDR,10.0.0.0/8,DIRECT,no-resolveのように記述します。IP-CIDR6はそのIPv6版で、構文は同じです。

GEOIPは宛先IPが属する国・地域で判定します。コアにはIP地理データベースが内蔵されており、記法はGEOIP,CN,DIRECTで、接続先IPが中国本土に属する場合はすべて直接接続にすることを意味します。ネットワークセグメントを1つずつ列挙する必要がなく、手書きのIP-CIDRリストよりメンテナンスコストがはるかに低くなります。

地理・ルールセット系マッチ

GEOSITEはmihomoコアがv2rayのルールセットエコシステムに対応した機能で、ドメインが属するカテゴリで判定します。例えばGEOSITE,cn,DIRECTという1行だけで、中国本土で頻繁に使われる数百から数千のドメインをカバーでき、現在最もメンテナンスコストが低いドメイン分流方式の一つです。使用前にコンフィグファイル内で対応するrule-providersが宣言されているか確認する必要があり、そうでない場合コアは起動時にルールセットが見つからないとエラーを出します。

RULE-SETはカスタムまたはサブスクリプション提供元のルールセットファイルを参照します。書式はRULE-SET,セット名,ポリシーで、ルールセット自体はDOMAIN-SUFFIXやIP-CIDRなどの項目を多数含む独立したファイルであり、rule-providersフィールドで取得元アドレスと更新周期を宣言します。利点はルール内容をメインコンフィグファイルと独立して更新できることで、毎回ルールリストを再編集する必要がありません。

プロセス・ポート系マッチ

PROCESS-NAMEは接続を発行したローカルプロセス名でマッチし、特定のクライアントだけに個別の出口を指定するのに適しています。例えばあるダウンロードツールだけを直接接続にする場合です。DST-PORTは宛先ポートでマッチし、メールやゲームなどの一般的なポートを個別に取り出して処理するのに使われます。この2種類のルールはプラットフォーム層のプロセス識別機能に依存しており、一部のモバイル環境やサンドボックス環境では機能しない場合があるため、まずデスクトップ環境で有効性を確認してから利用することをお勧めします。

フォールバックマッチ

MATCHはワイルドカードルールで、マッチ値を持たず、必ずルールリストの最終行に置く必要があります。それまでのすべてのルールが一致しなかった場合のデフォルトの振り先を示します。ほとんどのコンフィグではMATCHのターゲットを単一ノード固定ではなくポリシーグループに設定しており、コンフィグファイルを変更せずにクライアント画面から出口をいつでも切り替えられるようにしています。

NOTE

ルールタイプの大文字小文字の区別への感度は高くありませんが、コミュニティの慣例として大文字表記が統一されています。この習慣を保つことで、チーム作業や後の検索がしやすくなります。

SEC-03

優先順位ロジック:上から順に、一致したら終了

Clashとmihomoコアはルールリストを処理する際、厳密な順序マッチングの原則に従います。rulesリストの1行目から順に現在の接続と比較し、一度どこかの行が一致すればすぐにその行で指定されたポリシーを採用し、以降の比較を停止します。後にさらに精確で適切なルールがあっても、二度とチェックされません。つまりルールの順序そのものが優先順位であり、マッチタイプがどちらが「精確」かで決まるわけではありません。

ハマりやすい例を挙げます。

rules:
  - DOMAIN-KEYWORD,google,DIRECT
  - DOMAIN-SUFFIX,google.com,PROXY
  - MATCH,PROXY

このコンフィグでは、1行目のキーワードマッチが先にgoogleという文字列を含むすべてのドメインを直接接続にしてしまうため、本来プロキシ経由になるべき2行目のDOMAIN-SUFFIX,google.com,PROXYは実行される機会を永久に得られません。接続が2行目に到達する前に、1行目でキャッチされ処理が完結してしまうためです。ルールの順序を逆に書くと、結果は期待と完全に逆になり、クライアント画面は通常このような論理的な矛盾を指摘してくれないため、利用者自身で確認する必要があります。

このメカニズムに基づき、ルールを書く際は精確なものから広範なものへという配列原則に従うことをお勧めします。まずDOMAIN、DOMAIN-SUFFIXのような精確マッチを置き、次にDOMAIN-KEYWORD、GEOSITE、GEOIPのような範囲の広いマッチを置き、最後にMATCHでフォールバックします。範囲の広いルールを前に置くと、本来後ろの精確なルールで処理されるべきトラフィックを先取りしてしまいます。

SEC-04

カスタムルールはサブスクリプションルールの前か後か

多くのユーザーのコンフィグファイルはゼロから手書きしたものではなく、サブスクリプションのノード提供者が生成した完全なコンフィグであり、その中にはすでにルールリストが含まれています。この状態で新たにカスタムルールを追加する場合、挿入位置がそのルールが本当に機能するかどうかを直接決定します。

結論:カスタムルールはサブスクリプション付属のルールリストの最も前に挿入するべきで、末尾に追加してはいけません。理由はまさに前節で述べた「一致したら終了」というメカニズムです。サブスクリプションが提供するルールリストはすでに大量の一般的なドメインやIPレンジをカバーしていることが多く、カスタムルールを末尾に追加すると、接続はほぼ確実にまずサブスクリプションのルールでマッチしてしまい、カスタムルールには永遠に順番が回ってきません。カスタムルールを最前列に置いてこそ、サブスクリプションのルールより実質的に高い優先順位を確保できます。

よく行われる方法は、ルールリストの先頭にコメントで区切りを作り、次回サブスクリプション更新時にすぐこの部分を見つけて保持できるようにすることです。

rules:
  # ↓↓↓ カスタムルール、サブスクリプション更新時は手動で保持すること ↓↓↓
  - DOMAIN-SUFFIX,internal.mycompany.com,DIRECT
  - DOMAIN-KEYWORD,ads,REJECT
  # ↑↑↑ カスタムルールここまで ↑↑↑
  - DOMAIN-SUFFIX,google.com,PROXY
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

特に注意すべき点として、クライアントがサブスクリプション自動更新を設定している場合、クライアント自体が「カスタムルールを個別に保存し、統合時に自動で前置する」といった高度な機能をサポートしていなければ、サブスクリプション更新のたびにリモートファイルでローカルコンフィグ全体が上書きされ、手動で先頭に追加したルールも一緒に消えてしまいます。Clash Verge RevやFlClashなど「コンフィグの統合」や「オーバーライド(override)」機能をサポートするクライアントを使う場合は、カスタムルールをサブスクリプションから生成されるメインコンフィグに直接書き込むのではなく、独立したオーバーライドファイルに記述することをお勧めします。これによりサブスクリプション更新時にカスタム部分が失われません。

WARN

サブスクリプションから生成されたコンフィグファイルを直接編集するのは一時的な変更に過ぎず、ほとんどのクライアントは次回のサブスクリプション取得時にこのファイルを全体的に上書きします。カスタムルールを長期的に保持したい場合は、毎回のサブスクリプション更新後に手動で追加を繰り返すのではなく、クライアントのオーバーライド、統合、ローカルルール機能を優先的に利用してください。

SEC-05

典型的なシナリオとルール組み合わせ例

以下のいくつかの組み合わせは、日常的なコンフィグでよく遭遇する要件をカバーしており、ポリシーグループ名を調整するだけで直接参考にできます。

LANと国内は直接接続、それ以外はプロキシ経由

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

このセットではまずLANとローカルホストのアドレスを除外し、内部ネットワークへのアクセスが誤ってプロキシ経路に入ってしまうことを防ぎます。次にGEOSITEで国内ドメインをカバーし、GEOIPで国内IPだがドメイン分類に収録されていないケースをフォールバックでカバーします。最後にMATCHで残りのトラフィックをすべてプロキシポリシーグループに渡します。

広告・トラッキングドメインのブロック

rules:
  - DOMAIN-KEYWORD,doubleclick,REJECT
  - DOMAIN-SUFFIX,adservice.google.com,REJECT

REJECTはマッチした接続リクエストを直接破棄し、クライアント側ではそのリソースの読み込み失敗またはタイムアウトとして表れます。この種のルールも同様に、そのドメインを許可する他のルールより前に置く必要があります。そうしないと、より広範な許可ルールに先に処理されて無効になってしまいます。

指定アプリの強制直接接続

rules:
  - PROCESS-NAME,WeChat.exe,DIRECT
  - PROCESS-NAME,com.tencent.mm,DIRECT

一部のメッセージングアプリやローカルネットワークアプリは遅延や回線の安定性への要求が高く、単独で取り出して直接接続にする方が無理にプロキシを通すよりも体感がよいことが多いです。デスクトップ環境のプロセス名は通常拡張子付きで、Androidアプリの場合はアプリのパッケージ名を記入します。

SEC-06

ルールが機能しない場合のトラブル対処

ルールを書き終えても分流結果がおかしい場合は、まずノード自体を疑うのではなく、以下の順序で確認してください。

ルールの順序を確認する
目的のルールより前に、より広範なルールが書かれていてトラフィックを先取りしていないか見直します。これが最もよくある原因です。
rule-providersが正しく読み込まれているか確認する
GEOSITEやRULE-SETを使う場合、対応するルールセットのアドレスが無効だったり形式が合っていないと、コアの起動が失敗したり、そのルールが黙って無視されることがあります。クライアントのログで読み込み状態を確認する必要があります。
ポリシーグループ名の表記が一致しているか確認する
ルールの3段目に記入するポリシー名はproxy-groupsで定義された名称と完全に一致していなければならず、大文字小文字やスペースも合わせる必要があります。誤字があるとそのルールが全体的に無効になったりエラーになったりします。
より早いフォールバックルールにヒットしていないか確認する
コンフィグ内に複数のMATCHや、早すぎる位置に置かれた広範なGEOIP/GEOSITEルールが存在すると、新たに追加した精確なルールはその後ろに追いやられ、永遠に実行されない可能性があります。

ルールシステムは「上から順に、一致したら終了」というこの1本の主軸ロジックを一度理解すれば、以降知らないサブスクリプションのコンフィグを受け取る場合でも、自分でゼロから分流ポリシーを構築する場合でも、トラブル対処の思考がかなり明確になります。カスタムルールは一箇所にまとめて管理し、コメントで境界を明示しておくと、長期的なメンテナンスがより楽になります。