Clashの国内外トラフィック分流ルール設定実践：ドメインルール、GEOIP、フォールバック戦略

まず目的を決める：中国本土は直接接続、海外はプロキシグループへ

Clashのルールモードは、サイトが「中国国内」か「海外」かを先に判定して自動的に出口を選ぶ仕組みではありません。実際には上から順に並んだルール表を処理し、新しい接続は順番に照合され、最初に一致した時点で停止します。その後、指定されたプロキシグループ、プロキシノード、または DIRECT に処理が渡されます。つまり、分流結果を左右するのはまずルールの順序であり、次にルールデータベースの網羅性とノードの状態です。

この記事では、そのまま導入できる目標として、LANと明確な中国本土向けドメインは直接接続し、プロキシが必要な既知のドメインは「海外トラフィック」プロキシグループへ送り、残りはGEOIPで判定し、最後にMATCHで一括処理します。例ではmihomo v1.19系がサポートする標準的なルール構文を基準にしており、Clash YAML設定を読み込める多くのGUIクライアントでも利用できます。

トラフィックの種類	推奨アクション	主なルール	配置位置
本体およびLANアドレス	DIRECT	IP-CIDR	最上部
プロキシを強制するドメイン	海外トラフィック	DOMAIN、DOMAIN-SUFFIX	中国本土ルールの前
明確な中国本土向けドメイン	DIRECT	DOMAIN-SUFFIX	中ほど
中国本土のIPに解決されるアドレス	DIRECT	GEOIP,CN	末尾近く
どのルールにも一致しない接続	海外トラフィック	MATCH	最後の1行

ルール構文：DOMAIN、DOMAIN-SUFFIX、IP-CIDR

完全一致ドメインとドメインサフィックス

DOMAIN は完全なホスト名1つだけに一致します。たとえば DOMAIN,api.example.com,海外トラフィック は api.example.com に一致しますが、www.example.com には一致しません。単独のAPIドメイン、更新サーバー、汎用ルールより優先したい特定ホストの指定に適しています。

DOMAIN-SUFFIX は指定したドメインと、その下位サブドメインに一致します。DOMAIN-SUFFIX,example.com,海外トラフィック なら、example.com、www.example.com、api.eu.example.com をまとめて対象にできます。運用上、サフィックスルールはホスト名を1件ずつ列挙するより簡潔ですが、対象範囲も広くなります。1つのAPIを処理するために、サービス全体のドメインをプロキシ経由にしないよう注意してください。

rules:
  - DOMAIN,api.example.com,海外トラフィック
  - DOMAIN-SUFFIX,wikipedia.org,海外トラフィック
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT

ルール内のプロキシ名は、proxy-groups に存在する名前と完全に一致させる必要があります。プロキシグループが「ノード選択」という名前なら、ルール末尾にも「ノード選択」と記述し、「海外トラフィック」とは書けません。名前が異なっても自動変換されず、設定チェックでプロキシが見つからないと報告されます。

LANアドレスはIP-CIDRで先に直接接続する

ルーターの管理画面、NAS、プリンター、ローカル開発サービスには、通常プライベートアドレスが使われます。これらを上位に置くと、192.168.1.1 や 10.0.0.20 などの機器へのアクセスがリモートプロキシへ送られるのを防げます。IPv4でよく使われるプライベートネットワークは 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 です。

rules:
  - 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

no-resolve は、対象IPネットワークとの一致時に、ドメインに対する追加の名前解決を行わないことを示します。明確なプライベートアドレスのルールでは、不要なDNS問い合わせを減らせます。DNS自体を無効にする設定ではなく、すでに取得済みの宛先IPも変更しません。

GEOIP,CNの役割と限界

GEOIP,CN,DIRECT は、宛先IPの地理情報データベース上の所属に基づいて判定します。接続先がすでにIPアドレスの場合、またはルール照合のためにカーネルがドメインを解決した場合、そのIPがデータベースでCNに分類されていれば直接接続します。広範囲の中国本土向け通信を直接接続する補助ルールとして便利ですが、すべてのドメインルールを置き換えるものではありません。

