Clashの中国国内・海外トラフィック分岐設定：ルールの順序とプロキシグループ実践ガイド

Routing model

中国国内・海外トラフィックの分岐モデルを理解する

Clashのトラフィック分岐は、「現在のサイトが中国国内か海外か」を単純に判定する仕組みではありません。設定ファイルのルールを上から順に確認し、各接続を判定します。ルールは、ドメイン、ドメインの末尾、IPアドレス、宛先ポート、プロセス名、外部ルールセットなどを条件にできます。条件に一致すると、接続は指定されたプロキシグループ、プロキシノード、または組み込みアクションに渡されます。一般的な DIRECT、PROXY、REJECT は、それぞれ直接接続、PROXYという名前のプロキシグループで処理、接続拒否を意味します。

つまり、「中国国内は直接接続し、それ以外はプロキシ経由にする」というのは目標であって、すべてをカバーできる単独のルールではありません。実際の設定では、まずLANや明確な例外を処理し、その後に特定のドメイン、地域別ドメイン、宛先IPを判定し、最後にどのルールにも一致しなかった接続をフォールバックルールで受け止めます。海外ドメインを使っていてもサーバーが中国国内にあるサイトや、中国国内のドメインを使いながら海外のAPIに依存するサービスでは、地域データベースだけでは意図と異なる結果になることがあります。より具体的なドメインルールを追加してください。

「ルールに一致した際のプロキシ」と「最終的に使われるノード」は区別する必要があります。たとえば、ルールが接続を 海外トラフィック プロキシグループに渡しても、そのグループが 自動選択 や 香港ノード などの下位グループを参照している場合があります。ログで「海外トラフィック」に一致したことが分かっても、それが最終出口とは限りません。プロキシグループの現在の選択項目と、接続詳細に表示される経路を確認してください。

ルールまたはアクション	役割	配置に適した位置
`DOMAIN`	完全一致するドメインを指定	汎用ドメインルールより前
`DOMAIN-SUFFIX`	ドメインとそのサブドメインに一致	地域・IPルールより前
`RULE-SET`	ルールプロバイダーのルールセットを参照	ルールセットの具体性が高い順
`GEOIP`	宛先IPの所在地域で判定	ドメイン系ルールの後
`MATCH`	それまでに一致しなかった接続を受け取る	ルールリストの最後

Rule order

ルールは上から順に評価し、具体的なルールを優先する

mihomoが接続を処理するときは、rules の先頭から下へ確認し、最初に条件へ一致したルールで接続の方針を決定します。後続のルールは評価されません。ルールの内容は正しくても配置が不適切、というのは地域別振り分けで最もよくある設定ミスです。たとえば、対象範囲の広い中国国内向けドメインルールを先に記述し、その後に特定ドメインだけをプロキシ経由にする例外を置くと、後者は決して適用されません。

より確実な並べ方は、「最も具体的なルール」から「最も広範なルール」へ段階的に移行することです。LAN、ループバックアドレス、家庭内機器のドメインは通常、直接接続にします。プロキシ経由または直接接続が必須のサービスドメインは手動で指定する例外として扱い、広告やトラッキング用ドメインを拒否するかどうかは、ページの機能を確認したうえで慎重に判断します。その後に地域別ドメイン、地域別 IP、最終的なフォールバックをまとめて配置します。サブスクリプションごとに提供されるルール名は異なりますが、並び順の原則は変わりません。

ローカルネットワークとプライベートアドレス：ルーターの管理画面、NAS、プリンター、LAN内サービスには通常 DIRECT を使い、遠隔ノードを経由しないようにします。
手動指定の例外：必ずプロキシ経由、必ず直接接続、または特定の出口を必要とする完全なドメイン名とドメイン末尾の条件を、汎用ルールより前に配置します。
サービス別ルールセット：開発プラットフォーム、動画配信、インスタントメッセージなど、サービスの種類ごとにメンテナンスされたルールセットを参照します。
中国国内のドメインとIP：ドメインベースの地域ルールを GEOIP より優先し、名前解決後のIPだけに依存することによるズレを抑えます。
最終フォールバック：MATCH を既定のプロキシグループに向け、分類されなかった接続にも明確な行き先を与えます。

「既知の中国国内リソースは直接接続し、それ以外は既定でプロキシ経由」にしたい場合、フォールバックは地域判定ではなくプロキシグループに向けます。反対に、少数のサービスだけをプロキシ経由にしたい場合は、それらを先に列挙し、最後を MATCH,DIRECT で終えます。どちらが絶対に優れているわけではなく、既定の動作とメンテナンスコストが異なります。

Proxy groups

プロキシグループでルールの意図とノード選択を分離する

