Clashのカスタムルール構文を詳しく解説：マッチ方式・並び順・優先順位

Clashのルールマッチングモデル

Clashのルールシステムは、現在の接続をどのポリシーグループ、プロキシノード、または組み込みアクションで処理するかを決めるためのものです。接続がコアに入ると、設定ファイルに記述された順番に従って上から下へルールを確認し、条件を満たした最初のルールが直ちに適用されます。その後のルールは同じ接続の判定に使われません。すべてのマッチ結果を集計して「精度」を比較する仕組みではなく、ドメインルールが自動的にIPルールより優先されることもありません。

一般的なルールは、ルールタイプ、マッチ対象、処理先ポリシーの3つで構成され、各フィールドは半角カンマで区切ります。例：

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Final

DOMAIN、DOMAIN-SUFFIX、IP-CIDR はルールタイプです。ドメイン名やネットワーク範囲がマッチ対象で、DIRECT、Proxy、Final が処理先です。処理先の名前は、大文字・小文字、空白、記号を含め、設定内のプロキシグループ名と完全に一致させる必要があります。DIRECT は直接接続、REJECT は接続拒否を表し、プロキシグループ名を指定した場合は、そのグループが最終的に使用するノードを決定します。

ルールは通常、接続のメタデータである宛先ドメイン、宛先IP、ポート、ネットワーク種別、接続元プロセスなどを処理します。Webページ本文を読み取ってサイトのカテゴリを判定するものではありません。1つのアプリが同じページ内で複数のドメインへアクセスする場合、メインページ、画像、動画、API、解析リクエストがそれぞれ別のルールにマッチすることがあります。ルールの適用状況を確認するときは、アドレスバーのメインドメインだけでなく、個々の接続を確認してください。

ドメインのマッチ構文：完全一致・サフィックス・キーワード

DOMAIN：完全なドメイン名だけにマッチ

DOMAIN は、特定のホスト名を処理する場合に適しています。次のルールは api.example.com にマッチしますが、www.example.com、v2.api.example.com、その他のサブドメインにはマッチしません。

- DOMAIN,api.example.com,Proxy

特定のAPIだけを個別に振り分け、同じ親ドメインに属する他のサービスは従来のポリシーのままにしたい場合、完全一致のドメインルールが適しています。実際の接続におけるドメイン比較では通常、大文字と小文字は区別されませんが、確認・検索・重複排除をしやすくするため、小文字で統一することをおすすめします。

DOMAIN-SUFFIX：親ドメインとサブドメインにマッチ

DOMAIN-SUFFIX は、カスタムルールでよく使われるタイプです。次のルールは example.com、www.example.com、cdn.media.example.com を対象にできます。

- DOMAIN-SUFFIX,example.com,Proxy

サフィックス値には通常、ドメイン名をそのまま記述し、先頭にドットやワイルドカードを付ける必要はありません。*.example.com と書くと、期待どおりに動作しない場合があります。ルールタイプ自体がサフィックスマッチの意味を持つためです。特定のサブドメインを除外する場合は、例外ルールを汎用的なサフィックスルールより前に置きます。

- DOMAIN,internal.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,Proxy

DOMAIN-KEYWORD：ドメイン名内の文字列にマッチ

DOMAIN-KEYWORD は、ドメイン名に指定した文字列が含まれているかを確認します。たとえば DOMAIN-KEYWORD,example,Proxy は、example.com だけでなく、example-cdn.net や notexample.org にもマッチする可能性があります。対象範囲が広いため、ドメイン構造が頻繁に変わる一方で、安定した命名要素を持つサービスに適しています。すべてのサフィックスルールを置き換える用途には向きません。

キーワードが短いほど、意図しないマッチが起きやすくなります。無関係なサイトまでプロキシ経由になっている場合は、前方にある DOMAIN-KEYWORD ルールを優先的に確認してください。完全な親ドメインが分かっている場合は、DOMAIN または DOMAIN-SUFFIX を使うのが基本です。

GEOSITE：ドメインカテゴリの集合でマッチ

Clash Meta、つまり現在広く使われている mihomo コアでは、GEOSITE を使ってあらかじめ整理されたドメインカテゴリのデータを参照できます。例：

- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT

GEOSITE で利用できるカテゴリは、クライアントに付属する、またはダウンロードされたGeoSiteデータファイルに依存します。カテゴリ名が存在しない、データベースが更新されていない、使用中のコアがこのルールに対応していないといった場合、設定エラーや意図しないマッチが発生する可能性があります。別の設定からルールをコピーする前に、現在のクライアントのコア種類とデータファイルの入手元を確認してください。

