Clashのカスタムルール設定方法｜rulesの書き方・評価順序・優先順位を解説

1. rulesの役割と基本構文

rulesは設定ファイル直下に記述する順序付きリストで、接続をどのポリシーに渡すかを決めます。プロキシノードの作成や速度測定を行う項目ではありません。ルールの右側には、組み込みポリシーのDIRECTやREJECTのほか、設定済みのプロキシノード名やポリシーグループ名を指定できます。名前はスペースや大文字・小文字も含め、設定内の表記と完全に一致させてください。

この記事では、Clash Nyanpasuでmihomoコアを使う標準的なルールモードを前提に説明します。Clashはコアによって対応する拡張ルールが異なります。設定を移行する場合は、クライアントのコア情報や起動ログで実際に使われているコアを確認してください。基本的なドメインルールは通信の振り分けを理解するのに役立ちますが、すべてのコアが同じ高度な項目に対応しているとは限りません。

モードを確認してから設定を編集

Ruleモード：rulesのリストに従って接続先を振り分けます。この記事で扱うモードです。
Globalモード：グローバルポリシーを使い、通常のrulesリストによる振り分けは行いません。
Directモード：すべての通信を直接接続として処理します。プロキシ振り分けルールの検証には使えません。

YAMLのmode: ruleはルールモードを表します。クライアントの画面から実行モードを切り替えられる場合もあるため、現在の動作状態も確認してください。システムプロキシやTUNは、どの通信をコアに取り込むかを決めるもので、ルールの優先順位を切り替える機能ではありません。コアに届いていない接続は、ルールを追加しても自動的には処理されません。

mode: rule
rules:
  - DOMAIN,portal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,ノード選択

2. よく使うルールタイプと項目の位置

一般的なルールは「タイプ、マッチ条件、適用先ポリシー」の順に記述します。MATCHにはマッチ条件は不要です。IPルールの一部では、末尾にno-resolveを追加できます。引数は半角カンマで区切り、リストの各行はハイフンとスペースで始めます。インデントにはスペースを使い、Tabは使わないでください。

