Clashのルール振り分け設定ガイド：ドメイン suffix と GeoIP で中国国内外の通信を分ける

1. ルールモードと照合順序

Clashの振り分けは接続単位で行われます。接続がコアに入ると、コアは取得できる宛先ドメイン、宛先IP、ポートなどの情報をもとに、rulesを上から順に確認します。最初に一致したルールで使用するアウトバウンドが決まり、通常、その接続では以降のルールは評価されません。そのため、ルールの数より順序が重要です。

この記事では、Clashで一般的な基本ルール構文を使用します。これらのフィールドに対応するClashおよびClash Meta／mihomoコアで利用できます。クライアントによって画面上の項目名は異なる場合がありますが、設定内のmode: rule、rules、ポリシー名は実際に動作している設定と一致させてください。拡張ルールタイプやデータベースのオプションが、バージョンを問わず使えるとは限りません。

変更前に確認する3項目

動作モード：Rule／ルールモードに切り替えます。Global／グローバルモードではこの記事のルールに沿った振り分けは行われず、Direct／直接接続モードもルールのテスト環境ではありません。
通信の入口：ブラウザーの通信がシステムプロキシまたは明示的なプロキシを経由してコアに入ることを確認します。システムプロキシに従わないアプリも取り込む必要がある場合は、TUNモードを検討してください。
利用可能なアウトバウンド：設定に使用可能なプロキシノードがあるか、それらを含むプロキシグループが必要です。この記事では、このグループ名を中国国外プロキシとします。

システムプロキシとTUNは、どの接続をコアに取り込むかを決めます。ルールは、取り込まれた接続をどのように送出するかを決めます。TUNを有効にしても、すべての接続が自動的にプロキシ経由になるわけではありません。ルールモードにしても、システム上のすべてのアプリが自動的に取り込まれるわけではありません。まずクライアントの接続一覧に対象の接続が表示されることを確認し、その後で振り分け結果を確認してください。

3種類の基本ルール

ルール	照合条件	主な用途
`DOMAIN-SUFFIX`	完全一致するドメインとそのサブドメイン	特定サイトを直接接続またはプロキシ経由にする
`GEOIP`	宛先IPのデータベース上の地域	CNのアドレスを直接接続に振り分ける
`MATCH`	残りすべての接続	最後の送出先を明示する

DIRECTは組み込みの直接接続ポリシーです。中国国外プロキシはユーザー設定内の名前であり、コアに組み込まれたキーワードではありません。どちらもルールのポリシー欄に指定できますが、後者はノードまたはプロキシグループに定義済みで、名前が完全に一致している必要があります。

2. 中国国内は直接接続、中国国外はプロキシ経由にする基本設定

現在使用中の設定をバックアップしてから、ルール部分を差し替えてください。以下は既存設定に追加・統合するための例で、サブスクリプションURL、ノードの認証情報、完全なプロキシグループ設定は含みません。すでにmixed-portまたはmodeがある場合は、同じ階層に重複して追加せず、既存の項目を変更してください。

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

rules:
  # LAN 名とよく使うローカルアドレス
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,lan,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,qq.com,DIRECT
  - DOMAIN-SUFFIX,jd.com,DIRECT
  - DOMAIN-SUFFIX,github.com,中国国外プロキシ
  - DOMAIN-SUFFIX,githubusercontent.com,中国国外プロキシ
  - DOMAIN-SUFFIX,wikipedia.org,中国国外プロキシ

  # IP の地域判定と最後のフォールバック
  - GEOIP,CN,DIRECT
  - MATCH,中国国外プロキシ

7890はこの記事で例として使用するHTTP／SOCKS混合リスニングポートです。すべてのクライアントでの既定値ではありません。現在のクライアントで別のポートを使用している場合は、実際の値を維持してください。プロキシグループの状態も確認が必要です。ルールが中国国外プロキシに一致しても、グループ内でDIRECTが選択されていれば、最終的には直接接続されます。

GeoIPより前にドメイン指定ルールを置く理由

ドメインルールは通信の振り分け意図を表し、GeoIPはIPデータベース上の分類を表します。この2つは同じ意味ではありません。プロキシ経由にしたい特定のドメインが、データベース上でCNとされるアドレスに解決されたとします。この場合、GEOIP,CN,DIRECTを先に評価すると、接続はそこで直接接続に振り分けられます。ドメイン指定ルールを前に置けば、IPの地域判定よりサイトごとの方針を優先できます。

同様に、直接接続したい企業サービスは、宛先が中国国外でも、前方にドメインルールを置いてDIRECTを指定できます。ここでいう「国内外の振り分け」は既定の方針であり、すべてのサイトを一律に分類するものではありません。ログイン、決済、企業専用回線などは、実際のネットワーク要件に応じて個別に設定してください。

3. DOMAIN-SUFFIXの書き方と適用範囲

