Clashのルール振り分け実践：GEOIPとDOMAIN-SUFFIXで中国本土・海外を振り分け
中国本土の通信を直接接続し、海外向け通信をプロキシ経由にするルール設定を実例で解説。ルールの順序、MATCHによるフォールバック、rule-providerの管理方法も紹介します。
まず確認：通信がコアに届いていること、モードがRuleであること
中国本土と海外の振り分けは、クライアント画面に表示されたノード名で決まるものではありません。コアに届いた各接続を、ドメイン名や宛先IPなどの条件に基づいて振り分けます。この記事では「明示したドメインは直接接続、中国本土のIPも直接接続、それ以外はプロキシグループへ」という構成を使います。ここでいう中国本土・海外はルーティング方針を簡潔に表したもので、サイトの登記地、運営主体、コンテンツの対象地域を正確に判定するものではありません。
Clash for Windowsの開発元プロジェクトはすでにメンテナンスを終了しています。既存環境を維持する場合は基本的なルール構文を参考にできますが、新しい環境を構築する場合は、まずクライアント比較でメンテナンス状況とコアの機能を確認してください。以下の基本ルールは一般的なClash設定向けです。ルールセットの例はmihomoを想定しており、最新コアの機能を旧版CFWでも必ず使えるものとして扱っていません。
- Clash for WindowsのGeneral → System Proxyでシステムプロキシを有効にすると、Windowsのプロキシ設定に従うアプリがクライアントを経由します。システムプロキシに対応していないアプリは、個別にプロキシを設定するか、正しく設定したTUNを使用してください。
- Proxies → Ruleを開き、動作モードがルールモードになっていることを確認します。Globalではすべての接続がグローバルポリシーに渡され、Directでは直接接続されます。どちらもこの記事のルールを検証する用途には適しません。
- Profilesで現在有効な設定を確認し、プロキシポリシーグループが存在するかチェックします。この記事では既存のプロキシグループ名を
PROXYとします。実際に使う際は、設定ファイルにある正しい名前に置き換えてください。
DOMAIN-SUFFIX、GEOIP、MATCHの役割を理解する
Clashのルールは通常、上から順に照合され、出口が決まるルールに一致すると後続の確認は行われません。ルール一覧は「より精密なルールを自動で優先する」仕組みではありません。大まかなルールを先に置くと、後ろに書いた具体的な例外が適用されないことがあります。
| ルール | マッチ対象 | 注意点 |
|---|---|---|
DOMAIN,example.com,DIRECT | 完全一致のドメイン名 | www.example.comには一致しません。 |
DOMAIN-SUFFIX,example.com,DIRECT | ルートドメインとそのサブドメイン | example.comとa.example.comには一致しますが、notexample.comには一致しません。 |
GEOIP,CN,DIRECT | 宛先IPがGeoIPデータで割り当てられている地域 | ローカルデータに依存します。サイトが中国企業に属することを示すものではありません。 |
MATCH,PROXY | 先行ルールで出口が決まらなかった接続 | 最後に配置します。PROXYは既存のプロキシまたはポリシーグループである必要があります。 |
ドメインルールにURLを書かない
DOMAIN-SUFFIXの後にはドメイン名だけを指定し、https://、ポート番号、パスは付けません。たとえば、Alipay関連のドメインを直接接続する場合はDOMAIN-SUFFIX,alipay.com,DIRECTと書きます。ウェブページのURLを指定することはできません。また、URL内の/loginや/videoといったパスを判定するルールでもありません。
ドメインの末尾は地理的な境界ではありません。すべての.comを海外扱いにしたり、.cnだけで実際のサーバー所在地を判断したりするのは適切ではありません。よく使うサービスには具体的なドメインルールを設定し、それ以外の接続をIPの地域情報で判定すると、確認や管理がしやすくなります。
基本設定：例外、GEOIP、最後にフォールバック
以下はメイン設定の一部であり、ノードを含む完全なサブスクリプションではありません。使う前に現在の設定をバックアップし、PROXYという名前のプロキシグループが存在することを確認してください。統合時は既存のノード、DNS、ポートの設定を残します。トップレベルにrules:がすでにある場合は、そのリストを編集し、同じキーを重複して追加しないでください。
mode: rule
rules:
# ローカルホストと一般的なプライベートIPv4アドレス
- DOMAIN,localhost,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
# ローカルホストとプライベートIPv6アドレス
- IP-CIDR6,::1/128,DIRECT,no-resolve
- IP-CIDR6,fc00::/7,DIRECT,no-resolve
- IP-CIDR6,fe80::/10,DIRECT,no-resolve
# 実際の用途に合わせて具体的なドメインルールを追加
- DOMAIN-SUFFIX,baidu.com,DIRECT
- DOMAIN-SUFFIX,qq.com,DIRECT
- DOMAIN-SUFFIX,alipay.com,DIRECT
- DOMAIN-SUFFIX,wikipedia.org,PROXY
# ドメインルールに該当しない中国本土のIPは直接接続
- GEOIP,CN,DIRECT
# それ以外の接続は既存のプロキシグループへ
- MATCH,PROXYこの順序では、まずLAN内の宛先を直接接続し、次に明示したドメインの例外を処理します。その後、広い範囲を対象とするIPの地域判定をGEOIP,CN,DIRECTで行い、最後に残った接続をMATCHで受け止めます。例のドメインは書き方を示すもので、中国本土のサービスを網羅した一覧ではありません。アプリによっては、画像、ログイン、決済、更新に別のドメインを使うことがあります。
GEOIPをすべてのドメインルールより前に置かない理由
あるサービスのドメインを常にプロキシ経由にしたいのに、現在の解決先IPがGeoIPデータでCNに分類されている場合を考えてみましょう。先にGEOIPによる直接接続を指定すると、後続のドメイン別プロキシルールが適用されない可能性があります。具体的な用途に基づくルールを先に置き、地理情報による判定を補完として使えば、例外を維持できます。
LANのアドレス範囲も実際のネットワークに合わせてください。例には172.16.0.0/12を含めていますが、172.0.0.0/8全体ではありません。行数を減らすために、パブリックIPを含む可能性のある範囲全体を直接接続にしないでください。上記のルールは出口を選ぶだけで、TUNのルーティング、ネットワークアダプターの優先順位、ファイアウォールによる遮断を自動で解決するものではありません。
GEOIPの後ろに付けるno-resolve：名前解決を減らせる一方、マッチしなくなる場合も
ルール振り分けを調べていると、GEOIP,CN,DIRECTとGEOIP,CN,DIRECT,no-resolveの2種類を見かけます。違いは地理データベースではなく、このルールの判定時に、宛先IPを調べるためのドメイン名解決を行うかどうかです。
- no-resolveを付けない場合：判定に宛先IPが必要なドメイン接続では、コアが名前解決を行い、その結果をGeoIPで照合できます。上の基本例では、ドメイン一覧にない中国本土のサービスも対象にしやすいこの書き方を使っています。
- no-resolveを付ける場合：このルールは、自身の判定のためにドメイン名解決を開始しません。その接続のコンテキストに利用可能な実際の宛先IPがなければ、後続のMATCHに進む可能性があります。
- IPアドレスをすでに取得している場合：IPアドレスへの直接アクセスや、現在の接続コンテキストに照合可能なアドレスがある場合は、no-resolve付きのIPルールにも一致することがあります。設定ファイルだけで推測せず、接続の詳細を確認してください。
そのため、GEOIPにno-resolveを付けながら、一覧にない中国本土のドメインをすべて受け止めることはできません。振り分けのために発生する名前解決をできるだけ抑えたい場合は、まず十分なドメインルールを整備し、一部の未知のドメインがプロキシ側のフォールバックに進むことを前提にしてください。
fake-ipはウェブサイトの実際のIPアドレスではない
fake-ipを有効にすると、アプリには198.18.0.0/16の範囲にあるマッピング用アドレスが見えることがあります。これはコアがドメイン名と対応付けるための仮想アドレスであり、ウェブサイトの実際の所在地を示すものではありません。「GEOIPを直す」ためにfake-ipのアドレス範囲全体を直接接続にするのは避け、コアが復元したドメイン名、実際の名前解決結果、適用されたルールを確認してください。DNS設定は使用するコアとクライアントのバージョンに合わせる必要があります。詳しくは設定リファレンスをご覧ください。
rule-providers：よく使うドメインルールを管理しやすいファイルに分ける
ルールが十数件から数百件に増えると、すべてのドメインをメイン設定に詰め込むことで確認が難しくなります。rule-providersでルールの参照元を宣言し、メインのルール一覧からRULE-SETで呼び出します。ここではmihomo対応のローカルファイル形式のルールセットを使い、リモートルールの取得や定期更新と、基本的な振り分け設定を分けて確認できるようにします。
手順1：メイン設定で宣言して参照する
管理するドメインをルールセットに移したら、以下の宣言とルール一覧でメイン設定の該当部分を置き換えます。local-directは独自に付けるルールセット名です。参照時には完全に同じ名前を使ってください。既存のLAN向けルールは、引き続きルールセットより前に置きます。
rule-providers:
local-direct:
type: file
behavior: classical
path: ./rules/local-direct.yaml
rules:
- DOMAIN,localhost,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-CIDR6,::1/128,DIRECT,no-resolve
- IP-CIDR6,fc00::/7,DIRECT,no-resolve
- IP-CIDR6,fe80::/10,DIRECT,no-resolve
- DOMAIN-SUFFIX,wikipedia.org,PROXY
- RULE-SET,local-direct,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY手順2：ルールセットファイルを作成する
コアの作業ディレクトリに対応するrules/local-direct.yamlに、以下の内容を保存します。相対パスは通常コアの作業ディレクトリを基準とするため、サブスクリプションファイルの保存先とは異なる場合があります。クライアントのログと実際のデータディレクトリを確認してください。mihomoはパスへのアクセスに制限があるため、許可されたデータディレクトリ内にファイルを置くことをおすすめします。
payload:
- DOMAIN-SUFFIX,baidu.com
- DOMAIN-SUFFIX,qq.com
- DOMAIN-SUFFIX,alipay.comここでのbehavior: classicalは、各項目にルールタイプを含める形式を示します。ファイル内に末尾の,DIRECTはありません。出口はメイン設定のRULE-SET,local-direct,DIRECTで指定します。behavior: domainに変更する場合は、項目の形式も合わせて変更してください。behaviorだけを変更して元の内容を残すことはできません。
ローカルファイル形式のルールセットは、リモートサブスクリプションの更新間隔に合わせて自動取得されるものではありません。編集後はクライアントの設定再読み込みまたはルールセット再読み込み機能を使い、ログで読み込みが成功したことを確認してください。HTTP形式のルールセットを使う場合は、信頼できる参照元、キャッシュ先、更新間隔を設定します。たとえばinterval: 86400の単位は秒で、1日を意味します。ただし、参照元の形式はbehaviorと一致させる必要があります。
サブスクリプション更新とルール管理：どの設定が上書きされるか確認する
クライアントが生成したサブスクリプション設定を直接編集すると、次回の更新時に変更が上書きされることがあります。より安全な方法は、ノードの参照元として元のサブスクリプションを残し、クライアントが対応するオーバーライド、マージ、拡張設定のレイヤーで独自ルールを管理することです。マージ方法はクライアントによって異なり、rules全体を置き換えるものもあれば、先頭への追加に対応するものもあります。保存できたことだけで、ルールの順序が正しいと判断しないでください。
- まずバックアップ：元の設定と現在使用できているルールセットファイルを保存し、使用中の設定名を控えておきます。
- 最終的な設定を確認：実際に動作している設定に
mode: rule、プロキシグループ名、ルールの順序、rule-providersの宣言が含まれていることを確認します。 - サブスクリプションを手動で一度更新：更新後にもう一度確認し、翌日になって独自ルールが消えたことに気付いてから調べる事態を避けます。
- 一度に変更する内容は一種類に：まずドメインルールを検証し、次にGEOIPを追加し、最後にルールセットへ分割します。異常が起きたときに、どの層の変更が原因か特定しやすくなります。
GeoIPデータの更新とドメインルールの管理は別々に行います。GeoIPデータを更新しても、アプリに新しく追加されたドメインは補えません。ドメインルールを追加しても、古くなったIPの地域情報は修正できません。データベース名、取得方法、更新機能はコアによって異なるため、別のクライアントで使うファイル名をそのままCFWのディレクトリに流用しないでください。
振り分けを検証する：ウェブページが開くかではなく、適用されたルールを見る
設定を保存したら、まず検証する接続を新しく確立してください。既存の長時間接続はルールを変更しても出口が自動で切り替わらないことがあります。ブラウザーが接続を再利用し、以前の結果が残る場合もあります。該当する接続を閉じてから再試行し、クライアントのConnections画面で宛先ドメイン、適用ルール、プロキシチェーンを確認してください。表示項目の名称はクライアントによって多少異なります。
| 検証するケース | この設定で想定される結果 | 問題がある場合にまず確認する点 |
|---|---|---|
www.baidu.comにアクセス | ドメインルールまたはlocal-directに一致し、出口はDIRECT | ドメインのスペル、ルールセットの読み込み、前段にブロックルールがないか。 |
www.wikipedia.orgにアクセス | ドメインルールに一致し、PROXYポリシーグループへ | グループ内で現在選択されている項目が、DIRECTではなくプロキシノードか。 |
実際のルーターアドレス（例：192.168.1.1）にアクセス | コアに取り込まれていれば、LAN向けの直接接続ルールに一致 | 接続一覧に記録がない場合、システムプロキシのバイパスリストによって直接許可されている可能性があります。 |
| ドメイン一覧にないパブリックIPの宛先にアクセス | GEOIPで判定し、一致しない場合はMATCHへ | 宛先の解決先IP、GeoIPデータ、no-resolveの有無。 |
よくある誤解を3つ
- PROXYと表示されれば必ずノード経由だと思う：PROXYはグループ名にすぎません。グループ内でDIRECTが選択されていれば、最終的には直接接続です。プロキシチェーン全体を確認してください。
- ウェブページが開けば、すべてのリソースが同じ経路だと思う：メインページ、画像、ログインAPIが別々のドメインに接続する場合があります。関連する接続を一つずつ確認してください。
- 接続一覧に記録がなければ、ルールが機能していないと思う：アプリの通信がそもそもコアに届いていない可能性があります。ルールのマッチを調べる前に、システムプロキシまたはTUNで通信が取り込まれているか確認してください。
振り分けが正しくないドメインは、「コアに届いているか → 動作モード → 実際のドメインとIP → 適用ルール → 最終的な出口」の順で調べると、ノードを何度も切り替えるより効率的です。基本構成が安定してから、必要なドメインやルールセットを段階的に追加してください。網羅的に見える一覧を作るために、出所が不明で優先順位が重複するルールを複数取り込むのは避けましょう。