Clash 分流ルールの優先順位を徹底解説:DOMAIN と IP-CIDR カスタムルールの書き方

ルール判定の基本原則:上から下へ、一致したら即終了

Clash の分流エンジンは接続要求を処理する際、rules フィールドに列挙された順序で1件ずつ条件を照合し、いずれかのルールの条件が要求に一致した時点で、そのルールが指定する策略グループまたはプロキシノードを即座に採用し、以降のルールは一切評価されません。つまりルールの並び順そのものが優先順位を決めており、ルールの種類とは無関係です──前に書かれた DOMAIN-KEYWORD が後に書かれた GEOIP を上書きすることもあれば、逆のパターンも同様に成立します。

この仕組みからは2つの直接的な結果が生まれます。第一に、リストの前方に置くルールほど、カバー範囲が狭く判定条件が明確なケース(特定ドメインの直接接続や拒否など)であるべきで、後方に置くルールほど、国・地域単位で分流する GEOIP や最終的な MATCH のような広い受け皿ルールであるべきです。第二に、カスタムルールを追加する際は、挿入位置によってそのルールが前方の既存ルールに先取りされて無効化されるかどうかが決まります──「ルールを書いたのに反映されない」という問題の多くは、記述ミスではなく順序の問題が原因です。

NOTE / 補足

Clash Meta(mihomo)もルールエンジンのロジックは Clash と同じで、上から下へ、一致したら即終了という点は変わりません。違いは主に対応するルール種別が豊富であること(PROCESS-NAME、RULE-SET、論理ルール AND/OR/NOT など)にあり、並び順に関する基本原則は影響を受けません。

よく使うルール種別と記述形式

ルール行の一般的な形式は 種別,マッチ内容,策略 であり、策略には具体的なノード名を指定することも、策略グループ名(PROXY、DIRECT、REJECT など)を指定することもできます。以下は日常的な設定で最もよく使われる種類です。

DOMAIN 系:ドメイン名によるマッチ

DOMAIN:完全なドメイン名に厳密一致します。そのドメイン自体のみに一致し、サブドメインは含みません。
DOMAIN-SUFFIX:ドメインのサフィクスに一致し、そのすべてのサブドメインも自動的にカバーします。最もよく使われるドメインルールです。
DOMAIN-KEYWORD:ドメイン名に含まれるキーワードに一致します。カバー範囲が最も広く、無関係なドメインを誤って拾いやすいルールです。

DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,analytics,REJECT

上記の3行が同時に存在する場合、api.example.com は1行目と2行目の両方に一致しますが、1行目が先に置かれているため、api.example.com は DIRECT となり、example.com の他のサブドメインは2行目の PROXY によって処理されます。これは「カバー範囲の狭いルールを前に置く」という典型的な例です。

IP-CIDR と IP-CIDR6:IPアドレス帯によるマッチ

対象がドメイン名ではなく既知の IP アドレス帯(内部ネットワークのアドレス、固定の CDN 折り返し先、既知のサービス事業者の IP 帯など)である場合には IP-CIDR を使用します。このルールは既定では接続先の IP のみに対して有効ですが、サーバーが解決したすべての A/AAAA レコードを判定対象に含めたい場合は避け、多くのコアでは no-resolve オプションによって余分な解析コストを省くことができます。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve

CAUTION / 注意

no-resolve を付けない場合、Clash はドメイン名を先に DNS で解決してから IP アドレス帯と照合するため、マッチごとに解析コストが加わります。内部ネットワークのアドレス帯のように明らかに解析が不要なルールには、常に no-resolve を付けることを推奨します。

GEOIP:国・地域単位の分流

GEOIP は対象 IP が属する国・地域コードに基づいて判定を行い、「日本国内の IP は直接接続、海外の IP はプロキシ経由」といった粗い分流によく使われます。判定根拠が国・地域全体の IP データベースであるため、カバー範囲が最も広く、通常はルールリストの末尾に近い位置に置きます。

GEOIP,CN,DIRECT
GEOIP,PRIVATE,DIRECT

RULE-SET とルールセット:まとめて管理する分流断片

Clash Meta(mihomo)は rule-providers フィールドによる外部ルールセットの読み込みに対応しており、設定内では RULE-SET で参照します。ある種のサイト群(動画配信、広告ドメインリストなど)を一括で管理し定期的に更新でき、1行ずつ手書きする必要がありません。

rule-providers:
  ads-reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/ads.txt"
    path: ./rule-providers/ads-reject.yaml
    interval: 86400

rules:
  - RULE-SET,ads-reject,REJECT

MATCH:受け皿ルール

MATCH は前方のいずれのルールにも処理されなかったすべての接続に一致し、ルールリストの最終行に置く必要があります。分流表全体の受け皿となる出口であり、後から切り替えやすくするため通常は固定ノードではなく策略グループを指定します。

