Clash 通信振り分け設定実践:国内外振り分けの記述ルールとマッチ順序

振り分けの目標:国内は直接接続、海外はプロキシ経由

Clash の基本動作はルールベースの転送です。Clash を通過するすべての接続は、宛先アドレスを持ってルールリストと1件ずつ照合され、最初にマッチしたルールで指定された出口へ送られます。国内外振り分けとは、要するに「どの通信を直接接続にし、どの通信をプロキシに回すか」を、正しい順序で並んだルールリストに落とし込む作業です。

ルールの出口は3種類だけです。DIRECT は直接接続で、宛先アドレスに端末のネットワークから直接アクセスします。REJECT は接続を拒否するもので、遮断用途に使います。3つ目はプロキシノードまたは策略グループの名前で、プロキシ経路に転送を委ねます。

国内外振り分けで目指す結果ははっきりしています。国内サイトは直接接続にして低遅延・ノードの通信量を消費しない状態にし、海外サイトはプロキシ経由にする。明確に通したくないリクエストは拒否する。これを実現するには3つだけあれば十分です——国内外のアドレスを網羅したルール、ノードを指す策略グループ、そして正しい並び順。以下でひとつずつ分解して説明します。

ルールタイプ:各ルールが照合している対象

ルールの記述形式は「タイプ,パラメータ,出口」で、3項目を半角カンマで区切ります。タイプによって、リクエストと何を比較するかが決まります。よく使うタイプは下表の通りです。

ルールタイプ	マッチ対象	記述例	説明
`DOMAIN`	完全一致ドメイン	`DOMAIN,example.com,PROXY`	そのドメイン自体のみにマッチし、サブドメインは含まない
`DOMAIN-SUFFIX`	ドメインサフィックス	`DOMAIN-SUFFIX,example.com,PROXY`	メインドメインと全サブドメインにマッチする、最も一般的な書き方
`DOMAIN-KEYWORD`	ドメインキーワード	`DOMAIN-KEYWORD,example,PROXY`	ドメインに該当文字列が含まれるだけでマッチするため誤爆しやすく、使用には注意が必要
`GEOSITE`	ドメイン分類セット	`GEOSITE,cn,DIRECT`	1行でドメインの分類全体をカバー、mihomo カーネルが必要
`IP-CIDR`	宛先 IP レンジ	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	サブネット単位でマッチ、LAN や固定アドレス帯に適する
`GEOIP`	宛先 IP の所属国	`GEOIP,CN,DIRECT`	IP データベースで国・地域を判定、振り分けのフォールバックに使用
`DST-PORT`	宛先ポート	`DST-PORT,853,DIRECT`	ポート単位で振り分け、単一ポートで動くサービスに適する
`PROCESS-NAME`	発信元プロセス名	`PROCESS-NAME,chrome.exe,PROXY`	プロセス単位で振り分け、デスクトップ環境で利用可能
`MATCH`	すべてのリクエスト	`MATCH,PROXY`	ルールリストの末尾に置くフォールバック出口、必ず最後に配置する

選び方の基本感覚はシンプルです。ドメインサフィックスで済むならキーワードは使わない、GEOSITE の分類が使えるなら DOMAIN-SUFFIX を何百行も並べない、IP 系ルールはドメイン系ルールの後ろに置いて国別判定のフォールバックとして使う。DOMAIN-KEYWORD は最も誤爆しやすいタイプで、短いキーワードが国内サイトのサブドメインにも同時にマッチしてしまうことがあるため、対象が非常に明確でない限り国内外振り分けのメインリストには入れません。

カーネルの違い

GEOSITE は Clash Meta / mihomo カーネルの機能で、対応する geodata ファイルに依存します。無印 Clash 環境では DOMAIN-SUFFIX、ルールセット、GEOIP の組み合わせで代用してください。カーネルを切り替える前に、クライアントの「バージョン情報」ページでカーネル名を確認し、記述方法を決めましょう。

マッチ順序:最初にマッチした時点で停止

Clash は rules リストを上から下へ照合し、最初にマッチしたルールで停止します。それ以降のルールは判定に参加しません。つまり順序はレイアウト上の習慣ではなく、振り分け結果そのものを決めるものです。国内外振り分けの安定した順序は次の通りです:自端末・LAN の直接接続 → 明確に拒否したい対象 → 国内ドメインの直接接続 → 国内 IP の直接接続 → 残り全部をプロキシへ。