DOMAIN-SUFFIX,qq.com,DIRECTはqq.comとmail.qq.comなどのサブドメインに一致します。文字列が似ているだけのnotqq.comには一致しません。ドメイン欄にはドメイン名だけを指定し、https://、パス、クエリパラメーターは書きません。また、*.qq.comのような指定も不要です。

ホスト名を完全指定：DOMAIN,login.example.com,DIRECTは、そのホスト名だけに一致します。
ドメイン全体：DOMAIN-SUFFIX,example.com,DIRECTは、ルートドメインとサブドメインの両方に一致します。
キーワード：DOMAIN-KEYWORDは文字列を含むかどうかで照合するため適用範囲が広く、正確なドメイン一覧の代わりには適しません。

上記のexample.comは構文の説明用です。実際の運用では、確認済みのサービスドメインを指定してください。1つのWebページでも、メインサイト、画像、API、オブジェクトストレージなどに複数のドメインを使う場合があります。メインサイトのドメインがプロキシに一致しても、すべてのリソースが同じポリシーになるとは限りません。たとえばGitHubのページと一部のrawファイルでは、それぞれgithub.comとgithubusercontent.comが使われるため、接続一覧で個別に確認してください。

適用範囲の狭い例外を先に置く

rules:
  - DOMAIN,download.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,中国国外プロキシ
  - GEOIP,CN,DIRECT
  - MATCH,中国国外プロキシ

この単独の例では、同じドメイン配下の例外を示しています。ダウンロード用ホストは直接接続し、それ以外のサブドメインはプロキシ経由にします。最初の2つのルールを入れ替えると、suffixルールが先に一致し、ホスト名を完全指定したルールが機能しなくなります。ルールを追加するたびに、上に適用範囲の広いルールがないか確認してください。

4. GeoIP、DNS、no-resolveの組み合わせ

GEOIP,CN,DIRECTは「中国語のサイトを直接接続する」ルールでも、「.cnドメインをすべて直接接続する」ルールでもありません。宛先IPの地域情報を参照します。ドメインが中国国外のCDNを使うことも、中国国外のサイトが中国国内のアドレスを返すこともあります。データベースの更新、IPアドレスの移転、DNSの応答結果によって照合結果は変わります。

従来のClashでは、GeoIPデータにCountry.mmdbを使うのが一般的です。mihomoでは、動作モードやバージョンに応じた地理データベース設定もあります。データの読み込みエラーが発生した場合は、まず現在のコアのログと実際のデータベース設定を確認してください。他のクライアントのデータベースファイル名、更新URL、拡張フィールドをそのまま転用しないでください。

no-resolveはDNSを無効にする設定ではない

IPベースのルールにno-resolveを付けると、そのルールの照合のためだけに宛先ドメインを追加で名前解決しないよう指定できます。接続に宛先IPがすでに含まれている場合は、そのアドレスを使って引き続き照合できます。アプリによるDNS問い合わせを禁止したり、システムのDNS設定を変更したりするものではありません。

記述方法	宛先がドメイン名の場合	主な違い
`GEOIP,CN,DIRECT`	必要に応じて名前解決し、IPの地域を判定する	ドメインルールに一致しなくても、IPがCNの接続を振り分ける
`GEOIP,CN,DIRECT,no-resolve`	このルールのためだけの追加の名前解決は行わない	利用できる宛先IPがない場合、フォールバックに進むことがある

この記事の基本設定では、LANのアドレス範囲を照合するルールにno-resolveを付け、プライベートアドレスを確認するためだけに各ドメインを先行して名前解決しないようにしています。CNルールでは名前解決を許可しています。イントラネットのホスト名を確実に直接接続したい場合は、明示的なドメインルールを追加するか、イントラネットDNSを正しく設定してください。プライベートアドレスのルールが必ず先に名前解決を取得すると想定しないでください。

Fake-IPとドメイン情報の確認

Fake-IPモードでは、コアがドメインと偽アドレスの対応関係を管理します。接続がコアに入った後、この対応関係から元のドメインを復元してルールを判定できます。一般的なFake-IPのアドレス範囲である198.18.0.0/16を実際の中国国外サービスのネットワークと誤認しないでください。また、「偽アドレスを避ける」ために範囲全体を強制的に直接接続にするのも避けてください。

一方、アプリが独自のDNSを使う場合、IPアドレスへ直接接続する場合、または想定したDNS経路を通らない場合、コアがドメイン情報を十分に取得できず、DOMAIN-SUFFIXが照合に使われないことがあります。mihomoのスニッフィング機能で一部の接続のドメイン情報を補える場合はありますが、すべてのプロトコルから復元できるわけではありません。ブラウザーのアドレスバーだけで判断せず、接続詳細に表示されるドメイン、宛先IP、適用ルールを確認してください。

5. 設定の読み込み、接続確認、ログの調査

検証は2段階で行います。まず設定が正常に読み込まれたことを確認し、次に新しい接続が想定したポリシーに一致することを確認してください。ファイルを保存しただけでは、クライアントが新しいルールを使っているとは限りません。サブスクリプション設定はクライアントの生成処理で再加工される場合もあるため、実行中の設定や接続詳細を基準に確認してください。

