Clash ルール分岐設定の実践:中国国内直結・海外プロキシの書き方とマッチ順序

B-01分岐の基本原理:ルール・プロキシグループ・マッチ順序

Clash の分岐処理は、本質的に「上から下へ1行ずつ照合する」リストです。設定ファイルの rules フィールドは配列になっていて、各行が独立したルールで、ルールタイプ,マッチ対象,ポリシー名 という3段構成で統一されています。通信リクエストが Clash コアに入ると、コアは配列の先頭行から順に照合していき、いずれかのルールにヒットした時点で、そのルールが指定するポリシー(直結・プロキシ・拒否)を即座に適用し、以降のルールはもう照合されません。この「ヒットしたら終了」という仕組みこそが分岐設定を理解する上での核心であり、後述する未マッチ問題を切り込むための鍵にもなります。

ポリシーの欄に書くのは具体的なノードではなく、プロキシグループの名前です。例えば内核に組み込まれた DIRECT(直結)や REJECT(拒否)、あるいは proxy-groups で自分で定義したグループ名(例:海外プロキシ)を指定します。実際にどのノードを使うかはプロキシグループ側で決まり、ルール層が担うのは「どの経路を通すか」だけで、「その経路上の具体的な車両」までは関与しません。この階層構造の利点は、ノードの切り替えや遅延判定ポリシーの調整がプロキシグループの変更だけで済み、ルール自体をいじる必要がない点です。

B-02中国国内直結・海外プロキシの標準的な書き方

中国国内直結・海外プロキシは最も一般的な分岐シーンで、基本的な考え方は次の通りです。まず中国国内に明確に属するドメインと IP セグメントを抽出して直結にし、次に海外またはプロキシ経由が必要と明確なドメインをプロキシに振り、最後に受け皿ルールを1本置いて残り全ての通信をいずれかのポリシー(通常はプロキシグループ)にまとめ、漏れを防ぎます。

実践では主に3種類のルールを使います。

• DOMAIN-SUFFIX:ドメインの末尾でマッチさせる方式で、ドメインが既知のサイトに向いています。例えば DOMAIN-SUFFIX,google.com,海外プロキシ は google.com とそのすべてのサブドメインにマッチします。
• GEOIP:接続先 IP の地理的な所属でマッチさせる方式で、ドメインに規則性がないもの、あるいはサーバーの所属地域が明確な通信に向いています。例えば GEOIP,CN,DIRECT は、接続先 IP が中国大陸に属する場合に直結する設定です。
• RULE-SET:事前に整理されたルールセットファイル(ローカルまたはリモート)を参照する方式で、何千・何万というドメイン/IP ルールを1つの参照にまとめられるため、ルールファイル自体が長く煩雑になるのを防げます。

最も基本的な中国国内直結・海外プロキシのルール部分は、おおむね次のようになります。

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-SUFFIX,baidu.com,DIRECT
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,google.com,海外プロキシ
  - DOMAIN-SUFFIX,youtube.com,海外プロキシ
  - DOMAIN-SUFFIX,github.com,海外プロキシ
  - GEOIP,CN,DIRECT
  - MATCH,海外プロキシ

このルールのロジックは以下の通りです。まず明確に直結させたい、あるいは明確にプロキシさせたいドメインをいくつか個別に処理し、続いて GEOIP,CN,DIRECT で接続先サーバーが中国大陸にある通信をまとめて受け止め、最後に MATCH,海外プロキシ で前段のいずれのルールにもマッチしなかった通信をすべてプロキシグループへ流します。実際の運用では、手書きの DOMAIN-SUFFIX 項目は RULE-SET によるルールセット参照に置き換えられることが多く、数十件のドメインを手動で維持するより、継続的に更新されるルールセットを参照する方がはるかに手間がかからないためです。

B-03RULE-SET でルールセットを参照する書き方

RULE-SET は2段階で設定します。まず rule-providers フィールドでルールセットの名前・取得元・更新周期を宣言し、続いて rules 内で RULE-SET,ルールセット名,ポリシー名 の形式で参照します。例は次の通りです。

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

rules:
  - RULE-SET,cn-domain,DIRECT
  - RULE-SET,proxy-domain,海外プロキシ
  - GEOIP,CN,DIRECT
  - MATCH,海外プロキシ

behavior フィールドはルールセットファイルの実際の内容に対応させる必要があり、よく使われるのは次の3種類です。domain はファイルがドメインリストであることを示し、ipcidr はファイルが IP セグメントのリストであることを示し、classical はファイルに完全なルール文(各行に種別のプレフィックスが付いたもの)が混在していることを示します。behavior の設定ミスは、ルールセットが効かなくなる原因として非常によくあるパターンです。内核は宣言された behavior に基づいてファイル形式を解釈するため、これが一致しないとルールセットは実質的に空ファイルと同等になりますが、必ずしも明確なエラーが出るわけではありません。