まず自端末、LAN、予約アドレス帯を通してあげます。ルーター、NAS、プリンターなどの通信がプロキシに送られないようにするためです。
次に明確な遮断ルールを置きます。既知のトラッキングドメインや通したくないサービスなどです。遮断ルールは前に置くほど、後続の解析処理を減らせます。
続いて国内ドメインの集合を置きます。GEOSITE,cn の1行で大量のドメインをまとめて処理できます。GEOSITE が使えない環境では、メンテナンスされているドメインルールセットで代用します。
その次に GEOIP,CN,DIRECT を置きます。ドメイン集合でカバーできなかったものの、解析結果が中国の IP になる対象を受け止めます。
最後に残すのは MATCH,PROXY の1行だけです。国内ルールにマッチしなかったすべてのリクエストが、まとめてプロキシ策略グループに入ります。

no-resolve は IP 系ルールにのみ影響します。これを付けると、Clash はそのルールにマッチさせるためにドメインを能動的に IP へ解析しません。よくある書き方は、LAN のセグメントには必ず no-resolve を付けることです。GEOIP,CN に no-resolve を付けるかどうかは、ドメインルールのカバー率次第です。ドメイン集合が十分に網羅されている場合は GEOIP,CN,DIRECT,no-resolve と書いて余計な解析を減らせます。ドメイン集合がやや古い場合は解析機能を残したほうが安定しますが、その際は正しい DNS の流れと組み合わせ、解析自体がプロキシ経路を回避しないよう注意する必要があります。

順序ミスによる事故

MATCH,PROXY をリストの途中に誤って置くと、それ以降の国内直接接続ルールがすべて無効になります。GEOIP,CN を GEOSITE,cn より前に置くと、本来ドメインで直接接続できたはずの大量のリクエストが先に IP 所属国の判定を受けてしまいます。症状はどちらも同じで、国内サイトがノード経由に送られ、遅延とノードの通信量が同時に増えます。

策略グループの組み合わせ:出口は名前しか見せない

ルール内で特定のノード名を直接書き込むのはおすすめしません。策略グループ名を書くようにします。これによりノードの切り替え、速度テスト、バックアップ出口の追加を行っても、ルールリスト自体は変更不要になります。国内外振り分けには最低でも2つのグループが必要です:手動選択用の PROXY と、自動速度テスト用の AUTO です。

策略グループタイプ	動作	適用箇所
`select`	クライアント上で出口を手動選択	メイン出口グループ、最終決定の配置に適する
`url-test`	定期的に速度テストし、最も遅延の低いノードへ自動切り替え	select グループの中に組み込み、自動選択の1項目として使う
`fallback`	順番に検査し、障害時は次に使えるノードへ切り替え	最低遅延より可用性を重視する場面
`load-balance`	策略に従って接続を複数ノードに振り分け	マルチライン負荷分散、デフォルトのトラブル対応窓口には不向き

推奨構成は、PROXY を select にして候補に AUTO・各ノード・DIRECT を入れ、AUTO を url-test にして実際に使えるプロキシノードのみを入れることです。ルールは統一して PROXY を指し、クライアント側で自動または手動ノードに切り替えてもグループ内選択の変更だけで済み、ルールは変更しません。

そのまま使える設定例

以下は最小構成の骨格で、proxy-groups と rules の対応関係に注目してください。ノードは明らかにダミーの値で、フィールド位置の確認用です。サブスクリプションを使う場合、ノードとグループはサブスクリプション変換やオーバーライド機構に管理を委ね、変換結果を手動で編集すると次回の更新で上書きされます。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

proxies:
  - name: "サンプルノード-使用禁止"
    type: ss
    server: node1.example.invalid
    port: 443
    cipher: aes-128-gcm
    password: "demo-pass-000"

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - サンプルノード-使用禁止
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - サンプルノード-使用禁止
    url: http://example.invalid/generate_204
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,localhost,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,169.254.0.0/16,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

