対象範囲：まずコアと通信経路を確認

中国国内外の通信を振り分ける設定は、中国国内のオフィス、動画、ダウンロードサービスは直接接続し、海外サービスは指定したプロキシグループを経由させたい場合に適しています。ここでいう「国内外」は、ルールデータベースがドメインやIPを分類した結果を指します。ページの言語、企業の登記地、ドメインの末尾だけで判定するものではありません。海外サービスでも中国国内のCDNを使う場合があるため、通常はドメインルールをIPの地理ルールより前に置きます。

この記事の設定例は、現在mihomoと呼ばれるClash Metaコアを対象としています。従来のClashや各種フォークでは、GEOSITE、ルールセット形式、データファイルの対応状況が異なります。クライアント名だけで判断せず、「バージョン情報」やコア情報の画面で実際のコアを確認してください。読み込み時に未知のルールタイプが表示された場合は、インデントを何度も調整するのではなく、まず互換性を確認しましょう。

  • 動作モード：クライアントの「プロキシ」または「モード」画面で「ルール」を選択します。グローバルモードでは、この記事の rules リストに沿った振り分けは行われません。
  • 通信経路：まずブラウザーからシステムプロキシ経由でテストします。システムプロキシに従わないアプリも制御する場合は、TUNを別途確認してください。TUNを有効にしても、ルール設定の代わりにはなりません。
  • プロキシグループ：以下では、既存のプロキシグループ 境外代理 を使用します。利用可能なノードが含まれ、proxy-groups に実際に定義されている必要があります。
  • バックアップ：作業前に現在の設定をエクスポートしてください。サブスクリプションを利用している場合は、更新でローカル変更が上書きされないよう、クライアントのオーバーライド、拡張、マージ機能を使うのがおすすめです。

ルールの適用順：上から確認し、最初に一致したルールを適用

ルールは「条件が細かいほど優先」と自動で並べ替えられるわけではありません。ここで紹介する一般的なルールは、リストの先頭から順に確認され、一致した時点でそのルールの動作が適用されます。後ろにより詳細なドメインルールを書いても、先に一致した広いルールは上書きされません。

rules:
  - DOMAIN,mail.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,境外代理
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,境外代理

この例では、mail.example.com は直接接続し、www.example.com は海外プロキシを使用します。どちらも後続のGEOIPルールでは判定されません。example.com はルールの動作を説明するための予約済みサンプルドメインであり、実際の接続テストに使うサービスではありません。

おすすめの配置順

  1. 特定のドメインを必ず直接接続、またはプロキシ経由にする個別の例外。
  2. NAS、ルーター、LAN内サービスが海外プロキシを経由しないよう、ローカルアドレス帯を指定。
  3. 明確に海外サービスと判断できるドメインルールやルールセット。
  4. 中国国内のドメインリストを置き、その後に中国国内のIP地理ルールを配置。
  5. 最後に MATCH を置き、いずれの分類にも当てはまらない通信を処理します。

GEOIP・GEOSITE・RULE-SETの違い

ルールタイプ判定対象主な書き方と用途
GEOIP接続先IPの地理的な分類GEOIP,CN,DIRECT,no-resolve は、中国国内のIP宛ての通信を処理します。
GEOSITEGeoSiteデータベースに登録されたドメインの集合GEOSITE,cn,DIRECT は、ドメインをもとに中国国内のサービスを判定します。
RULE-SET指定したrule-providerが提供するルールRULE-SET,overseas-domains,境外代理 は、別途管理するルールセットを参照します。

GEOIP：IPを判定するもので、サービス全体を識別するわけではない

GEOIP,CN は、使用する地理データベースに基づいて接続先のIPを判定します。データベースの更新が遅れることもあり、クラウドサービスやCDNの影響で、同じドメインでも地域の異なるIPに解決される場合があります。プロキシ経由にしたいサービスが明確な場合は、ドメインルールを優先してください。GEOIPルールひとつですべての要件を表現しようとしないことが大切です。

no-resolve は、このIPルールを確認するためにドメインを積極的にIPへ名前解決しない、という意味です。DNSを全体的に無効化する設定ではありません。接続に実際の宛先IPが含まれていれば判定対象になります。利用可能なIPがまだない場合はルールに一致せず、後続のルールに処理が移ることがあります。プロキシノードのアドレス解決やアプリ側の名前解決も、引き続き正常に行われます。

GEOSITE：GeoSiteデータファイルが必要

