Clashのルール設定ガイド：DOMAIN-SUFFIX・IP-CIDRの照合順とMATCHのフォールバック

ルールが効かないときは、まずルールモードで通信しているか確認

WebサイトをDIRECTにするルールを追加したのに通信がプロキシ経由になる、IPアドレス範囲をプロキシに変更しても結果が変わらない。こうした問題は、必ずしも構文エラーとは限りません。まずアプリの通信がClashを経由しているか、次にカーネルがルールモードになっているかを確認し、その後でルールの内容を調べましょう。

クライアントの「プロキシモード」で「ルール（Rule）」を選択します。クライアントによっては「ルールモード」と表示されます。「グローバル（Global）」や「ダイレクト（Direct）」モードでは、ルールによる振り分けを確認できません。
「接続（Connections）」画面を開き、対象のWebサイトに再アクセスします。新しい接続が表示されない場合は、システムプロキシやアプリ独自のプロキシ設定、TUNの対象範囲を確認してください。
現在選択されている設定ファイルが、実際に編集したものか確認します。ファイルを保存した後は、クライアントで設定を再読み込みしてください。保存しただけでは、実行中のカーネルに反映されないことがあります。
対象アプリの既存接続を切断してから再テストします。ルールによる出力先の選択は、主に接続時に行われます。設定ファイルを変更しても、確立済みの長時間接続は自動で振り分け直されません。

ルールの基本構造：種類・照合値・出力先ポリシー

一般的なルールはYAMLのrules:リストに記述し、各行をハイフンで始めます。ドメインルールは通常、ルールの種類、照合値、出力先ポリシーの3項目で構成されます。MATCHには照合値が不要です。no-resolveに対応するIP系ルールでは、4つ目の項目を追加できます。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

この設定例では、構造が分かりやすいように組み込みポリシーだけを使用しています。DIRECTは直接接続、REJECTは接続拒否を表します。実際にプロキシを使う場合、最後の項目には設定済みのプロキシノード名またはプロキシグループ名を指定してください。PROXYは、すべての設定で使える共通の組み込みポリシーではありません。同名のノードやプロキシグループがなければ、そのままコピーすると設定の読み込みに失敗することがあります。

半角の英語カンマを使い、日本語の読点に置き換えないでください。
YAMLのインデントにはスペースを使い、Tabは使わないでください。同じリスト内のルールは同じ幅でインデントします。
ポリシー名は定義と完全に一致させてください。大文字・小文字、スペース、記号にも注意が必要です。
既存の設定を編集する場合は、項目を元のrules:の下に追加してください。同じ名前のトップレベルキーを重ねて追加しないでください。

ドメインルール：DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORD

