2026-07-05 上級設定 読了時間目安 9 分

Clash 自作ルールの書き方:DOMAIN・IP-CIDR 構文とマッチ優先順位を解説

Clash ルールでよく使う種類と書式を体系的に整理し、上から順に評価される優先順位の仕組み、GEOIP と MATCH の配置ポイントをわかりやすく解説。そのまま使える並び順のコツも紹介します。

一、ルール項目の基本構造

Clash の振り分け機能は一つひとつのルールの上に成り立っています。設定ファイルの rules: 項目に並ぶ各行が、独立したルールになります。ルールの共通フォーマットは3段構成で、それぞれをカンマで区切ります:

TYPE,ARGUMENT,POLICY

TYPE はマッチ判定の種類を示し、ドメイン・IP セグメント・プロセス名などが該当します。ARGUMENT は具体的なマッチ値です。POLICY はマッチ後に適用するポリシーで、プロキシノード名やポリシーグループ名のほか、組み込みの DIRECT(直接接続)や REJECT(拒否)も指定できます。一部のルールタイプは4番目の任意パラメータにも対応しており、最も一般的なのが no-resolve です。これは IP 系ルールをマッチさせる際に事前の DNS 解決を行わないよう指示するもので、不要な問い合わせによる遅延やプライバシー漏洩を避けられます。完全なルール例は以下の通りです:

DOMAIN-SUFFIX,example.com,Proxy
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

この3段構成(および任意の4段目)を理解しておくことが、後述するすべてのルールタイプを読み解く前提になります。

二、よく使うルールタイプを一つずつ解説

Clash コア(Clash Meta / mihomo 系も含む)が対応するルールタイプは多数ありますが、日常的な設定でよく登場するのは以下の数種類に集中しています。マッチ対象別に、ドメイン系・IP 系・地理位置系・プロセス/ポート系の4グループに分けて見ていきます。

1. ドメイン系ルール

2. IP・ネットワークセグメント系ルール

IP 系ルールは no-resolve パラメータと組み合わせて使うことが多く、特に直接接続用ルールでは、直接接続する通信に余計な名前解決のコストをかけないために有効です。

3. 地理位置系ルール

4. プロセス・ポート系ルール

5. ルールセットと兜底ルール

注意

DOMAIN-KEYWORD と DOMAIN-REGEX はマッチ範囲が広いため、上位に配置するとキーワードが重複した際に本来マッチさせるべきでない通信を先取りしてしまいがちです。厳密マッチ系のルールより後ろに置くことを検討してください。

三、マッチ優先順位:上から順に、当たったら即確定

Clash のルールを理解するうえで最も重要なのは、rules: リストの上から下への順序で1行ずつ厳密に評価され、どこかのルールにマッチした瞬間にそのルールのポリシーが適用され、それ以降のルールはチェックされないという点です。つまりルールの記述順そのものが優先順位を決めており、ルールタイプ自体に本来的な優劣はありません。DOMAIN であれ GEOIP であれ、先に評価されてマッチしたものが先に効きます。

陥りやすい例を一つ挙げます:

GEOIP,CN,DIRECT
DOMAIN-SUFFIX,example.com,Proxy

example.com が置かれているサーバーの IP が、たまたま地理情報データベース上で中国本土の IP と判定されている場合、上記の設定では最初の GEOIP ルールの時点で通信が直接接続に振られてしまい、その下にあるこのドメイン向けのプロキシルールは永遠に実行されません。特定のドメインを常にプロキシ経由にしたいなら、そのドメインルールを GEOIP より前に置く必要があります:

DOMAIN-SUFFIX,example.com,Proxy
GEOIP,CN,DIRECT

この順序の問題は、ルール項目が多い設定でとても起こりやすいものです。「プロキシを設定したはずのサイトがなぜかプロキシを通らない」という場合、まず確認すべきは、それより前に位置する範囲の広いルールに先取りされていないかという点です。

四、GEOIP と MATCH の配置ポイント