MATCH,PROXY

ルールの配置順序の考え方:ルール同士の競合を避けるには

上記のルール種別を1つの設定にまとめる場合は、「マッチ範囲の狭いものから広いもの」の順に上から下へ配置することを推奨します。おおむね4層に分けられます。

厳密な例外層:DOMAIN と内部ネットワークの IP-CIDR。個別に策略を指定する必要がある具体的なアドレスを処理します。例えば内部管理画面は直接接続、既知の悪質ドメインは即座に拒否といったケースです。
ドメイン分類層:主に DOMAIN-SUFFIX を使い、業務ごと(SNS、動画、開発ツールなど)にグループ化して対応する策略グループへまとめます。
ルールセットとキーワード層:RULE-SET や DOMAIN-KEYWORD はカバー範囲が広いため、ドメイン分類層の後に置き、キーワードルールが本来精密に一致すべきドメインを先取りしてしまわないようにします。
地域と受け皿層:GEOIP で残りの国・地域分流を処理し、MATCH を最終行に置いて締めます。

下表はこの並び順における代表的なルールの出口方向をバッジで示したもので、設定が想定どおりかを確認する際に役立ちます。

DOMAIN-SUFFIX,cn: DIRECT
DOMAIN-SUFFIX,googlevideo.com: PROXY
DOMAIN-KEYWORD,ad: REJECT
GEOIP,CN: DIRECT
MATCH: PROXY

NOTE / 補足

あるカスタムルールを追加しても反映されない場合は、まずその上方に同じ対象を先取りしてしまう、より広範なルールが既に存在していないかを確認しましょう。これが順序の問題を突き止める最も手早い方法で、構文を何度も見直すより効率的です。

実践例:カスタム分流の断片と配置位置

「ある開発環境のドメインだけを直接接続にしつつ、既存の広告ブロックと地域分流はそのまま残す」という例で考えてみます。新しいルールは広告ブロックルールより前、かつドメイン分類層より後に挿入すべきです。理由は、この例外ルールのマッチ範囲が DOMAIN-KEYWORD よりも精密であり、優先して判定する必要があるためです。

rules:
  # 厳密な例外層
  - DOMAIN,192-168-1-1.local,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

  # 追加:開発環境ドメインの直接接続(キーワードルールより前に挿入)
  - DOMAIN-SUFFIX,dev.internal-project.com,DIRECT

  # ドメイン分類層
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,googlevideo.com,PROXY

  # ルールセットとキーワード層
  - RULE-SET,ads-reject,REJECT
  - DOMAIN-KEYWORD,analytics,REJECT

  # 地域と受け皿層
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この新規ルールを誤って MATCH の近くに置いてしまうと、その前方にすでにカバー範囲の広いキーワードルールや地域ルールが存在するため、新しいルールはほとんど実行されず、「設定は保存されたのに通信の流れが変わらない」という状態になります。

もう一つよくある要件は、特定の IP アドレス帯を直接接続ではなく拒否にすることです。例えば既知の探索用サーバー群をブロックするケースです。

rules:
  - IP-CIDR,203.0.113.0/24,REJECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この IP-CIDR,REJECT は GEOIP,CN,DIRECT より前に置く必要があります。そうしないと、そのアドレス帯がたまたま国内 IP と判定された場合、先に GEOIP ルールに一致して直接接続となり、拒否ルールが決して発火しなくなってしまいます。

ルールが反映されないときの調査手順

カスタムルールが想定どおりに反映されない場合は、すぐに構文ミスを疑うのではなく、以下の順序で調査することを推奨します。

配置位置を確認する:追加したルールの上方に、カバー範囲が広く先に一致してしまうルールがないかを確認します。これが最もよくある原因です。
ルール種別と記述形式を確認する:DOMAIN-SUFFIX にはワイルドカードの接頭辞は不要です(*.example.com のように書かない)。純粋なドメインサフィクス example.com として記述します。
策略グループ名が存在するか確認する:ルール末尾の策略名は、proxy-groups で定義したグループ名や具体的なノード名と完全に一致している必要があります。表記ミスがあると、コアが設定読み込み時にエラーを出す、あるいはその行を無視することがあります。
DNS 層での分流の影響を確認する:fake-ip やカスタムの nameserver-policy を有効にしている場合、ドメインがルールエンジンに到達する前に DNS 側の分流の影響を受けている可能性があります。rules だけでなく DNS 設定のセクションも併せて確認してください。

STOP / 警告

DOMAIN-KEYWORD を DOMAIN-SUFFIX の代替として濫用しないでください。キーワードルールはドメイン構造を区別しないため、同じ文字列を含む無関係なドメインを誤って拾いやすくなります(例えばキーワード ad は adobe.com にも一致します)。想定外の接続を調査する際は、まずこの種の広範なルールが前方に置かれすぎていないかを確認しましょう。