GEOSITE,cn を使うには、コアが cn カテゴリーを含むGeoSiteデータを読み込める必要があります。配布パッケージによってはデータがあらかじめ含まれている場合と、初回使用時にダウンロードする場合があります。ログにファイル不足やカテゴリー未登録のエラーが出たら、コアのデータディレクトリ、ダウンロード接続、データソースを確認してください。cn をWebサイトのドメインに置き換えるのは適切ではありません。GEOSITEのドメイン分類とGEOIPのIP分類は、別々のデータです。

RULE-SET：formatとbehaviorの組み合わせに注意

ルールセットを使うと、ルール本体をメイン設定から分離でき、定期更新にも便利です。behavior: domain はドメインの集合、ipcidr はIPアドレス帯の集合、classical はルールタイプを含む従来形式のルールリストに使用します。YAML、プレーンテキスト、MRSでは解析方法も異なります。URLだけを変更し、合わない format や behavior をそのまま残さないでください。

設定例：中国国内は直接接続、海外はプロキシ経由

以下は、既存のmihomo設定にマージできる rule-providers と rules の一式です。既存のノード、プロキシグループ、DNS設定はそのまま残してください。単独で動作するサブスクリプションファイルではありません。マージ前に既存のプロキシグループ名を 境外代理 にするか、コード内の同名の指定をすべて実際のグループ名に変更してください。

Loyalsoldierが公開するClash用ドメインルールセットのYAMLファイルを参照する例です。海外向けのルールを先に適用し、次に中国国内のルールを確認してから、GEOSITEとGEOIPで補完します。ドメインが複数のルールに含まれる場合、リストの上にあるルールが適用されます。中国国内ドメインの情報源を一つにまとめる場合は、国内向けのRULE-SETまたはGEOSITEのどちらかを削除し、不要になったproviderも併せて整理してください。

mode: rule

rule-providers:
  overseas-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt"
    path: ./ruleset/overseas-domains.yaml
    interval: 86400

  domestic-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/direct.txt"
    path: ./ruleset/domestic-domains.yaml
    interval: 86400

rules:
  - DOMAIN-SUFFIX,google.com,境外代理
  - DOMAIN-SUFFIX,github.com,境外代理
  - DOMAIN-SUFFIX,githubusercontent.com,境外代理
  - DOMAIN-SUFFIX,qq.com,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
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve

  - RULE-SET,overseas-domains,境外代理
  - RULE-SET,domestic-domains,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,境外代理

マージ時に確認する3つのポイント

  • トップレベルのキーは1つだけ：既存の rules: がある場合は、そのリストを編集してください。ファイル末尾に同じキーを追加してはいけません。キーの重複はエラーになったり、先に記述した内容が上書きされたりすることがあります。
  • 名前を完全に一致させる：RULE-SET の2番目の項目はprovider名と一致させます。最後の項目には、組み込みアクションまたは既存のプロキシグループを指定してください。名称、スペース、大文字・小文字も確認しましょう。
  • 必要なIPv6ルールを残す：アプリがIPv6を使う場合、IPv4のみのLAN・インターネット向けルールでは不十分です。トラブルシューティングを簡単にするために、システムのネットワーク機能を安易に削除しないでください。

ルールセットの更新：サブスクリプション、provider、地理データを区別

interval: 86400 の単位は秒で、24時間を表します。この設定が制御するのはHTTP rule-providerの更新確認です。ノードのサブスクリプションやGEOSITEが使うデータファイルは更新されません。メイン設定、ルールセット、地理データベースの更新状況は、それぞれ個別に確認してください。

  1. 設定を保存して再読み込みし、YAMLの解析エラーやプロキシグループ未定義のエラーがないことを確認します。
  2. クライアントのルールセット画面で overseas-domains と domestic-domains を確認します。画面の項目名はクライアントによって異なります。スイッチの状態だけでなく、ルール数、更新日時、エラーログも確認しましょう。
  3. 手動で一度更新し、ダウンロードが成功することを確認します。キャッシュ先の例はコアの作業ディレクトリにある ./ruleset/ です。システム上の固定された絶対パスではありません。
  4. 続けてノードのサブスクリプションを更新し、再読み込み後もカスタムルールが残っているか確認します。消えてしまう場合は、クライアントの永続化されるオーバーライド機能に変更を移してください。