ドメインの所属地域と、サーバーIPの所属地域は必ずしも一致しません。中国本土向けのサービスが海外CDNノードを使うこともあれば、海外サービスが中国本土にあるエッジノードから静的リソースを配信することもあります。GEOIPデータには更新間隔もあるため、データセンターの移転直後やアドレス帯の再割り当て直後は分類が不正確な場合があります。安定性が重要なサービスはDOMAINまたはDOMAIN-SUFFIXで方向を明示し、GEOIPはドメインルールの後ろで補完に使うのが基本です。

GEOIPにno-resolveを付けるか

次の2通りでは結果が異なる場合があります。

- GEOIP,CN,DIRECT
- GEOIP,CN,DIRECT,no-resolve

1つ目は、必要に応じてカーネルがドメインを解決し、IPを取得して地理判定できる書き方です。2つ目は、このルールによる追加の名前解決を抑止します。中国本土向けドメインを十分にカバーするルールセットが前にある場合、GEOIPに no-resolve を付けることで、ルール照合時の名前解決を減らせます。一方、手作業で登録したドメインルールが少ない状態で早くから no-resolve を使うと、未登録の中国本土向けドメインがMATCHに流れ、最終的にプロキシ経由になる可能性があります。

実際の設定では、まず no-resolve なしで試し、接続ログとDNS遅延を確認するとよいでしょう。テスト環境で、キャッシュされていないドメイン20件へ初回アクセスを連続して行った場合、追加の名前解決によって通常は数ミリ秒から数十ミリ秒の待ち時間が発生します。具体的な値は、ローカルDNS、ネットワーク距離、キャッシュヒット率によって変わります。GEOSITEやrule-providerで十分にカバーできている場合は、ログを見ながらGEOIPの名前解決を減らすか判断してください。

GEOIPデータはカーネルのリソース更新に合わせて更新する

mihomoは通常、GeoIPデータファイルを使ってアドレスの所属地域を判定します。GUIクライアントでは、カーネル更新、設定リソース更新、またはデータベース単独の更新メニューからファイルを管理する場合があります。よく使う中国本土のIPが大量にフォールバック先へ誤分類される場合は、ルール順序だけでなく、GeoIPファイルが正常に読み込まれているかも確認してください。ログにリソースファイルの欠落、解析失敗、データベース形式の非互換が出ているなら、DOMAIN-SUFFIXを追加しても局所的な回避にしかならず、地理ルール自体は修復できません。

MATCHのフォールバック：最後の1行が未知の通信の出口を決める

MATCH は、それまでに一致しなかったすべての接続を受け取るため、ルールリストの末尾に置く必要があります。中国本土は直接接続、海外はプロキシという一般的な構成では MATCH,海外トラフィック とし、所属地域を確認できない宛先をデフォルトでプロキシグループへ送ります。ルールデータベースにまだ登録されていない新しいドメインにも対応しやすく、プロキシグループ内でノードを切り替えられる点も利点です。

MATCH,DIRECT と書くと、未登録の海外ドメインも直接接続されます。「通常は直接接続し、一部のサービスだけプロキシを使う」用途には適していますが、この記事の目標には合いません。どちらの設計でも動作しますが、違いはMATCH自体の優先順位ではなく、未知の通信をどの出口へ送るかにあります。

読みやすい完全なルール順序

以下の例では、設定内に「海外トラフィック」という名前のプロキシグループがすでに存在すると仮定しています。ノードの認証情報やサブスクリプション情報は含まれていないため、クライアントのルールオーバーライド領域に追加できます。

mode: rule
mixed-port: 7890
log-level: info