IP・ポート・ネットワーク種別のルール

IP-CIDRとIP-CIDR6

IP-CIDR はCIDRのネットワーク範囲を使ってIPv4の宛先アドレスにマッチさせ、IP-CIDR6 はIPv6に使用します。スラッシュの後ろの数字はネットワークプレフィックス長を示します。単一のIPv4アドレスには /32、単一のIPv6アドレスには /128 を指定できます。

- IP-CIDR,203.0.113.8/32,Proxy,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR6,2001:db8::/32,Proxy,no-resolve

接続が最初にドメイン名として渡された場合、一部のIPルールでは、宛先IPを取得して判定を続けるためにドメイン名を解決することがあります。ルール末尾の no-resolve は、このIPルールを確認するための追加のドメイン解決を行わないことを示します。LANの予約アドレスや既知のサーバーアドレスなど、ドメイン解決を必要としないルールには通常このパラメータを追加でき、不要なDNS問い合わせを減らせます。

no-resolve は、Clash全体のDNS機能を無効にするという意味ではなく、アプリ自身が行うDNSリクエストを阻止するものでもありません。現在のルールのマッチング中に、ドメイン名をIPへ能動的に解決するかどうかだけに影響します。解決後のアドレス範囲に依存するルールへ、機械的にこのパラメータを追加しないでください。

GEOIP：IPデータベースのカテゴリでマッチ

GEOIP は、宛先IPの地理データベース上のカテゴリに基づいてマッチします。一般的な書式は次のとおりです。

- GEOIP,CN,DIRECT,no-resolve

このタイプのルールの結果は、GeoIPまたはGeoDataデータベースの内容に左右されます。IPアドレスの割り当ては変わることがあり、クラウドサービスやコンテンツ配信ネットワークも複数地域へ振り分けられる場合があります。そのため GEOIP は、すべての完全一致ドメイン例外を覆うのではなく、リスト後半の範囲指定ルールとして使うのが適切です。処理方法を固定したいサービスには、明示的なドメインまたはIPルールを前に置いてください。

ポートとプロトコル

mihomo では、DST-PORT、SRC-PORT、NETWORK などのタイプを使って接続条件をさらに絞り込めます。宛先ポートルールはサーバー側のポート、送信元ポートルールは本機の接続に使われるポートを対象にします。ネットワーク種別には通常、tcp または udp を指定します。

- DST-PORT,22,SSH
- DST-PORT,3478-3481,Realtime
- NETWORK,udp,UDP-Policy

ポートだけで振り分けると、同じポートを使う他のプログラムにも影響しやすくなります。たとえばHTTPSでは443番ポートが広く使われるため、443番へのすべての通信を固定ポリシーへ送るのは範囲が広すぎます。ドメイン、プロセス、論理ルールを組み合わせて対象を絞り、変更後は接続一覧を確認するほうが安全です。

プロセスルールと論理条件の組み合わせ

PROCESS-NAMEとPROCESS-PATH

PROCESS-NAME は、接続を開始した実行ファイル名でマッチさせます。特定のアプリ全体に同じポリシーを適用したい場合に便利です。Windowsのプログラム名には通常、拡張子が含まれます。

- PROCESS-NAME,example.exe,Application-Proxy
- PROCESS-NAME,curl,DIRECT

PROCESS-PATH は実行ファイルの完全なパスにマッチさせられるため、同名の実行ファイルが複数ある場合により正確です。ただし、パスの書式はOSやコアの実装に左右されます。Windowsのパスに含まれるバックスラッシュ、空白、YAMLの引用符は正しく扱う必要があります。アプリのアップデートでインストール先が変わると、古いパスルールが機能しなくなることもあります。

プロセスを識別できるかどうかは、プラットフォーム、実行権限、通信の取り込み方式に左右されます。システムによっては特定の権限がないとプロセス情報を取得できず、一部の転送経路では元のプロセスを特定できない場合もあります。プロセスルールが適用されないときは、ルールの文言を何度も変更する前に、クライアントの接続詳細でプロセス名が表示されているか確認してください。

AND・OR・NOT

mihomo は論理ルールに対応しており、複数の条件を組み合わせられます。たとえば、特定のアプリが特定のドメインへアクセスするときだけプロキシを使用する設定です。

- AND,((PROCESS-NAME,example.exe),(DOMAIN-SUFFIX,example.com)),Proxy
- OR,((DST-PORT,80),(DST-PORT,443)),Web
- NOT,((NETWORK,udp)),TCP-Policy