初回起動時にルールの配布元へ直接接続できず、プロキシノードもまだ利用できない場合、ルールセットのダウンロードに失敗して起動が滞ることがあります。まず動作する基本設定を用意してからルールセットをダウンロードしてください。この項目に対応するmihomoでは、HTTP providerに proxy: 境外代理 を設定し、既存のプロキシグループ経由でダウンロードする方法もあります。グループは読み込み済みのノードを使うようにし、まだダウンロードできていないリソースへの依存が循環しないようにしてください。

オフラインで導入する場合は、対応するYAMLファイルをあらかじめ保存し、providerを type: file に変更します。正しい path、behavior、format を指定し、HTTPダウンロード関連の項目は削除してください。この場合、ファイルは手動で管理する必要があり、HTTPの更新間隔に従った自動取得は行われません。

振り分けを検証：Webページが開くかだけでなく、一致したルールを確認

クライアントの「接続」画面を開き、直接接続するドメインとプロキシ経由にするドメインへ、それぞれアクセスします。接続先ホスト、一致したルール、プロキシ経路、接続先IPを確認してください。Webページが表示されても、通信が期待した経路を通った証明にはなりません。ノード選択画面でノードを選んでも、すべての通信がそのノードを経由するとは限りません。

テスト用の入口を固定して条件を絞る

現在の設定で混合ポートに 7890 を使っている場合は、次のコマンドをターミナルで実行できます。ポートが異なる場合は実際の値に置き換えてください。このコマンドはHTTPリクエストの確認用です。システム全体のTUN制御範囲を検証するものでも、速度測定でもありません。

curl -I --proxy http://127.0.0.1:7890 https://www.qq.com/
curl -I --proxy http://127.0.0.1:7890 https://github.com/

この記事のルールでは、1つ目のリクエストは DOMAIN-SUFFIX,qq.com に一致して直接接続し、2つ目は DOMAIN-SUFFIX,github.com に一致して海外プロキシグループへ進みます。サーバーがリダイレクトを返したり、HEADリクエストを拒否したりする場合もあります。振り分けの判断はクライアントの接続ログを基準にしてください。

よくある症状と対処方法

  • 常にMATCHに一致する：接続ログにドメインが表示されているか、providerの読み込みが成功しているか、GEOSITEのカテゴリーが利用可能かを確認します。IPアドレスを直接指定した通信は、通常のドメインルールには一致しません。
  • 変更後も以前のノードを使う：既存の長時間接続は、以前のルールを引き続き使うことがあります。接続を新しく作り直し、新しい一致ログを確認してください。接続を使い回しているアプリの画面を更新するだけでは不十分です。
  • 海外サービスがGEOIPで直接接続される：サービスのドメインルールが不足していないか確認し、GEOIPより前に追加してください。一度の名前解決結果でサービス全体の接続先を決めつけないようにしましょう。
  • ブラウザーと他のアプリで結果が異なる：システムプロキシ、アプリ独自のプロキシ、TUNルート、ブラウザーのセキュアDNSを確認します。スニッフィングで一部のプロトコルからドメインを取得できる場合はありますが、すべての暗号化通信からドメインを取得できるわけではありません。
  • fake-ip使用時に仮想アドレスが表示される：これはDNSマッピングの仕組みによるものです。通常、コアはマッピング情報からドメインを復元します。fake-ipのアドレスプールを実際の海外IPとみなして、プロキシ用IPリストに追加しないでください。

メンテナンスの進め方：例外を少しずつ追加し、ルールセットを拡張

日常的なメンテナンスで、似たルールを次々に追加する必要はありません。「個別の例外、ドメインリスト、IPによる補完、最後のフォールバック」の4段階を基本にし、実際の接続ログを見て問題に対処しましょう。ルールを追加する際は、対象ドメイン、適用するポリシー、追加理由を記録します。テストに成功してから他のデバイスにも反映してください。

複数のデバイスで同じサブスクリプションを使っていても、すべてのコアが同じ設定を解釈できるとは限りません。他のデバイスにコピーする前に、GEOSITE、IPv6、provider形式、カスタムオーバーライドの対応状況を確認してください。詳しい手順はサブスクリプションのインポート方法をご覧ください。通信経路に問題がある場合は、システムプロキシ設定とポートの説明も確認してください。

最終確認では、設定が正常に読み込まれること、中国国内と海外向けのテスト通信がそれぞれ想定したルールに一致すること、ルールセットの手動更新に成功し、サブスクリプション更新後もカスタム設定が残ることの3点を確認します。すべて確認してから普段使うアプリに適用しましょう。DNS、TUN、すべてのルールを一度に変更するより、問題の切り分けが簡単になります。