タイプ	例	マッチ条件
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	完全一致するドメインapi.example.comだけにマッチします。
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	ルートドメインとすべてのサブドメインにマッチします。
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,ノード選択`	ドメイン名に指定した文字列を含むものにマッチします。対象範囲が広くなります。
`IP-CIDR`	`IP-CIDR,10.0.0.0/8,DIRECT,no-resolve`	IPv4アドレスの範囲にマッチします。
`IP-CIDR6`	`IP-CIDR6,fc00::/7,DIRECT,no-resolve`	IPv6アドレスの範囲にマッチします。
`GEOIP`	`GEOIP,CN,DIRECT`	接続先IPアドレスの地理データベース上の分類で判定します。
`RULE-SET`	`RULE-SET,business,ノード選択`	businessという名前のルールプロバイダーを参照します。
`MATCH`	`MATCH,ノード選択`	前のルールに一致しなかった接続をすべて受け取ります。

ドメインルールにURLのパスは指定しない

DOMAINのマッチ条件に指定するのはホスト名であり、URL全体ではありません。api.example.comのように記述し、https://api.example.com/loginのようなURLは指定しません。通常のドメインルールでは、同じホスト内の/loginと/imagesを区別できません。HTTPSリクエストのパスも、一般的なドメイン振り分けの条件としては使えません。

DOMAIN-SUFFIX,example.comはexample.comとa.example.comにマッチしますが、文字列が似ているだけのnotexample.comにはマッチしません。一方、DOMAIN-KEYWORDは文字列による条件のため対象が広がりやすく、通常は明示的なドメイン例外より後に配置します。

3. ルールの優先順位：上から順に評価し、最初の一致を適用

通常のルールリストには、「ドメインルールがIPルールより常に優先される」「条件が細かいほど優先される」といった自動並べ替えはありません。コアはリストの上から順に評価し、最初に一致したルールのポリシーを適用します。それより下のルールで上書きされることはありません。例外ルールを機能させるには、対象範囲の広いルールより前に置く必要があります。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - MATCH,ノード選択

api.example.com：1行目に一致し、直接接続します。
www.example.com：1行目には一致せず、2行目に一致して「ノード選択」に渡されます。
example.net：上の2行には一致せず、3行目のフォールバックが適用されます。

2行目を1行目より前に移動すると、api.example.comは先にサフィックスルールに一致し、本来の直接接続の例外が機能しなくなります。同様に、MATCHをリストの先頭に置くと、後続の通常ルールはマッチする機会を失います。

4. IP-CIDR、GEOIP、no-resolve

IP-CIDR,192.168.0.0/16,DIRECTは、192.168.0.0から192.168.255.255までのIPv4アドレスを対象にします。単一のIPv4アドレスだけを指定する場合は/32、単一のIPv6アドレスだけなら/128を使えます。アドレス範囲は実際の用途に合わせて指定してください。すべてのプライベートアドレスを同じ用途のルールとして扱うべきではありません。

接続先がドメイン名の場合、IPルールで判定するために名前解決が必要になることがあります。末尾にno-resolveを追加すると、そのルールのためだけに名前解決を開始しないよう指定できます。接続先IPがすでに取得されている場合は、引き続きアドレスでマッチングできます。これはクライアント全体のDNSを無効にする設定でも、すべてのDNSリクエストを省略する設定でもありません。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

内部ドメインが分かっている場合は、個別のルールとして前方に置きます。no-resolve付きのアドレスルールでは、ドメイン名だけをもとに内部アドレスを判定できるとは限らないためです。GEOIPが参照するのは接続先IPのデータベース上の分類であり、ページの内容、ドメインの登録地、サーバーのブランドではありません。CDNの利用状況やデータベースの更新によって結果が変わることもあります。

5. RULE-SETとrule-providersの連携

ルールが多い場合は、マッチ条件をルールプロバイダーにまとめ、RULE-SETで参照できます。rule-providersではデータの取得元と形式を定義し、rulesではマッチング処理内での位置と、一致したときに適用するポリシーを定義します。プロバイダー名を登録しただけでは振り分けに使われません。rulesから参照する必要があります。

ローカルのdomainルールセットの例

ここではmihomoのローカルファイルプロバイダーを使います。指定したルールセットのファイルは、コアが実際に使用する設定ディレクトリに配置してください。相対パスは実行時の作業ディレクトリを基準にするため、ダウンロードしたファイルの場所だけから読み込み先を判断しないでください。クライアントのログで実際の読み込みパスを確認できます。

rule-providers:
  business:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/business.yaml

rules:
  - DOMAIN,health.example.org,DIRECT
  - RULE-SET,business,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

./rules/business.yamlには次の内容を記述します。domainタイプでは+.example.orgが該当ドメインとそのサブドメインにマッチします。domainタイプのリストにDOMAIN-SUFFIX,example.org,ノード選択のようなルール行全体を記述しないでください。

payload:
  - '+.example.org'
  - 'api.example.net'

behavior: domain：ドメインのマッチ条件を記述します。
behavior: ipcidr：IPアドレス範囲を記述します。
behavior: classical：対応するコアがサポートするルール条件を記述します。例：DOMAIN-SUFFIX,example.org。通常、各項目に適用先ポリシーは記述しません。

3種類のbehaviorを混在させることはできません。リモートプロバイダーにはダウンロード、更新、キャッシュも関係するため、問題を調べるときは、まずプロバイダーが正常に読み込まれていることを確認してから優先順位を確認してください。ルールセットに数千件の条件があっても、メインリスト上の優先順位はそのRULE-SET行の位置で決まります。メインリストの前方にあるルールが先に一致した場合、後から上書きされることはありません。

6. サブスクリプション更新後のルール保持と上書き確認

リモートサブスクリプションの更新時に設定が再生成されることがあります。ダウンロードしたYAMLを直接編集すると、今回だけ反映され、次回の更新で消えるケースがよくあります。元のサブスクリプションを残したうえで、クライアントが対応するローカル上書き、マージ、またはスクリプト処理の段階に個人ルールを追加し、処理後の最終的な並び順を確認する方法がより安全です。設定項目の名称はクライアントのバージョンによって異なります。「サブスクリプションのテキストを保存」することと、上書き設定を永続化することは同じではありません。

現在使えている設定をバックアップし、選択中のProfile、モード、ポリシーグループ名を記録します。
プロファイル管理で、未適用のコピーではなく、現在使用中の設定を編集していることを確認します。
まず明示的なドメインルールを1つ追加し、既存の広い範囲のルールより前に配置します。
実行時に生成された設定を確認し、rulesが1つだけであることと、先頭のルール、ルールセットの参照、末尾のMATCHを確認します。
サブスクリプションを更新し、ルールが保持されているか、順序が変わっていないかを再確認します。

マージツールによって、リストを置き換える、末尾に追加する、先頭に挿入するなど動作が異なります。テキストに新しいルールが見えるだけでは、有効になったとは限りません。MATCHより後ろに追加したルールは存在していてもマッチできません。スクリプトによる上書きも、実行に成功したかだけでなく、出力結果を確認してください。YAMLの階層と項目の説明はYAML設定ガイドを参照してください。

7. カスタムルールが反映されないときの確認手順

切り分けでは同じ接続先ホストを使い、ポリシーグループの選択を固定して、一度に変更する条件は1つだけにします。接続パネルに表示される「マッチしたルール」「適用されたポリシー」「実際のプロキシ経路」はそれぞれ異なる情報です。「ノード選択」に一致した場合も、グループ内でDIRECTが選ばれていれば、実際の接続は直接接続です。

症状	まず確認する項目	対処方法
接続パネルに対象のリクエストが表示されない	アプリの通信がコアに取り込まれているか	システムプロキシ、アプリのプロキシ設定、またはTUNのルーティングを確認し、まず通信の入口を確保します。
以前からある広範囲のルールに一致する	カスタムルールの実際の行順	詳細な例外ルールを対象ルールより前に移動し、上書き設定が末尾への追加になっていないか確認します。
ポリシーが存在しないというエラーが表示される	ルール右側のグループ名	現在の設定からグループ名をそのままコピーし、スペース、大文字・小文字、設定の切り替えを確認します。
RULE-SETの読み込みに失敗する	プロバイダー名、パス、behavior	起動ログとファイル形式を確認し、通信をテストする前に読み込みエラーを修正します。
変更後も以前のポリシーが適用される	既存の接続が再利用されていないか	対象の接続を閉じてリクエストを再度実行します。既存の長時間接続を更新するだけでは解決しない場合があります。
サブスクリプション更新後にルールが消える	変更が生成後の設定ファイルに保存されているか	永続化される上書き設定に移行し、更新後の最終設定を確認します。

最小構成で動作を確認する

実行モードがRuleで、選択中の設定が適用済みであることを確認します。
実際にテストするドメイン用にDOMAINルールを1つ追加し、リストの前方に配置します。
設定を保存して適用します。パースエラーが発生した場合は、変更を重ねずにバックアップへ戻してください。
対象への既存の接続を閉じてから、もう一度アクセスします。
接続の詳細で、接続先ホスト、マッチしたルール、ポリシーグループ、実際の出口を確認します。
動作を確認した後でサフィックスルールやルールセットに広げ、どのルールにも一致しない場合のフォールバックも再テストします。

ルールのメンテナンスで確認するポイントは3つです。通信が実際にコアへ届いていること、マッチ条件と接続情報が一致していること、対象ルールがそれを先に拾うルールより前にあること。まず完全一致のドメインで再現可能な結果を確認し、その後にIP分類やルールセットを追加すると、多数のルールを一度に変更するより原因を特定しやすくなります。Profile、ポリシーグループ、TUNの違いは用語ガイドを参照してください。

Clashのカスタムルール設定方法：rulesの書き方・評価順序・優先順位を解説