GEOIPとDOMAIN-SUFFIXの実践設定｜Clashの中国国内・海外向けルール | Clash ダウンロード公式サイト

1. まず振り分けの基準を決める：ドメイン、接続先IP、フォールバック

中国国内・海外向けの振り分けは、Webページの言語や企業の登記地で決まるものではありません。Clashのルールエンジンは、接続時に取得できるドメインや接続先IPなどの情報を使い、設定順に一致するルールを探します。ここでは、直結対象として明示したドメインを優先的に直結し、中国本土のIPと判定された接続も直結、それ以外はプロキシグループに渡す構成を例にします。

これは保守しやすいルーティング方針であり、すべてのWebサイトの所在地を正確に分類するものではありません。海外サービスが中国国内のCDNを使うこともあれば、中国国内のサービスが海外のAPIに接続することもあります。ドメインルールは利用目的を表し、GEOIPはIPアドレスの所在情報を補います。互いに置き換えられるものではありません。

ルール	判定基準	対象範囲
`DOMAIN`	完全一致するドメイン名	特定のホスト名に対する例外
`DOMAIN-SUFFIX`	ドメインのサフィックス	親ドメインとそのサブドメイン
`GEOIP`	データベースに登録された接続先IPの所在	ドメインリストで補足されない接続
`MATCH`	上にあるルールに一致しない	残りすべての接続に対するフォールバック

設定を反映するための3つの前提

クライアントがrule（ルール）モードになっていること。グローバルモードでは、この記事のルール一覧に基づいて出力先は選択されません。
対象アプリの通信が実際にクライアントを経由していること。システムプロキシはプロキシ設定に従うアプリのみが対象です。TUNの場合は仮想NIC、ルーティング、権限の設定も関係します。
ルールで参照するプロキシグループが存在すること。ここではグループ名に海外プロキシを使っています。現在の設定にある実際の名前に置き換えてください。

2. DOMAIN-SUFFIXをGEOIPより前に配置する

DOMAIN-SUFFIX,qq.com,DIRECTはqq.comとmail.qq.comに一致しますが、notqq.comには一致しません。サフィックスはドメイン名の区切りを認識して判定されるため、*.qq.comと書く必要はありません。ドメイン欄にhttps://、ポート番号、URLのパスを含めないでください。

通常のルール一覧は上から順に評価され、最初に一致したルールが適用されます。「より具体的な」ルールが自動で選ばれるわけではありません。同じサイトに個別の例外を設ける場合は、完全一致のドメインを先に書き、その後に広い範囲のサフィックスルールを置きます。サフィックスルールが先に一致すると、後続のGEOIPルールで結果は変わりません。

基本ルールの例

mode: rule

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
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,海外プロキシ

この例では、一般的なプライベートアドレス、IPv6のユニークローカルアドレス、ループバックアドレスを直結にし、その後に指定した2つのドメインサフィックスを処理します。特殊用途アドレスをすべて網羅したものではありません。IPv6のリンクローカルアドレス、マルチキャスト、企業独自のルーティングを利用している場合は、既存のLANルールに合わせて追加してください。元の設定にある関連ルールをそのまま削除しないでください。

DIRECTは組み込みの直結ポリシーです。クライアントを経由しないという意味ではなく、クライアントが直結方式で外部接続を確立します。
海外プロキシは任意に設定したプロキシグループ名です。ルール内の名前はproxy-groupsに記載した名前と完全に一致させてください。
MATCHは最後に置きます。前に置くと、それ以降のルールが評価されなくなります。

「特定のサブドメインはプロキシ経由にし、親ドメインのその他は直結したい」場合は、サフィックスルールの前にDOMAIN,指定した完全なホスト名,海外プロキシを追加します。1つのAPIを処理するために、大規模サービス全体のドメインサフィックスをプロキシ対象にするのは避けてください。変更範囲が広がり、検証も難しくなります。

3. GEOIPとno-resolve：IP判定のためにドメインを解決するか

GEOIP,CN,DIRECTはIPデータベースを参照するルールであり、Webサイトの所属国をオンラインで判定するものではありません。接続時にドメイン名しか取得できない場合、IPルールの評価に先立ってドメインを解決することがあります。実際の解決動作は、コアの実装、DNSモード、接続に付随するメタデータによっても異なります。