rules:
  - 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

  - DOMAIN-SUFFIX,wikipedia.org,海外トラフィック
  - DOMAIN-SUFFIX,githubusercontent.com,海外トラフィック

  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT
  - DOMAIN-SUFFIX,jd.com,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT

  - GEOIP,CN,DIRECT
  - MATCH,海外トラフィック

mode: rule はルールモードを有効にし、mixed-port: 7890 は一般的なHTTPおよびSOCKSのインバウンド接続を同時に受け付けます。クライアントがポートを管理している場合は、画面設定との競合を避けるため、オーバーライドで重複指定する必要はありません。Clash Verge Rev 2.3.xでは、「設定」→「Clash設定」で現在のポートと動作モードを確認できます。バージョンによってグループ名は多少異なりますが、モードがGlobalやDirectではなくRuleになっていることを確認してください。

ルール間に空行を入れる必要はありません。例の空行は、LAN、プロキシ強制、中国本土ドメイン、フォールバックという4つの層を区切るためだけに使っています。YAMLのインデントにはスペースを使い、タブは使用できません。保存後にクライアントが解析エラーを表示したら、まずコロンの後のスペース、リスト項目のハイフン、プロキシグループ名を確認してください。

サブスクリプション設定を永続化する方法

サブスクリプションが生成した設定を直接開いて編集すれば、短時間は反映を確認できますが、次回の更新で通常は上書きされます。GUIクライアントには一般に「オーバーライド」「設定のマージ」「拡張スクリプト」などの機能があり、サブスクリプションの読み込み後にフィールドを追加・調整できます。どの方法を使うかは、クライアントがルールの前置き、後置き、配列の置換に対応しているかによって決まります。

現在の設定を先にコピーし、複製した設定でルールをテストします。
クライアントのオーバーライド機能が rules を追加するのか、元のルール配列を完全に置き換えるのか確認します。
優先的に一致させたいカスタムルールはサブスクリプションのルールより前に置き、MATCHの後ろへ追加するだけにしないでください。
保存後に設定を再読み込みし、エディター上のソースファイルだけでなく、実際に動作中の設定を確認します。
サブスクリプションを手動で1度更新し、カスタムルールが残っていて元の順序を保っていることを確認します。

「末尾に追加」は、機能しなくなる最も一般的な原因です。サブスクリプションのルールは通常、すでにMATCHまたはFINALで終わっているため、その後ろに追加した内容が一致することはありません。クライアントがルール追加にしか対応していない場合は、prepend、ルールの前置き、スクリプト注入などの機能を使います。全体置換しかできない場合は、サブスクリプションに含まれる重要な直接接続、ブロック、LANルールもまとめて管理する必要があります。

分流が本当に機能しているか確認する

まずモード、ポート、システムプロキシを確認する

ルールが正しくても通信がClashに入っていなければ、ログに該当する接続は表示されません。デスクトップクライアントでは、まずRuleモードが有効になっていることを確認し、次にシステムプロキシが現在のリスニングポートを指していることを確認します。この記事では 127.0.0.1:7890 を使用しています。画面に7897、7899、その他のポートが表示されている場合は、テストコマンドも同じポートに変更してください。

curl -I -x http://127.0.0.1:7890 https://www.qq.com/
curl -I -x http://127.0.0.1:7890 https://www.wikipedia.org/

次の2つのコマンドは、指定したHTTPプロキシポートをリクエストが通過しているか確認するためだけに使います。200、301、302 のいずれが返っても、リモートHTTP応答を受信したことを示すだけで、出口をステータスコードだけから判断することはできません。実際の分流結果は、クライアントの接続一覧やログに表示されるルール名、プロキシグループ、実際のノードと合わせて確認してください。

接続ログで確認する3つの項目

宛先ホスト：ログに想定したドメインが記録されているか確認します。バックグラウンドリクエストやページ内の第三者リソースでないことも確認してください。
一致したルール：中国本土のサイトではDOMAIN-SUFFIXまたはGEOIP,CN、海外のテストドメインでは指定したサフィックスルールまたはMATCHが表示されるはずです。
最終経路：DIRECTは直接接続を示します。プロキシグループ名の後ろには、通常、実際に選択されたノードも表示されます。