海外向けの各ルールを特定のノードへ直接割り当てる方法は一見簡単ですが、サブスクリプション更新でノード名が変わると、多数のルールが機能しなくなります。保守しやすい方法は、ルールから安定したプロキシグループ名を参照し、ノード、自動テストグループ、他のプロキシグループをグループ側で管理することです。ルールは「この種類のトラフィックをどう処理するか」を表し、プロキシグループは「現在どの出口で実行するか」を決めます。

実用的な構成は通常、総合入口、地域選択、自動テストの3層で構成します。総合入口は 海外トラフィック などの名前にし、種類には select を指定して、自動グループ、特定地域のグループ、DIRECT を手動で選べるようにします。地域グループではサブスクリプション内の該当ノードを参照するほか、proxy-providers とフィルター条件でノードを動的に取得できます。自動グループでは url-test で候補ノードを定期的に測定し、結果に基づいて遅延の低い出口を選択します。

url-test の結果は、測定先がその時点で応答した状況を示すだけで、すべてのサイトでの実速度を保証するものではありません。地域間の経路、接続先の制限、ノードの負荷によって体感は変わります。ログイン地域に左右されるサービス、固定地域を必要とする用途、安定した出口が必要な業務では、頻繁に切り替わる自動グループより手動の地域グループの方が管理しやすいでしょう。

proxy-groups:
  - name: 海外トラフィック
    type: select
    proxies:
      - 自動選択
      - 香港ノード
      - 日本ノード
      - DIRECT

  - name: 自動選択
    type: url-test
    proxies:
      - HK-01
      - JP-01
      - SG-01
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 中国国内トラフィック
    type: select
    proxies:
      - DIRECT
      - 海外トラフィック

上の例にあるノード名は、proxies に実際に存在する名前と一致していなければなりません。ノードがプロキシプロバイダーから提供される場合は、存在しないノード名をそのまま書き写すのではなく、グループ内で対応する use 設定を使用します。設定の参照関係には厳密な要件があります。ルールが参照するプロキシグループ、プロキシグループが参照するノードや下位グループは、すべて設定内で定義済みでなければなりません。Clash Verge Revでサブスクリプションをインポートした後はグループ名が異なる場合があるため、変更前に現在の設定構造を確認してください。

YAML practice

例外からフォールバックまで、トラフィック分岐を実践する

以下のルール断片は、よくある考え方を示したものです。ローカルアドレスは直接接続し、指定した開発サービスはプロキシ経由にし、明確な中国国内サービスは直接接続します。その後、地域データで一般的なケースを処理し、最後に未識別のトラフィックを海外用プロキシグループへ渡します。これは構成例であり、既存のサブスクリプションをそのまま置き換えるものではありません。実際の設定には、ポート、DNS、ノード、プロキシグループ、必要に応じてルールプロバイダーの定義も含める必要があります。

rules:
  - DOMAIN,router.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

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

  - DOMAIN-SUFFIX,gov.cn,DIRECT
  - DOMAIN-SUFFIX,example.cn,DIRECT

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

GEOSITE はmihomoがサポートする地理ベースのサイトルールで、対応する地理データファイルに依存します。データの読み込み方法やルールセットは設定によって異なります。現在の設定で利用可能なGeoSiteデータがない場合は、定義済みの RULE-SET を使うか、必要なドメインルールを管理してください。読み込めないデータ参照を1行追加するだけでは不十分です。GEOIP は宛先IPから地域を判定するため、ドメインルールでカバーできない接続を補完するのに適しています。

no-resolve は、カーネルに対して「このIP系ルールを確認するとき、宛先IPを取得するための追加のドメイン解決を自動的に開始しない」よう指示します。一部の IP-CIDR と GEOIP ルールの末尾に付けるのに適していますが、クライアント全体のDNS機能を無効にするものではありません。接続コンテキストに宛先IPがすでに含まれていれば、ルールは通常どおり判定できます。

外部ルールプロバイダーを使う場合は、ルール本体と更新元を分離できます。ルールプロバイダーには、動作タイプ、形式、保存先、更新間隔を定義し、その後で rules から RULE-SET を使って参照します。以下は論理関係を示す例です。URLとファイル名は、実際に管理されている提供元の有効な内容へ置き換えてください。

rule-providers:
  local-direct:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/local-direct.yaml
    url: https://rules.example.com/local-direct.yaml
    interval: 86400

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,海外トラフィック

ルールセットの behavior はファイルの内容と一致していなければなりません。domain はドメイン形式のペイロード、ipcidr はネットワークセグメント形式のペイロード、classical はルールタイプを含む従来形式のルールに使用します。形式が一致しないと、ルールプロバイダーの更新に失敗したり、ペイロードを解析できなかったりします。リモートルールセットには安定した更新元も必要です。更新元に一時的にアクセスできない場合、通常は保存済みのローカルファイルを使い続けますが、初回取得に失敗すると利用できるキャッシュがない可能性があります。