no-resolveを付けると、このIPルールのためだけにドメイン解決を開始しません。接続に判定可能な接続先IPがすでにあれば、一致する場合があります。有効なIPがなければ、後続のルールが評価されます。これは「DNSを無効にする」設定でも、「DNSリクエストを遮断する」スイッチでもありません。

記述方法	ドメイン名しかない場合	トレードオフ
`GEOIP,CN,DIRECT`	IP判定のために名前解決が行われる場合がある	IPの所在に基づいて直結できる範囲が広がる一方、名前解決への依存が生じる
`GEOIP,CN,DIRECT,no-resolve`	このルールのための名前解決を行わない	マッチング時の余分な名前解決を減らせる一方、一部のドメイン接続はフォールバックに進む

選び方

直結対象のドメインリストを十分に整備しており、残りのドメインはプロキシグループに渡したい場合は、no-resolveの利用を優先できます。
IPの所在情報を使って、リストにない中国国内のドメインを多数直結したい場合は、パラメーターを付けない構成も検討できます。その際はDNSの可用性と名前解決の結果も確認してください。
アプリがIPアドレスに直接接続する場合、接続先アドレスはすでに判明しているため、通常no-resolveがそのIPのマッチングを妨げることはありません。

GEOIPの精度はローカルデータベースにも左右されます。IPアドレス帯の移転、データベースの更新遅れ、CDNの振り分けなどで誤差が生じることがあります。mihomoの地理データ設定も、実際に読み込まれるデータファイルに影響します。起動ログにデータベースの不足や読み込み失敗が表示された場合は、ルール順を何度も変更する前に、データの読み込みを解決してください。

4. rule-providers：直結対象のドメインを管理しやすいファイルに分ける

ドメインの例外が数件から数十件に増えると、メイン設定に追加し続けることで重複や記述ミスが起きやすくなります。mihomoではrule-providersでルールプロバイダーを定義し、RULE-SETで参照できます。プロバイダーにはマッチ条件を格納し、適用するポリシーはメイン設定の参照ルールで指定します。

メイン設定：ローカルのドメインルールセットを定義

rule-providers:
  domestic-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/domestic-domains.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
  - RULE-SET,domestic-domains,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,海外プロキシ

ルールファイル：rules/domestic-domains.yaml

payload:
  - '+.qq.com'
  - '+.taobao.com'
  - '+.jd.com'

mihomoのdomainタイプのルールセットでは、+.qq.comはそのドメインとサブドメインを表します。ドメインパターンの原文を保つため、シングルクォートで囲んでいます。このファイルにはDOMAIN-SUFFIX,qq.com,DIRECTと書かないでください。ここで必要なドメイン項目の形式とは異なります。

behavior: domain：ドメインのマッチ条件を格納します。直結またはプロキシ対象のドメイン一覧に適しています。
behavior: ipcidr：IPアドレス範囲を格納します。ドメイン項目は混在させられません。
behavior: classical：DOMAIN-SUFFIX,qq.comなどのルール式を格納します。通常、項目の末尾にポリシー名は記述しません。

相対パスは、コアの作業ディレクトリとクライアントのファイルアクセス制限に基づいて解釈してください。編集中のサブスクリプションファイルを基準にするとは限りません。モバイル版クライアントでは、ファイルのインポートや保存場所が制限される場合もあります。保存後、ルールセットが正常に読み込まれ、項目数に問題がないことを確認してから、接続を作り直してテストしてください。ローカルのtype: fileはネットワークからコンテンツを自動取得しません。リモート更新用のintervalも不要です。

リモートルールセットを使う場合は、まず提供元ファイルのbehaviorとformatを確認してください。ドメインのプレーンテキスト一覧をYAMLファイルとして読み込むことはできません。また、別のコア専用のバイナリファイルを、その形式に対応していないバージョンに渡すこともできません。

5. DNS、システムプロキシ、TUN：ルールが参照できる情報

ルールが適用されないからといって、必ずしも構文に誤りがあるとは限りません。まず、接続がクライアントに届いた時点でどの情報を持っているかを確認します。HTTPプロキシのリクエストでは、通常、接続先のホスト名を取得できます。一部のSOCKSアプリはローカルで先に名前解決し、IPアドレスだけをクライアントに渡します。同じWebサイトへの接続でも、後者ではドメインサフィックスルールに直接一致しない場合があります。

よくある3つの注意点