論理ルールは、明確なAND・OR・除外条件を表現するのに適しています。ただし、括弧の入れ子が増えると保守の負担が急激に高まります。論理ルールや子ルールのタイプに対する対応範囲は、コアのバージョンによって異なる場合があります。保存後にクライアントで解析エラーが表示されたら、現在の mihomo ドキュメントで括弧、カンマ、対応ルールタイプを確認してください。

ルールの並び順と優先順位

Clashの優先順位における基本原則は「先にマッチしたら停止」です。ルールタイプそのものに共通の隠れた重み付けはありません。後ろにより具体的な DOMAIN があっても、前の DOMAIN-SUFFIX、GEOSITE、その他の広範囲なルールにマッチすれば、後続の完全一致ルールは実行されません。

実用的な並べ方は、例外を前方、範囲指定ルールを中央、フォールバックを最後に置く構成です。

1. LANアドレス、内部ドメイン、直接接続が必要な例外。
2. 固定プロキシまたは固定拒否にしたい特定ドメイン。
3. 特定アプリ、ポート、論理条件の組み合わせ。
4. ドメインサフィックス、ルールセット、GEOSITE、GEOIPなどの範囲指定ルール。
5. MATCH のフォールバックルール。

rules:
  - DOMAIN,login.internal.example,DIRECT
  - DOMAIN,api.example.com,Service-Proxy
  - PROCESS-NAME,example.exe,Application-Proxy
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

この設定では、api.example.com は先に完全一致のドメインルールへマッチし、後ろの example.com サフィックスルールには到達しません。このサフィックスに属するその他のドメインは Proxy に渡されます。前のどのルールにも処理されなかった接続は、最後に Final へ渡されます。

MATCH は無条件のフォールバックなので、ルールリストの最後に置きます。古い設定では同様の目的で FINAL を使うこともありますが、実際の対応状況はコアによって異なります。mihomoの設定では、現在のコアのドキュメントに従い、MATCH を優先してください。フォールバックを途中に置くと、その後のルールは永遠にマッチしません。

ルールの処理先がプロキシグループの場合、ルールが決めるのは「どのグループへ入れるか」だけで、ノードの選択はプロキシグループのタイプが決めます。たとえば手動選択グループはユーザーが現在選んでいるノードを使い、自動速度テストグループはグループ内のテスト結果に基づいて選択します。経路を調査するときは、「ルールが誤ったグループにマッチした」のか、「グループ内で適切でないノードが選ばれた」のかを切り分けてください。

サブスクリプションルールの上書きと永続化

サブスクリプション設定は通常、サーバー側で生成されます。クライアントで展開後のYAMLを直接編集すれば一時的には反映できますが、次回のサブスクリプション更新で変更内容が新しい設定に置き換わる可能性があります。長期的に保持したいカスタムルールには、クライアントが提供するオーバーライド、設定マージ、拡張スクリプト、ローカル設定機能を使用してください。

クライアントによってマージ機能の名称は異なりますが、目的は通常、次の3種類に分けられます。

• 前置ルール：サブスクリプションのルールリスト先頭に挿入します。優先度の高い例外の追加に適しています。
• 後置ルール：リスト末尾に追加します。ただし、サブスクリプションに MATCH がすでに含まれている場合、追加した内容にはマッチしない可能性があります。
• 全体置換：サブスクリプション内の全ルールをカスタムリストで置き換えます。必要なLAN、DNS、直接接続、フォールバックのロジックは自分で維持する必要があります。

したがって、「ルールを1つ追加する」ことが「優先度を上げる」ことになるとは限りません。サブスクリプションの既存結果を上書きしたい場合、新しいルールは関連する広範囲ルールと最終フォールバックより前に置く必要があります。GUIクライアントでは、オーバーライド編集欄の順番だけでなく、マージ後の実際の設定や実行中の設定を確認してください。

RULE-SETとrule-providers

ルール数が多い場合は、rule-providers でルールセットを参照し、メインのルールリストで RULE-SET を使用できます。ルールプロバイダーはルール内容を読み込みますが、RULE-SET がメインリストのどこにあるかによって、優先順位が決まります。

rule-providers:
  private-services:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-services.yaml
    url: https://rules.example.com/private-services.yaml
    interval: 86400

rules:
  - DOMAIN,exception.example.com,DIRECT
  - RULE-SET,private-services,Proxy
  - MATCH,Final