バックアップ：現在の設定をエクスポートし、動作モード、リスニングポート、プロキシグループの選択状態を記録します。
構文を確認：半角カンマとスペースによるインデントを使い、トップレベルのrulesが1つだけであることを確認します。
再読み込み：クライアントの設定再読み込み機能を使います。失敗した場合は、まずログにあるYAMLの構文エラーやポリシー名の誤りを解消してください。
新しい接続を作成：テストページの既存の接続を閉じてから、もう一度リクエストします。既存の接続は確立時のアウトバウンドを使い続けることがあり、ページを再読み込みしても長時間接続が再利用される場合があります。
3項目を確認：宛先ドメインまたはIP、適用ルール、最終的なアウトバウンドノードを確認します。3つすべてが正しい場合に、今回の振り分けが想定どおりと判断できます。

パブリックIPだけでなく、明示的なプロキシ入口でテストする

現在の混合ポートが7890である場合、次のコマンドをローカルで実行して、コア経由のリクエストを1回送信できます。このコマンドで確認できるのは明示的なプロキシ入口だけです。他のアプリがシステムプロキシまたはTUNに接続されていることを示すものではありません。

curl --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://github.com/

ここでの10は接続時のタイムアウト秒数であり、速度テストの結果ではありません。実行後、接続一覧でgithub.comを探します。先頭に置いたドメインsuffixルールに一致し、中国国外プロキシグループを経由して選択中のノードに到達するのが想定される動作です。HTTPのリダイレクトやその他のステータスコードだけでは、振り分けの誤りとは判断できません。

GeoIPを確認するには、先行するドメインルールに一致しないテスト対象を一時的に選び、そのときの解決先IPを記録してから、CNルールに一致するかを確認します。CDNのアドレスやデータベースの内容は変わるため、特定の公開サイトが常に同じルールに一致すると決めつけないでください。最後のMATCHルールを検証する場合も、実際の接続記録を確認してください。

6. よくある問題と継続的な管理

症状	まず確認する項目	対処方法
新しい接続がすべて同じポリシーを使う	動作モード、先頭にMATCHルールがないか	ルールモードに戻し、MATCHを最後に置く
設定の再読み込みに失敗する	ポリシー名、カンマ、インデント、重複フィールド	ログから行番号を特定し、実際のグループ名を確認する
プロキシグループに一致しているのに直接接続される	グループ内の現在の選択肢とネストされたグループ	最終的な接続先がDIRECTではないことを確認する
ドメインルールに一致しない	コアがドメイン情報を取得できているか、それより前に別のルールがないか	DNSの経路とルールの照合順序を確認する
中国国内のサービスがフォールバックのプロキシに送られる	解決先アドレス、GeoIPデータ、no-resolve	根拠に基づいてデータベースを修正するか、ドメイン例外を追加する
サブスクリプション更新後にルールが消える	サブスクリプションの元データを編集したか、永続的なオーバーライドを使ったか	クライアントがサポートするオーバーライドまたはマージ機能を使う

サブスクリプションの更新とルールのマージ

サブスクリプションには設定やノード情報が含まれます。ルールが保持されるかどうかは、クライアントの設定処理方法によって異なります。一時生成されたファイルを直接編集すると、次回の更新で変更が上書きされることがあります。クライアントが明示的にサポートする永続的なオーバーライド、スクリプト、ルールのマージ機能を使い、ルールが「前置」「後置」「全体置換」のどれにあたるか確認してください。既存のMATCHより後ろにルールを追加すると、構文上は正しくても振り分けに反映されません。

ルールが増えてきたら、ルールセットの管理を検討できます。mihomoではrule-providersでルールセットを読み込み、RULE-SETから参照できます。動作タイプとファイル形式を一致させてください。ドメインが1列に並んだだけのファイルを、どの形式でも使える汎用ルールセットとみなさないでください。また、ドメイン例外を1つ追加するために、ルール体系全体を置き換える必要もありません。

最終チェックリスト

個別のサービス向け例外を先に置き、汎用GeoIPルールを後に置きます。MATCHは末尾に配置します。
ドメインルールにプロトコルやURLパスを含めず、ポリシー名を実際の設定と一致させます。
IPv4とIPv6を個別に確認します。IPv4で一度成功しても、デュアルスタックの通信経路がどちらも正しいとは限りません。
関連するルールを1グループずつ変更し、再読み込み後に新しい接続で確認してから次の変更に進みます。
適用ルールと最終ノードを記録します。タイムアウトが発生した場合は、プロキシノード、DNS、宛先サービスへの到達性をそれぞれ確認してください。

基本的な振り分けを安定させるには、ローカル向けとサービスごとの例外を優先し、次にドメインルール、未対応のアドレスにはGeoIP、最後の送出先にはMATCHを使います。各フィールドの詳細はプロトコルリファレンスをご覧ください。クライアントとプロキシ入口の設定がまだの場合は、まず設定ガイドに沿って通信がコアに入っていることを確認してください。