DNS and TUN

DNS、システムプロキシ、TUNが結果に与える影響

ルール自体は接続先を決めますが、クライアントが接続を受け取れるか、ドメインを正しく復元できるか、名前解決のリクエストがどこへ向かうかによって、最終的な観測結果は変わります。システムプロキシが適用されるのは、OSのプロキシ設定に従うアプリだけです。一部のゲーム、コマンドラインツール、仮想マシン、独自のネットワークスタックを使うソフトウェアはシステムプロキシを迂回することがあります。その場合、ルールをどれだけ整えても、mihomoに入っていないトラフィックは接続一覧に表示されません。

TUNモードは仮想ネットワークインターフェースを通じて、より広範なTCP・UDPトラフィックを取り込みます。システムプロキシ設定を読み取らないプログラムも対象にしたい場合に適しています。TUNを有効にしても、ルールを上から順に評価する原則は変わりません。ルールエンジンに入るトラフィックの範囲が広がるだけです。TUNはシステム権限、ルーティングテーブル、他のVPNソフトウェアやセキュリティツールの影響も受けるため、まずシステムプロキシモードで基本的な分岐を確認し、必要に応じて有効にしてください。

DNS設定は、「ルールは正しいように見えるのに結果が一致しない」原因になりやすい部分です。fake-ip モードでは、クライアントが予約アドレスを先に返し、内部でドメインと接続の対応関係を保持するため、後続のルールでドメインによる判定ができる場合があります。一部のLANサービス、デバイス検出、仮想アドレスに対応しないプログラムでは、fake-ip-filter への追加が必要です。redir-host などのモードでは名前解決と接続確立の方法が異なりますが、DNSクエリが他のプログラムによって完全に迂回されていないことを確認する必要があります。

ドメインがシステム外部で先にIPへ解決されると、カーネルが受け取る接続にドメインルール用の情報が残らず、IP系ルールや MATCH にしか一致しないことがあります。ドメインルールに一致しない問題を調べるときは、YAMLの綴りだけでなく、接続詳細に表示される宛先ホスト、名前解決結果、一致したルールも同時に確認してください。

Verification

変更後に実際のトラフィック経路を確認する方法

トラフィック分岐の検証は、ウェブページが開くかどうかだけでは不十分です。直接接続でもプロキシ経由でもアクセスできる場合がありますが、遅延、出口の所在地、一致するルールは異なります。信頼できる確認には、設定の読み込み状態、接続詳細、一致したルール、プロキシグループの選択、外部から見える出口情報を組み合わせ、毎回1種類の条件だけを変更します。

手順1：設定が正常に読み込まれたことを確認する

YAMLを保存したら、クライアントの通知とカーネルログを確認し、インデント、フィールドの型、重複した名前、ルールプロバイダーの解析エラーがないことを確認します。YAMLはスペースで階層を表すため、Tab文字や誤ったインデントで読み込みに失敗することがあります。クライアントが古い設定を使い続けていると、以降のテストに変更内容が反映されません。

手順2：既存の接続を終了してからテストする

ブラウザーはHTTP/2、HTTP/3、長時間接続を再利用し、アプリも接続プールを保持することがあります。ルールを変更しても、すでに確立された接続では新しい出口が自動的に選び直されないのが通常です。対象の接続を閉じ、アプリを再起動するか、クライアントで該当接続を終了してから新たにアクセスしてください。DNSキャッシュも比較結果に影響するため、必要に応じてキャッシュの有効期限を待つか、システムの方法で更新します。

手順3：接続詳細と一致までの経路を確認する

Clash Verge Revの接続画面で対象ドメインを見つけ、一致したルールタイプ、ルールの内容、プロキシグループ、最終ノードを確認します。DOMAIN-SUFFIX への一致を期待しているのに MATCH と表示される場合は、ドメインがそのルールに届いていない、前のルールに先に捕捉されている、または接続にIP情報しか残っていない可能性があります。プロキシグループは正しいのにノードが違う場合は、ルールを変更せず、プロキシグループ画面で現在の選択項目を確認してください。

手順4：直接接続とプロキシの出口を個別に確認する

直接接続として明確に設定した対象と、プロキシ経由として明確に設定した対象を1つずつ選び、結果を比較します。必要に応じて信頼できる出口IP確認サービスでグローバルIPを確認しますが、サービスごとに利用するネットワーク、キャッシュ、IP地理データベースが異なる点に注意してください。地域ラベルは補助的な証拠にすぎず、最も重要なのはクライアントに表示される一致ルールと経路です。