クライアントでサブスクリプションを使っている場合は、まず「オーバーライド / Mixin / 設定パッチ」機能を探し、上記の rules の順序の考え方をサブスクリプション生成ルールの前か後に組み込んでください。クライアントが更新ごとに再構築する最終的な設定ファイルを直接編集してはいけません。遮断が必要な場合は、GEOSITE,cn の前に独立した REJECT ルールまたはルールセットを挿入し、国内直接接続ルールの連続性を保ちます。

判定基準

この設定がうまくいっている証は「ネットに繋がる」ことではなく、接続パネル上で国内の対象が GEOSITE,cn または GEOIP,CN にマッチし出口が DIRECT になっていること、海外の対象は MATCH のみにマッチし出口が PROXY グループ内で現在選択中のノードになっていることです。

振り分け結果の確認方法

確認は3段階で行い、順序を逆にしないことが大切です。1段目はモードの確認です。クライアントがルールモードになっていて、システムプロキシまたは TUN が通信を引き継いでいるか確認します。ブラウザ拡張のプロキシやアプリ内プロキシは Clash を経由しないため、まず除外してください。2段目はマッチ結果の確認です。クライアントの接続一覧またはログ画面を開き、国内向けと海外向けのリクエストを1回ずつ発生させ、各接続の右側に表示されるルールチェーンと出口を、ページの表示速度などの感覚ではなく実際の表示で確認します。3段目はコマンドラインでの確認です。明示的にプロキシを指定してリクエストを送り、通信が実際に Clash のポートを通っているか確かめます。

curl -x http://127.0.0.1:7890 -I https://対象ドメイン/

コマンドラインで分かるのは、リクエストが Clash に入ったという事実だけです。どちらに振り分けられたかは、接続パネルの rule と chains の項目で確認してください。国内向けリクエストは直接接続チェーンを表示し、海外向けリクエストはノードチェーンを表示するはずです。海外向けリクエストが DIRECT と表示される場合は、より前段にある DOMAIN-SUFFIX やキーワードのルールが誤マッチしている可能性が高いです。国内向けリクエストがノードに入ってしまう場合は、MATCH の位置が前すぎないか、GEOSITE のデータが欠けていないか、クライアントが実際には無印カーネルで動いていないかを優先的に確認してください。

TUN モードや拡張 DNS モードを有効にしている場合は、システムの通信が実際に Clash の仮想ネットワークアダプタを経由しているかも確認してください。そうでなければ、ルールがいくら正しくても、手動でプロキシを設定したアプリにしか効果が及びません。トラブル対応時はまず TUN を切り、システムプロキシでルールを検証してから TUN を再度有効にすると、「ルールの問題」と「通信引き継ぎの問題」を分けて確認できます。

よくあるミス一覧

ルール順序の逆転:フォールバックルールを前段に置くと、それ以降の細かいルールがすべて無効になります。保存前に rules の先頭部分と末尾部分だけでも確認しておくと、大半の事故は防げます。
キーワードの誤爆:DOMAIN-KEYWORD のマッチ範囲が広すぎて国内サイトまでプロキシに引き込まれる場合、DOMAIN-SUFFIX に変更するか GEOSITE の分類に任せます。
ルールにノード名を直接記述:サブスクリプション更新でノード名が変わるとルールがそのまま無効になります。ルールは策略グループ名だけを参照させます。
GEOIP 単独で振り分けを支える:GEOIP,CN だけに頼ると CDN や海外ミラーを取り逃がします。ドメイン集合と IP 所属判定を併用しましょう。
サブスクリプション生成物の手動編集:更新時に上書きされ、設定が「勝手に元に戻る」現象として表れます。カスタム部分はオーバーライド機能で管理しましょう。
IPv6 の見落とし:端末側で IPv6 が使える状態なのに設定で無効・未設定のままだと、一部のリクエストがシステムのネットワークを直接通ってしまいます。カーネル側とシステム側の両方で有効にして IP-CIDR6 ルールを補うか、明確に無効化してください。

ルールは道しるべのように保守しましょう。1行につき行き先はひとつだけ、順序は具体的なものからフォールバックの順に並べます。国内直接接続、海外プロキシ、異常時の遮断、この3つがそれぞれ正しい位置にあれば、以後のノード変更、クライアント変更、ルールセット追加は局所的な差し替えで済み、設定全体を書き直す必要はありません。