GEOIP ルールと MATCH 兜底ルールの位置は、ルール一覧全体の中でも特に強調すべき2つのポイントです。

GEOIP は細分化ルールの後ろに置く

GEOIP は宛先 IP が属する国・地域を判定するもので、カバー範囲がかなり広く、GEOIP,CN,DIRECT の1行だけで何千という個別ドメインをカバーしてしまう可能性があります。これをリストの上位に置くと、本来プロキシ経由にすべき特定サービスまで一緒に直接接続にされてしまいがちです。安全なやり方は、厳密に制御したいドメイン・アプリ・ポートのルールを先に書き、GEOIP 系ルールはそれらの細分化ルールより後ろ、兜底ルールより前に置くことです。こうすることで GEOIP は「特に指定されていない大多数のローカル通信を直接接続にする」という役割に絞られます。

MATCH は必ずリストの最終行に置く

MATCH は兜底ルールで、その名の通り、それまでのすべてのルールで処理されなかった通信を受け止める役割を持ちます。パラメータは不要で、書式は必ず MATCH,POLICY という形になり、サイトの振り分け方針によって MATCH,Proxy や MATCH,DIRECT がよく使われます。このルールが最後尾になければ、その後ろに来るはずの細かいルールで処理されるべき通信が、先に兜底ポリシーへ吸い取られてしまい、以降に書いたすべての細分化ルールが実質無効になります。MATCH が出現した時点で、それ以降のルールは絶対に実行されないと考えれば、これが最終行にしかなり得ない、そして必ず最終行にしなければならない理由がわかります。

確認方法

ルール一覧を書き終えたら、上から下まで一度読み通し、「範囲が広いルール」が「範囲は狭いが個別対応が必要なルール」より前に来ていないかを確認し、最後に MATCH が単独で最終行にあることを確認してください。

五、そのまま使える並び順の目安

以上の仕組みを踏まえると、整理された構成のルール一覧は「先に厳密、後で広範囲、最後に兜底」という並び順に従うのが基本で、おおよそ5段階に分けられます:

  1. LAN・プライベートアドレスの直接接続:IP-CIDR,192.168.0.0/16,DIRECT,no-resolve のように、内部ネットワークの通信がプロキシを経由しないようにします。
  2. 特定アプリ・ポートの個別ルール:個別制御したい PROCESS-NAME や DST-PORT ルールなど。
  3. 重点的に扱いたいドメインルール:よく使うサービスの DOMAIN-SUFFIX や DOMAIN ルールで、プロキシか直接接続かを明確に指定します。
  4. ルールセットと地理位置ルール:RULE-SET で参照する大量のルール群、および GEOIP によるローカル通信の兜底処理。
  5. 最終的な兜底:MATCH の1行で、マッチしなかったすべての通信のデフォルトの行き先を決めます。

簡潔な設定例はおおよそ次のようになります:

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
PROCESS-NAME,com.example.updater,DIRECT
DOMAIN-SUFFIX,example.com,Proxy
DOMAIN-KEYWORD,ads,REJECT
RULE-SET,proxy-list,Proxy
GEOIP,CN,DIRECT
MATCH,Proxy

補足すると、ルールセット(RULE-SET)自体も内部の項目順に沿ってマッチ評価が行われます。リスト内での挿入位置も「前段でより厳密なルールが処理済みで、後段でようやくこのルールセットの番になる」という原則に従います。複数のルールセットを同時に参照する場合も、範囲が狭く優先的に効かせたいルールセットを、範囲の広いルールセットより前に置くことをおすすめします。

六、よくある並び順ミスのセルフチェック

実際の運用では、ルールが効かない原因のほとんどは構文ミスではなく、順序の問題です。特によく見られるケースを整理します:

こうした問題を調べる際は、1行ずつ構文の正しさを繰り返し確認するより、rules: リスト全体を印刷または表示して、上から順にマッチの流れを頭の中でシミュレーションする方が効率的です。多くの場合、どの上位ルールが先取りしているのかすぐに特定できます。

クライアントをダウンロード