種類	例	照合範囲
`DOMAIN`	`DOMAIN,example.com,DIRECT`	example.comのみが対象で、www.example.comは含みません。
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	example.com自体に加え、www.example.comやapi.example.comなどのサブドメインも対象です。
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,REJECT`	ドメイン名にexampleという文字列を含む接続が対象です。サフィックスルールより広い範囲に一致します。

サフィックスはドメイン名の境界で照合され、任意の文字列の末尾とは一致しません

DOMAIN-SUFFIX,example.com,DIRECTはa.example.comに一致しますが、notexample.comやexample.com.other.orgには一致しません。通常、*.example.comと書く必要はありません。このサフィックスルールには、サブドメインも含まれます。

ルール値にはドメイン名だけを指定し、https://やポート番号、パスは含めません。https://example.com:8443/accountにアクセスする場合も、ドメイン欄はexample.comです。一般的なドメインルールでは、同じサイト内の/accountと/videoを区別できません。

個別の例外ルールは、範囲の広いルールより先に記述

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - MATCH,DIRECT

この例では、login.example.comをDIRECTにし、それ以外のexample.comドメインを拒否します。先頭の2行を入れ替えると、ログイン用ドメインが先にサフィックスルールに一致し、その後の個別ルールは適用されません。カーネルがルールの「精度」を比較したり、一致後により適切な候補を探したりすることはありません。

DOMAIN-KEYWORDは、照合範囲を明確に把握できている場合に適しています。よくある短い単語だけでサービス全体を振り分ける用途には向きません。キーワードが短いほど、たまたま同じ文字列を含む別のドメインまで誤って対象にする可能性が高まります。

IP-CIDRとGEOIP：アドレス範囲と地域データベースの違い

IP-CIDRは、接続先のIPv4アドレスが指定したネットワーク範囲に含まれるかを判定します。192.168.0.0/16の範囲は192.168.0.0から192.168.255.255までです。/32は単一のIPv4アドレスを表します。IPv6のアドレス範囲にはIP-CIDR6を使い、単一のIPv6アドレスは/128で指定できます。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ選択

GEOIP,CN,DIRECTは、読み込まれているIP地域データベースで接続先がCNに属するか判定し、一致すれば直接接続する設定です。「中国語のWebサイトをすべて直接接続する」という意味ではなく、ページの言語やドメインの末尾で判定するものでもありません。CDNのアドレス割り当て、データベースの更新状況、IPv4とIPv6の応答の違いにより、同じWebサイトでもネットワークによって結果が異なる場合があります。

特定のサービスを常に決まったポリシーで接続したい場合は、明確なドメインルールを優先してください。地域ルールは後方の補助ルールとして使うと管理しやすくなります。必要な地域データベースを読み込めない場合は、ルールの順序を変えて問題を覆い隠すのではなく、まずクライアントログでリソースの読み込みエラーを確認してください。

no-resolveの役割：このルールのためだけにドメインを追加で名前解決しない

接続にドメイン名が含まれていて、ルールが接続先IPを必要とする場合、カーネルはIP照合のためにDNS問い合わせを行うことがあります。no-resolveは、このIPルールのためにドメイン名を自動で名前解決するのを防ぎます。DNS全体を無効にする設定でも、IPルールを無視する指定でもありません。

接続先がもともとIPアドレスの場合：アドレスがネットワーク範囲内かを直接判定できます。no-resolveが付いていても一致する場合があります。
接続に利用可能な接続先IPが含まれている場合：引き続き照合される可能性があります。この設定を「ドメイン名を使う接続は必ずスキップする」と解釈しないでください。
ドメイン名のみで、利用可能な接続先IPがない場合：このルールのためだけに追加の名前解決は行われず、後続のルールが引き続き確認されることがあります。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ選択

この順序では、まず明示的なドメインルールを適用し、次にプライベートIPアドレスを確認してから、地域判定を行います。2つ目のルールにはno-resolveが付いていますが、3つ目には付いていないため、地域照合に必要な名前解決が行われる可能性があります。特定のルールにパラメーターを付けても、それ以降のすべてのルールのDNS動作が制限されるわけではありません。

3つ目のルールをGEOIP,CN,DIRECT,no-resolveに変更すると、ドメイン名しかなく利用可能な接続先IPもない接続は、ここで地域判定できず、プロキシのフォールバックに進む可能性があります。追加するかどうかは、想定する振り分け結果とDNSの経路を踏まえて判断してください。問い合わせを減らす目的で、すべてのルールに機械的に付けるのは避けましょう。

MATCHのフォールバックと上から順に並べるルール原則

MATCHは無条件で一致するルールで、MATCH,ポリシー名と記述します。通常はルールリストの最後に配置し、それまでのルールに一致しなかった接続を受け持たせます。MATCH,*,ポリシー名とは書かず、有効なルールが残っている位置より前に配置しないでください。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,プロキシ選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ選択

3つのアクセスでルールの順序を確認

login.example.comにアクセス：1つ目のルールに一致した時点で照合が終了し、DIRECTが適用されます。
static.example.comにアクセス：1つ目のルールには一致せず、2つ目に一致するため、「プロキシ選択」プロキシグループに渡されます。
上記のドメインに該当せず、接続先アドレスもIPルールや地域ルールに一致しないサービスにアクセス：最後にMATCHによって「プロキシ選択」に渡されます。

これは設定から導き出した結果であり、例示したドメインでサービスにアクセスできることを保証するものではありません。実際に試す際は、振り分けたい対象に置き換えてください。また、プロキシグループに一致しても、必ずリモートノードを経由するとは限りません。グループでDIRECTが選択されていれば、最終的には直接接続されます。

実用的な並び順は、個別の例外、明示的なドメイン範囲、その他のサービス用ルールやルールセット、IP・地域ルールによる補足、最後にフォールバックです。この順序はカーネルが強制するものではありません。要件上、拒否ルールを例外より優先したい場合は、そのルールを前に配置してください。ルールの種類だけで機械的に分類するのではなく、各ルールが後続のどの項目に影響するかを把握することが重要です。

サブスクリプションとルールセット：内容だけでなく配置も確認

サブスクリプション更新後にカスタムルールが消える場合、再ダウンロードで上書きされるサブスクリプションファイルを編集していることがよくあります。まず元の設定を保存し、クライアントの上書き・マージ・拡張設定機能を使ってください。設定画面の場所やマージ形式はクライアントごとに異なります。特定のクライアント専用の拡張フィールドを、Clashカーネル共通の設定として扱わないでください。

RULE-SETも配置順の影響を受ける

Clash対応の該当カーネルバージョンおよびmihomoでは、ルールプロバイダーは通常rule-providers:で定義し、RULE-SET,プロバイダー名,ポリシー名で参照します。参照ルールも同じ上から順の照合に加わります。前にある広範なドメインルールに一致すると、その後のルールセットは確認されません。

behavior: domainのデータにはドメイン集合の形式を使い、出力先を含む3項目のルールをそのまま入れないでください。
behavior: ipcidrのデータはIPアドレス範囲です。アドレス範囲の集合に適しています。
behavior: classicalではルール条件の形式を使います。最終的な出力先ポリシーは、それを参照するRULE-SETの項目で指定します。

オリジナル版Clash、各種の旧派生版、mihomoでは、ルールの種類や拡張フィールドが完全には一致しません。unsupported rule typeなどのエラーが表示されたら、まずクライアントの「バージョン情報」またはカーネル情報を確認し、実際に動作しているカーネルを特定してから、対応するドキュメントを確認してください。クライアントアプリを更新しても、カーネルが切り替わるとは限りません。

ルールを検証する：一度に1項目だけ変更し、一致ルールと最終出力先を確認

バックアップして保存します。正常に起動できる設定を1つ保管し、個別のドメインルールを1件だけ追加します。再読み込み後、解析エラーがないか確認してください。
既存の接続を終了します。対象アプリを閉じるか、クライアントの「接続」画面で該当する接続を終了してから、リクエストを再実行します。ブラウザーのHTTP/2・HTTP/3接続再利用により、以前の経路が使われ続ける場合があります。
接続先を確認します。接続の詳細画面で、ドメイン名、接続先IP、一致したルール、ポリシーの経路を確認してください。項目名はクライアントによって多少異なります。全体の通信量グラフだけで判断しないでください。
ログを確認します。必要に応じて一時的にlog-levelをdebugに設定し、問題を再現したらinfoに戻します。ログを共有する前に、サブスクリプションURL、トークン、公開すべきでないアドレスを伏せてください。

症状	まず確認する項目
常にMATCHに一致する	ルールが読み込まれているか、ドメイン名に誤りがないか、接続にIPアドレスしか含まれていないか、ルールセットの読み込みに成功しているか。
個別ルールに一致しない	前にあるサフィックスルール、キーワードルール、ルールセットが対象を先に拾っていないか。テストした接続が変更前から確立されていないか。
プロキシグループに一致するのに直接接続される	プロキシグループで現在DIRECTが選択されていないか、ネストされたグループの最終選択がどうなっているか。
一部のアプリでドメインルールが効かない	接続にドメイン名が含まれているか、アプリが独自に名前解決していないか、システムプロキシやTUNが実際にアプリの通信を取り込んでいるか。
サブスクリプション更新後に元の状態へ戻る	編集したのがサブスクリプションの元ファイルか、永続化される上書き設定か。カスタムルールが広範なルールより後にマージされているか。

通信に接続先IPしか含まれない場合、ドメインルールの照合に必要な情報が不足することがあります。mihomoのFake-IPマッピング、DNSの取り込み、スニッフィング設定は、ドメイン情報を利用できるかどうかに影響します。ただし、スニッフィングですべてのプロトコルを識別できるわけではなく、暗号化された接続から常に実際のドメイン名を取得できるわけでもありません。まず接続の詳細を確認し、DNSやスニッフィングの設定を見直してください。複数の項目を同時に変更するのは避けましょう。