behavior はルールセットの内容と一致させる必要があります。一般的な値には domain、ipcidr、classical があります。domainはドメイン集合、ipcidrはネットワーク範囲の集合、classicalはタイプ付きの完全なルールデータを格納するのに適しています。ルールファイルの具体的な形式は format とコアのバージョンにも左右されるため、メイン設定の rules セクション全体を、任意形式のルールプロバイダーファイルとしてそのまま使うことはできません。

リモートルールセットの読み込みに失敗した場合は、URLにアクセスできるか、ファイル形式が正しいか、保存先に書き込み可能かを確認し、クライアントログも確認してください。重要な振り分けをリモートルールセットに依存する場合は、適切な最終フォールバックを残しておくと、ルールセットが一時的に利用できないときも接続先が不明確になるのを防げます。

ルールが適用されないときの確認手順

ルールの問題は、一度に大量の内容を変更するのではなく、実行結果から原因を逆算して調べるのが適しています。次の順番で確認すると、構文、順序、名前解決、クライアントの対応能力に関する問題を切り分けられます。

1. 現在の設定が有効か確認する。クライアントには複数の設定ファイルが保存されている場合があります。変更後は保存、再読み込み、または設定の切り替えを行い、実行中の設定が編集したバージョンと同じか確認してください。
2. 接続詳細を確認する。宛先ドメイン、宛先IP、ネットワーク種別、プロセス名、マッチしたルール、最終ポリシーグループを記録します。接続一覧に表示される情報はコアが実際に判定した結果であり、Webページのドメインから推測するより信頼性があります。
3. 前方にある広範囲ルールを確認する。DOMAIN-KEYWORD、DOMAIN-SUFFIX、GEOSITE、GEOIP、RULE-SET、MATCH を重点的に検索してください。
4. ポリシー名を確認する。ルール末尾の処理先は実在していなければなりません。グループ名を変更した後も、古いルールが削除済みの名前を参照している場合があります。
5. DNSの状況を確認する。アプリはIPへ直接接続することもあれば、キャッシュ、暗号化DNS、独自の名前解決機能を使うこともあります。ドメイン情報を取得できない場合、ドメインルールはマッチングに参加できない可能性があります。
6. コアの対応状況を確認する。プロセス、論理、GEOSITE、一部のポートルールは、コアとプラットフォームの機能に依存します。起動ログに未知のルールや設定解析に関するメッセージがないか確認してください。
7. 既存の接続を閉じて再試行する。すでに確立された長時間接続は、ルールを変更してもすぐには再判定されないことがあります。対象アプリの接続を閉じ、クライアントの接続履歴を消去するか、アプリを再起動してからテストしてください。

完全一致のドメインにマッチしないのはなぜか

よくある原因は、実際のリクエストが別のサブドメインへアクセスしている、接続詳細にIPしか表示されていない、完全一致ルールが広範囲ルールの後ろにある、または変更がサブスクリプション更新で上書きされた、といったものです。現在のWebサイトでは、ログイン、API、静的リソース、動画が別々のドメインに分けられていることがよくあります。まず接続一覧でアプリのプロセスを絞り込み、対象ホストを1つずつ確認してください。

ルールはマッチしているのにアクセス結果が変わらないのはなぜか

正しくマッチしたことが示すのは、接続が指定したポリシーに入ったという点だけです。ポリシーグループで現在選択されているノード、ノードの接続性、DNSの応答、アプリのキャッシュ、独立したIPv6接続の有無も確認してください。ポリシーグループが自動選択タイプの場合、テスト後にグループ内のノードが変わる可能性があります。ドメインがIPv4とIPv6の両方を返す場合、2つの接続が異なるタイプのルールにマッチすることもあります。

最小構成でのテスト

複雑な設定で競合の原因を特定しにくい場合は、十分に具体的なルールを一時的に1つ追加してリストの先頭に置き、判別しやすいポリシーグループへ振り分けます。テストに成功したら、ルールの順番を少しずつ元に戻してください。DNS、TUN、プロキシグループ、大量のルールを同時に変更すると、変化が起きたときに本当の原因を特定しにくくなります。

システムプロキシに従わないアプリをTUNモードで取り込む場合は、まずTUNが正常に起動しているか、ルーティングとDNSハイジャックの設定が現在のプラットフォーム要件に合っているかを確認してください。TUNは通信をコアへ送り、ルールはコアに入った後の処理方法を決めます。両者は異なる段階の機能です。TUNで取り込まれていない接続は、当然ながらルールのマッチング履歴に表示されません。