1つのウェブページは、メインサイトのドメイン、画像CDN、計測API、フォントリソース、動画の分割ファイルへ同時に接続します。そのため、同じページにDIRECT接続とプロキシ接続が混在していても矛盾ではありません。分流はブラウザーのタブ全体ではなく、個々の接続単位で確認してください。接続履歴を消去してからシークレットウィンドウで開き直すと、初回接続を観察しやすくなります。

一時ルールで優先順位を確認する

ルール順序が正しくないと思われる場合は、先頭に識別しやすいテストルールを一時的に追加します。たとえば、特定の中国本土向けドメインを「海外トラフィック」に割り当てます。設定を再読み込みしてそのドメインへアクセスし、ログにDIRECTと表示されるなら、現在の実行設定でこのルールが使われていないか、前置きオーバーライドが反映されていません。テスト後は一時ルールを削除し、通常のアクセス経路を長期的に変更しないようにしてください。

TUNモードで追加確認する項目

システムプロキシは、プロキシ設定を自動的に読み取るアプリの通信だけを対象にします。一方、TUNモードは仮想ネットワークデバイスを通じて、より多くのTCP、UDP、およびシステムプロキシ設定に従わない通信を取り込みます。ルール構文は同じ順序で照合されますが、DNS、ルーティングテーブル、アプリ独自の暗号化DNSが結果により大きく影響します。

TUNを有効にしたら、まずクライアントが仮想ネットワークデバイスの作成に必要なシステム権限を取得できているか確認します。Windowsでは仮想ネットワークアダプターが正常にインストールされ有効になっているか、macOSではネットワーク拡張機能またはVPN設定の許可が出ているかを確認します。Linuxでは通常、利用可能な /dev/net/tun と適切なcapabilityが必要です。権限に失敗すると、画面上ではTUNを有効にできたように見えても、実際の通信はシステムプロキシしか通らない場合があります。

ブラウザーで独自のセキュアDNSが有効になっていると、設定内のDNSリスナーを迂回し、ドメイン解決結果がルールエンジンの想定と一致しないことがあります。切り分け中は、ブラウザーに一時的にシステムDNSを使わせ、接続ログを比較してください。mihomo設定でよく使われるDNSリスニングポートは 1053、プロキシの混合ポートは 7890 です。用途が異なるため、システムプロキシをDNSポートへ向けないでください。

よくあるエラーと対処法

現象	主な原因	対処方法
すべてのサイトが同じノードを経由する	現在Globalモードになっている	Ruleに切り替え、接続を再確立する
カスタムルールにまったく一致しない	ルールがMATCHの後ろに追加されている	ルールを前置きするか、設定全体をマージする
中国本土のドメインがときどきプロキシ経由になる	ドメインが未登録で、解決されたIPもCNに分類されていない	完全一致のドメインルールを追加し、GeoIPデータを更新する
LAN機器にアクセスできない	プライベートアドレスがフォールバックルールに処理されている	プライベートネットワークのIP-CIDRを最上部に置く
サブスクリプション更新後にルールが消える	サブスクリプション生成ファイルを直接編集している	クライアントのオーバーライドまたは設定マージへ移行する
ルールには一致するがウェブページが開かない	プロキシグループが選択したノードを利用できない	遅延テスト、ハンドシェイクログ、ノード選択を確認する

設定が完了したら、ルール数を増やせばよいと考える必要はありません。より安定するのは、プライベートアドレス、少数のプロキシ強制例外、メンテナンスされた中国本土向けドメインルール、GEOIP、最終MATCHという明確な階層を保つ方法です。毎回1つの層だけを調整し、ログで一致結果を確認すれば、新しいドメインに遭遇したときも、完全一致ルールを追加するのか、ルールセットを更新するのか、プロキシグループを修正するのか判断しやすくなります。