Clash振り分けルール解説：DOMAIN・GEOIP・MATCHの書き方

ルールの実行順序：マッチしたら即停止

Clashのrulesは上から下に順番に実行されるリストで、各行の基本フォーマットはタイプ,マッチ内容,ポリシーです。クライアントはネットワークリクエストを受け取ると、最初のルールから順に照合していき、マッチした時点で即座に対応するポリシーを適用し、以降のマッチングは行いません。これはルールファイルを理解する上で最も重要な前提であり、「ルールは正しく書いたはずなのに効かない」という問題の多くは、この点を見落としていることが原因です。

例えば、ルールファイルに次の4行があるとします：

- DOMAIN-SUFFIX,example.com,DIRECT
- DOMAIN-SUFFIX,google.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY

www.google.comへのリクエストは、まず1行目をチェックします——example.comにマッチしないためスキップ。次に2行目をチェック——google.comのサブドメインとしてマッチし、命中したため即座にPROXYポリシーが適用されて停止します。その後のGEOIPとMATCHルールはまったく実行されません。

よく使うルールタイプの完全リスト

ガイドページのクイックリファレンス表に載っている最も一般的な6種類以外にも、Clashが実際にサポートしているルールタイプはもっと豊富です。用途別に整理すると以下の通りです：

• DOMAIN：単一の完全なドメイン名を正確にマッチします（サブドメインは含みません）。
• DOMAIN-SUFFIX：ドメインとそのすべてのサブドメインにマッチする、最もよく使われる書き方です。
• DOMAIN-KEYWORD：ドメインに指定したキーワードが含まれていればマッチし、一度で複数のバリエーションのドメインをカバーできます。
• DOMAIN-REGEX：正規表現でドメインをマッチさせます。規則性が強いが個別に列挙しにくいドメインの処理に適しています。
• IP-CIDR / IP-CIDR6：IPv4 / IPv6のアドレス範囲でマッチします。ローカルネットワークの直接接続によく使われます。
• GEOIP：リクエスト先IPが属する国・地域によって振り分けます。例：GEOIP,CN,DIRECT。
• SRC-IP-CIDR：リクエストを発信したローカルの送信元IPでマッチします。複数NICやLAN内の複数デバイスがある場合に送信元別で振り分けるのに適しています。
• PROCESS-NAME：リクエストを発したプロセス名でマッチします。特定のアプリだけに個別のポリシーを指定できます（デスクトップ版でのサポートが良好）。
• MATCH：兜底ルールです。前のルールにマッチしなかったすべてのトラフィックにマッチします。必ずリストの最後の行に置いてください。

Rule Provider：手書き不要、リモートソースに追随して自動更新

1つずつ手動でルールを書くのは現実的ではありません——中国本土のサイトだけで何千ものドメインを一つずつ列挙することは不可能です。rule-providersは、コミュニティやサービス提供者がメンテナンスするリモートホストのルールコレクションを参照するための機能です。ルールの内容はリモートソースに追随して自動的に更新され、ルールリストにたった1行書くだけで参照できます：

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

rules:
  - RULE-SET,reject,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ほとんどのサブスクリプション提供者はすでにこの層を設定済みなので、一般ユーザーはそのまま使えます。デフォルトのルールセットが自分のニーズを満たさない場合（例えば新たに見つかった広告ドメインを追加でブロックしたい場合）にのみ、その前に自分のルールを挿入する必要があります——順序が先のルールが優先的にマッチするためです。

初心者が最もよく犯す3つのルールミス

1. MATCHを最後ではなく中間に書いてしまう

MATCHは兜底ルールです。リストの途中に書くと、それ以降のすべてのルールが実行されなくなります。MATCH自体がすべてのトラフィックにマッチするためです。必ずrulesリスト全体の最後の行に置いてください。

2. カスタムルールをRule Provider参照の後に書いてしまう

自分で書いたルールをサブスクリプション付属のルールセットより優先させたい場合は、必ずRULE-SET参照行の前に置く必要があります。そうしないとサブスクリプションのルールセットが先に命中し、あなたのカスタムルールには永遠に順番が回ってきません。

3. IP-CIDRにno-resolveを付け忘れる

ローカルネットワークのIP範囲にマッチさせる場合は、no-resolveパラメータ（例：IP-CIDR,192.168.0.0/16,DIRECT,no-resolve）を追加することをお勧めします。これはドメインの事前解決を行わないことを意味し、解決処理によって不要なDNSクエリが発生するのを避けられます。

実践例：特定のドメインだけに個別のポリシーを指定する

特定のサイトを、サブスクリプションのルールセットの判定に関係なく常にプロキシ経由にしたい場合は、ルールリストの一番上に1行追加するだけです：

rules:
  - DOMAIN-SUFFIX,example.com,PROXY   # カスタムルールは最初に置く
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - RULE-SET,proxy,PROXY
  - MATCH,PROXY

すべてのRULE-SET参照より前に置かれているため、最初にマッチされ、サブスクリプションのルールセットに先に直接接続や他のポリシーと判定されてしまうことはありません。

最後に

「順序通りにマッチし、命中したら停止する」というこの核心ロジックを理解すれば、残りのルールタイプは単なる語彙の積み重ねに過ぎません。ある用語の意味が分からない場合は、いつでも用語集で確認できます。特定のサイトがなぜ開けないのかを知りたいだけなら、完全ガイドの調査方法の方が、手動でルールを書くよりも速く問題を解決できるかもしれません。