直接接続の対象には DIRECT が表示されるか、プロキシグループに一致した後、そのグループで DIRECT が選択されている必要があります。
プロキシ対象には想定したプロキシグループが表示され、その経路をたどって実際のノードに到達している必要があります。
拒否ルールでは接続がブロックされます。同時に、ページに必要なAPIや静的リソースまで壊れていないことを確認してください。
UDP、QUIC、TCPでは別々の接続が作られることがあるため、調査時はプロトコルの種類にも注意してください。

Troubleshooting

分岐結果に異常がある場合の確認手順

中国国内のサイトなのにプロキシ経由になる

まず、中国国内向けルールより前に、トップレベルドメイン全体や大規模なルールセットを対象にする広範なプロキシルールがないか確認します。次に、中国国内用プロキシグループで本当に DIRECT が選択されているかを確認してください。GEOIP,CN,DIRECT しか設定しておらず、対象が海外CDNのアドレスを使っている場合は一致しないことがあります。安定したサービスには、明確なドメイン直接接続ルールを追加できます。

海外サービスがときどき直接接続になる

対象が複数のサービスドメインを含んでいないか確認します。現代のウェブサイトは、ログイン、API、画像、動画、統計用のドメインへ同時にアクセスすることが多く、メインドメインだけをプロキシにしてもすべてのリクエストはカバーできません。接続一覧から実際のドメインを集め、必要なドメイン末尾の条件を追加するか、適切にメンテナンスされたサービス用ルールセットを利用します。確認できた一時的なCDNホストをすべて完全一致ルールにするのではなく、安定したドメインの範囲を優先して見極めてください。

ルールは正しいのにサービスが使えない

プロキシルールに一致したことは、接続が該当する方針へ渡されたことを示すだけで、ノードの到達性を保証するものではありません。プロキシグループで有効なノードが選択されているか、必要なUDP通信にノードが対応しているか、DNSが正常か、対象サービスが出口地域を制限していないか、システム時刻が正確かを続けて確認します。同じグループ内の別ノードへ一時的に切り替えて比較すれば、ルールの問題かノード経路の問題かを切り分けられます。

TUNを有効にしたらLAN内のデバイスに接続できなくなった

プライベートネットワークのルールが前方にあり、DIRECT を指定していることを確認します。併せて、TUNの自動ルート、厳格ルート設定、システム内の他の仮想ネットワークアダプターも確認してください。ホスト名でLANデバイスへ接続している場合は、ローカルドメインの名前解決や検索ドメインがリモートDNSに置き換えられていないことも確認します。まずデバイスのIPアドレスで試すと、ルーティングの問題とローカル名前解決の問題を切り分けやすくなります。

サブスクリプション更新後にカスタムルールが消えた

サブスクリプションから生成された設定を直接編集すると、次回の更新で新しい内容に上書きされることがあります。Clash Verge Revでは、設定のマージ、スクリプト、オーバーライド機能によってローカルの変更を保持できます。具体的な入口は、バージョンや設定管理方法によって異なります。実施前に利用可能な設定をバックアップし、カスタムのプロキシグループとルールを独立した確認しやすい断片として管理してください。サブスクリプション更新後は、参照先の名前が引き続き存在することを確認します。

Checklist

継続的に保守できるトラフィック分岐チェックリスト

安定した中国国内・海外のトラフィック分岐に必要なのは、無制限にルールを積み重ねることではなく、明確な既定方針と必要最小限の例外です。設定が完了したら、次のチェックリストで確認してください。

LANとプライベートアドレスのルールが前方にあり、DIRECT が明示されている。
必ずプロキシ経由、または必ず直接接続するサービスドメインが、地域別の汎用ルールより前にある。
ルールが参照するプロキシグループ名が、設定内の定義と完全に一致している。
プロキシグループが参照するノード、下位グループ、プロキシプロバイダーが実際に存在している。
地域別ドメインルールが地域別IPルールより前にあり、MATCH が末尾にある。
外部ルールセットの動作タイプ、ファイル形式、ペイロードの内容が一致している。
変更後に既存の接続を終了し、接続画面でルール、プロキシグループ、最終ノードを確認している。
システムプロキシで対象プログラムをカバーできない場合に、TUNモードが必要かを検討している。
サブスクリプション更新後にカスタムオーバーライドを再確認し、名前の変更でプロキシグループの参照が切れていない。

設定で重要なのはルールの数ではなく、すべての接続が説明可能な経路をたどって明確な方針に到達することです。まず少数のルールで「ローカルは直接接続、指定した例外、地域判定、最終フォールバック」という骨格を作り、接続履歴を見ながら実際の要件を補完してください。複数の重複したルールセットを最初から導入するより、保守もトラブルシューティングも容易になります。