B-04ルールの順序が結果を左右する理由:実際に起こりやすいミスの例

ルールの順序は書式上の慣習ではなく、分岐結果を直接左右する論理構造そのものです。以下のミスが起こりやすい書き方を見てみましょう。

rules:
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,google.com,海外プロキシ
  - MATCH,海外プロキシ

この設定では GEOIP,CN,DIRECT が最上部に置かれています。問題は、CDN で配信されている海外サイトの一部では、あるアクセスノードの IP がたまたま中国大陸の CDN ノードに当たっていることがあり、逆に中国国内の一部サービス事業者が海外にもアクセラレーションノードを配置していることもある点です。GEOIP が判定しているのは「この接続が実際に到達した IP の所属地域」であり、「そのサイトの運営主体がどこに属するか」ではありません。GEOIP,CN,DIRECT が DOMAIN-SUFFIX より前に置かれていると、google.com へのアクセスがたまたま GEOIP データベース上で中国大陸とマークされた IP に解決された場合、本来効くはずの下にある DOMAIN-SUFFIX ルールに到達する前に直結ルールに先に捕まってしまい、そのリクエストが直結扱いになって接続失敗や通信の汚染を招くことになります。

正しい順序の原則は、より精確で具体的なルールをより前に置き、大まかな受け皿的な判定を後方に置くことです。ドメイン系のルールは通常 GEOIP より精確です。なぜならドメインはサイトの身元を示す識別子であり、CDN のスケジューリングによって変わることがないからです。GEOIP はドメインルールの後方に置き、ドメインルールでカバーされていないが IP の所属地域で簡単に判定できる残りの通信を処理する専用として使うのが適しています。先の例で DOMAIN-SUFFIX / RULE-SET を前方に、GEOIP を中間に、MATCH を最後に置いているのは、まさにこの原則を体現したものです。

B-05MATCH 受け皿ルール:必ず書き、必ず最後に置く

MATCH は特殊なルールで、マッチ対象を指定する必要がなく、「前段のどのルールにもマッチしなかった通信を、すべてここで指定したポリシーで処理する」という意味を持ちます。これは必ずルールリストの最終行でなければならず、そうでない場合は次の2つの問題が起こります。MATCH を書き忘れると、どのルールにもマッチしない通信は内核のデフォルト挙動に従って処理されます(クライアントによってデフォルト挙動は異なり、直結になるものと拒否になるものがあります)。動作を予測できません。一方、MATCH が最後になっていない場合、それより後ろのルールは永久に実行されません。MATCH 自体がどんな通信にも必ずマッチしてしまうためです。

1. ルールファイルの最終行が MATCH,ポリシー名 になっているか確認してください。
2. MATCH の後に他のルール行が続いていないことを確認し、あれば削除するか前方へ移動してください。
3. MATCH で指定するプロキシグループが存在し、実際に接続できることを確認してください。個別のノードを直接指定するより、海外プロキシグループを指すことを推奨します。そうすればそのノードが失効した場合でも受け皿ルールまで無効になることを防げます。

B-06よくある書き方のミスと未マッチ調査チェックリスト

ルールが効かない、あるいは分岐結果が想定と違うといった問題は、たいてい以下のいずれかの原因に絞られます。順番にセルフチェックすれば、大抵は問題箇所を特定できます。

この中で「プロキシグループ名の表記不一致」は最も見落とされやすいミスです。多くのクライアントは設定を読み込む際、ポリシー名が存在しなくてもエラーを直接出さず、そのルールを黙って無効扱いにするため、「見た目は設定に問題がないのに分岐が効いていない」という状態になります。ルールを変更した後は具体的な URL で1つずつ検証する習慣をつけたほうが、後から原因を調査するより結果的に時間の節約になります。

B-07分岐設定が想定通りに効いているか検証する

ルールを書き終えたら感覚だけで判断せず、以下の方法で1つずつ検証することを推奨します。

• クライアントの接続ログやルールヒット履歴で、対象サイトにアクセスした際に実際にどのルールにマッチし、どのプロキシグループを通ったかを確認します。多くの GUI クライアントでは「ログ」や「接続」パネルからこれを確認できます。
• 中国国内サイトと海外サイトそれぞれで代表的なドメインを2〜3個ずつ選んでテストしてください。1つのサイトだけでテストして結論を出すのは避けましょう。個別のサイトには CDN 特有の事情がある場合があるためです。
• ルールセット参照系の設定は、初回に効くようになる前に、ルールセットファイルのダウンロードが成功していること、ローカルキャッシュが空ファイルになっていないことを確認してください。