プロキシより先にローカルで名前解決される。 アプリが接続先IPだけを渡す場合、ドメインルールに直接一致する条件がありません。スニッフィング対応のコアは一部のプロトコルでドメイン名を補えることがありますが、すべての接続でホスト名を復元できるとは限りません。
DNSの処理範囲が不十分。 TUNのDNSハイジャック設定が、すべての暗号化DNSを識別できることを意味するわけではありません。アプリ内蔵のDoHはHTTPS接続を使うため、通常のUDP 53番ポートへの問い合わせと同じものとして扱えません。
IPv4とIPv6で経路が異なる。 同じドメインでもAレコードとAAAAレコードの両方が返され、接続ごとに異なるアドレスが使われる場合があります。IPv4のテスト結果だけでは、IPv6接続にも同じポリシーが適用されるとは判断できません。

TUNはルーティング条件に合うIP通信を取り込むための機能で、誤ったルール一覧を自動で修正するものではありません。システムプロキシとTUNを同時に有効にしている場合は、テスト対象のアプリが実際にどちらを経由しているか確認してください。企業VPN、コンテナ用ネットワーク、仮想マシンのネットワークによってルーティングが変わることもあります。イントラネットに接続できない場合は、直結ルールを追加する前にネットワーク帯の重複を確認してください。

DNSと出力先は別々に検証してください。名前解決に成功しても、接続先ポートに到達できるとは限りません。DIRECTに一致しても、直結回線が利用可能とは限りません。ドメインが海外のIPに解決されてGEOIPの対象外となった場合、それは現在のデータに基づくルールの結果であり、必ずしもルールエンジンの障害ではありません。

6. ルールが適用されないときの確認手順とテストケース

トラブルシューティングでは、一度に変更する項目を1つに絞ります。まず失敗した接続のドメイン、接続先IP、ポート、適用ルール、実際のポリシーを記録してから、ドメイン一覧とIPルールのどちらを修正するか判断してください。以下は想定される結果の一覧で、回線速度を実測したものではありません。現在の設定とネットワークで項目ごとに検証してください。

テスト対象	想定される一致結果	確認ポイント
`192.168.1.1:80`	プライベートIPルール → DIRECT	対象アドレスがローカルゲートウェイであることを確認してテスト
`www.qq.com:443`	ドメインサフィックスまたはルールセット → DIRECT	接続ログにドメイン名が残っているか
ドメイン一覧に含まれないCNアドレス	GEOIP → DIRECT	接続にマッチング可能なIPがあるか
その他の新規接続	MATCH → 海外プロキシ	グループ内で実際に選択されたノードまたはポリシー

クライアントを再インストールする前に、6つの手順で原因を特定する

有効な設定とモードを確認する。 現在の設定名とルールモードを確認し、エディター内のファイルだけでなく、実行中のルール一覧を確認してください。
接続がクライアントに届いているか確認する。 接続パネルで対象のリクエストを探します。記録がまったくない場合は、システムプロキシ、TUNのルーティング、アプリ独自のプロキシ設定を優先して確認してください。
最初に一致したルールを確認する。 先にある広範囲のドメインルールに一致している場合は、より具体的な例外をその前に移動します。前方に置かれたMATCHに一致している場合は、まずフォールバックの位置を修正してください。
名前解決とデータベースを確認する。 接続先IP、IPv4かIPv6か、地理データの読み込みログを確認します。no-resolveを使っている場合は、有効なIPがないために一致しなかった可能性を調べてください。
ルールセットの読み込みを確認する。 パスやインデントの誤り、フォーマットの不一致により、プロバイダーが利用できないことがあります。まずファイルを読み取れることと項目が読み込まれたことを確認し、その後でRULE-SETの配置を検証してください。
接続を作り直す。 対象アプリの既存セッションを閉じるか、クライアントで該当する接続を切断してから再試行してください。ルールファイルを変更しても、既存の長時間接続の出力先は通常自動で切り替わりません。

検証後は、プロキシグループ内で実際に何が選択されているかも確認してください。「海外プロキシ」に一致したことが示すのは、接続がそのグループに渡されたということだけです。グループ内でDIRECTが選ばれていれば、最終的には直結します。逆に、直結ルールに一致してもページを開けない場合は、DNS、接続先サービス、ローカルネットワークに問題がある可能性があります。振り分けが機能していないとすぐに判断しないでください。