Clashのルールと分流を実践：中国本土は直接接続、日本など海外はプロキシにする完全設定ガイド

まず分流の方針を決める：ドメインで判定し、IPで取りこぼしを補う

「中国本土は直接接続、海外はプロキシ」という設定は、全トラフィックを単純に2つの地域へ分けるものではありません。Clashが処理するのは接続リクエストであり、ドメイン名だけを含む場合、接続先IPだけを含む場合、またはDNS解決後に接続を確立する場合があります。信頼性の高い設定では、まずドメインルールで接続先を判定し、IPの地域判定で取りこぼしを補い、最後にどのルールにも一致しない通信をフォールバックルールで処理します。

Clash Meta、つまり現在広く使われているmihomoカーネルを例にすると、接続はrulesに記述された順番で上から下へ確認されます。最初に一致したルールが、その接続をどのプロキシグループへ送るかを直ちに決定し、後続のルールは実行されません。そのため、ルールの種類をそろえることは基本であり、並び順も最終結果を左右します。

トラフィックの種類	推奨する処理	主な判定基準	典型例
LANとローカルアドレス	`DIRECT`	プライベートドメイン、プライベートIPレンジ	`192.168.1.1`、`10.0.0.0/8`
明確に中国本土向けのサイト	`DIRECT`	GEOSITEまたはドメインルールセット	中国本土の動画・決済・地図サービス
中国本土のIPに解決された接続	`DIRECT`	`GEOIP,CN`	ドメインデータベースに未収録の中国本土向けサービス
プロキシを明示的に指定するサービス	`PROXY`	個別ドメインルールまたはルールセット	常にプロキシを経由させたい開発サービス
その他、一致しなかった接続	`PROXY`	`MATCH`	新しいドメイン、マイナーなドメイン、未知の接続先

GEOIP,CNだけでは不十分な理由

GEOIP,CN,DIRECTで地域を判定できるのは、カーネルが接続先IPを取得した後です。接続がまだドメインマッチングの段階にある場合や、DNSがFake-IPモードの場合、GEOIPだけではドメイン単位の分流を完全には表現できません。また、CDNノードの場所は、サービスの所属地域と必ずしも一致しません。同じドメインでも、ネットワーク、時間帯、DNSの応答によって異なる地域のIPが返されることがあります。

より安定する構成は「ドメインを優先し、IPで補完」です。まずGEOSITE,cn,DIRECTまたは中国本土向けドメインルールセットで既知のサイトを処理し、次にGEOIP,CN,DIRECTで、未収録でも中国本土のアドレスへ解決された接続を受けます。これにより不要なDNS依存を抑えながら、IPだけで行われるアクセスもカバーできます。

GEOIP、GEOSITE、RULE-SETの役割

GEOIP：接続先IPの地域情報でマッチング

GEOIPルールは、IPアドレスと地域コードの対応関係を参照します。一般的なGEOIP,CN,DIRECTは、接続先IPが中国本土のアドレスと判定された場合に直接接続する、という意味です。中国本土向け通信の取りこぼし対策には適していますが、ドメイン分流全体を単独で担わせるものではありません。

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolveパラメータは、このIPルールを照合する際に、接続先IPを取得するためのドメイン解決を能動的に行わないことを示します。たとえばGEOIP,CN,DIRECT,no-resolveは、ルール照合時の追加DNS問い合わせを避けられますが、リクエストがドメイン名しか持たない場合は一致しない可能性があります。このパラメータを付けるかどうかは、前段に十分なドメインルールがあるかを踏まえて判断してください。

GEOSITE：ドメイン集合でマッチング

GEOSITEは、mihomoなどのカーネルがサポートするドメイン分類機能です。GEOSITE,cn,DIRECTを使うと、geositeデータベースでcnに分類されたドメインを直接接続のポリシーへ渡します。現在どのIPへ解決されたかではなく、ドメインがどの種類のサイトに属するかを表すため、「このサービスはどのカテゴリか」という分流に適しています。

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

GEOSITEが正常に使えるかどうかは、カーネルと地理データファイルに左右されます。旧版Clashカーネル、異なる派生クライアント、mihomoのデータモードは完全には統一されていません。設定時にunsupported rule type GEOSITEと表示された場合、ルールの順番を調整し続けるのではなく、まずクライアントが使用しているカーネルの種類を確認し、クライアントのカーネルまたは地理データ更新画面から更新してください。

RULE-SET：外部ルールファイルをメイン設定に組み込む

ルールが数百、数千件に達すると、すべてをメイン設定のrulesに詰め込むのは適切ではありません。rule-providersで個別のルールファイルを定義し、RULE-SETから参照できます。更新、分類、確認がしやすくなり、ルールを保守するたびにプロキシグループやDNS設定を変更する必要もなくなります。

rule-providers:
  cn-domain:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml

  direct-extra:
    type: file
    behavior: classical
    format: yaml
    path: ./ruleset/direct-extra.yaml

rules:
  - RULE-SET,direct-extra,DIRECT
  - RULE-SET,cn-domain,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior: domainはドメイン項目だけを含むルールセットに適しています。behavior: ipcidrはIPレンジ用、behavior: classicalはDOMAIN、DOMAIN-SUFFIX、IP-CIDRなどの完全なルールを保存できます。ルールファイルのbehaviorは内容と一致させる必要があり、異なると読み込み失敗や項目の不一致が起きる可能性があります。

中国本土向けのドメインルールファイルは、次のように記述できます。

payload:
  - '+.bilibili.com'
  - '+.jd.com'
  - '+.taobao.com'
  - 'cn.bing.com'

ここでの+.example.comは、メインドメインとサブドメインを表します。特定のホスト名だけに一致させる場合は、サフィックス形式ではなく完全なドメイン名を記述してください。ファイルを変更した後は、クライアントで設定をリロードする必要があります。保存しただけでリロードしなければ、実行中のカーネルは新しいルールを自動的に適用しません。

そのまま調整できるプロキシグループとルールの基本構成

以下の設定では、メインのプロキシグループ、自動速度テストグループ、フォールバックルールを1つずつ用意しています。ノード名は、実際にサブスクリプションから提供される名前に合わせてください。サブスクリプションからプロキシノードを生成するクライアントでは、次回更新で上書きされる一時ファイルを直接編集せず、サブスクリプションの上書き設定または設定マージ機能にプロキシグループを追加するのが一般的です。

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
      - 香港ノード
      - 日本ノード
      - シンガポールノード

  - name: AUTO
    type: url-test
    proxies:
      - 香港ノード
      - 日本ノード
      - シンガポールノード
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mode: ruleはルール分流を有効にする前提です。クライアントが現在Globalモードの場合、すべての接続がグローバルプロキシグループに統一されます。Directモードの場合は、すべての接続がプロキシを迂回します。「ルールに一致しない」問題の多くは、実際には実行モードがRuleに切り替わっていないことが原因です。

url-testは指定したURLへ定期的にアクセスし、ノードの遅延を測定します。例のinterval: 300は300秒ごとにテストする設定で、tolerance: 80は現在のノードとより速いノードの遅延差が80ミリ秒を超えた場合にのみ切り替えを検討する設定です。頻繁な速度テストは通信と電力消費を増やすため、デスクトップでは通常300～600秒程度が適しています。

サブスクリプションプロバイダーを使う場合のプロキシグループ設定

ノードがproxy-providersから提供される場合、プロキシグループでuseを使ってプロバイダーを参照できます。これにより、各ノード名をメイン設定へ書き込む必要がなくなります。以下は、airportという名前のプロキシプロバイダーがすでに設定されていることを前提とした構成です。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
    use:
      - airport

  - name: AUTO
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

サブスクリプションを更新すると、新しいノードはそのプロバイダーを参照するプロキシグループに追加されます。クライアントが設定マージに対応している場合は、カスタムルールとプロキシグループを上書きファイルに置くのがおすすめです。入口は通常「設定」→「設定ファイル」→「上書き」または「サブスクリプション」→「設定編集」にあります。クライアントによってメニュー名は異なりますが、考え方は同じです。元のサブスクリプションを保持し、ローカルの分流ロジックを独立したマージ層として追加します。

DNSとFake-IPが分流結果に与える影響

ルールが正しそうなのに中国本土のサイトまでプロキシを経由する場合、DNSは必ず確認すべき層です。ClashがDNSを引き受けると、ドメイン解決、ルールのスニッフィング、接続確立が連携して動作します。システムDNS、ブラウザーのセキュアDNS、Clash DNSが同時に動作していると、一部のリクエストがカーネルによるドメイン判定を迂回し、最終的にIP情報だけが残る場合があります。

mihomoでよく使われるFake-IP設定は次のとおりです。リッスンポートに1053を指定してシステムの53番ポートを直接占有しないようにし、クライアント側でシステムDNSのリクエストをこのリッスンアドレスへ転送します。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

Fake-IPモードでは、まずアプリに198.18.0.0/16範囲の予約アドレスを返し、カーネルがFake-IPと元のドメインの対応を保存します。そのため、アプリが後からIPへ接続しても、カーネルはドメインを復元してDOMAIN、GEOSITE、ドメインルールセットを実行できます。LAN機器の検出、プリンター、一部のログインコンポーネントなど、Fake-IPに適さない通信はfake-ip-filterへ追加してください。

ブラウザーのセキュアDNSが判定を妨げる理由

ブラウザーで独立したDoHを有効にすると、DNS問い合わせがHTTPSトラフィックとしてブラウザー指定の解決サービスへ送られることがあります。ClashはこのHTTPS接続をプロキシできますが、その後のサービスドメインについて、システムDNSと一致する対応関係を取得できるとは限りません。切り分け中はブラウザーのセキュアDNSを一時的に無効にするか、「現在のサービスプロバイダーを使用」に設定し、ブラウザーのDNSキャッシュを消去してから再テストしてください。

Windowsではまずipconfig /flushdnsを実行してシステムキャッシュを消去します。Chromium系ブラウザーでは、古い接続の再利用による誤判定を排除するため、関連プロセスを完全に終了してから再起動してください。DNS設定を変更した後は、クライアントで「設定」→「リロード」を実行し、システムプロキシまたはTUNを切断して再接続します。

システムプロキシとTUNモードの選び方

システムプロキシは通常、HTTPとHTTPSのリクエストをmixed-port: 7890へ送ります。システムプロキシ設定に従うブラウザー、ダウンローダー、開発ツールはClashを経由できますが、一部のゲーム、コマンドラインプログラム、ストアアプリ、独自のネットワークスタックを実装したソフトウェアはシステムプロキシを迂回することがあります。

TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のTCP、UDP、DNSトラフィックを引き受けます。デスクトップ環境で通信を一元的に分流したい場合に適しています。mihomoの基本設定は次のように記述できます。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack: mixedはシステムスタックとの互換性とUDP処理を両立します。auto-routeはルートを自動的に追加し、auto-detect-interfaceは現在の出口ネットワークインターフェースを識別します。strict-routeはTUNを迂回する通信を減らします。TUNの有効化には通常、管理者権限が必要です。初回起動時には、仮想NICやネットワーク拡張機能の許可を求められることもあります。

利用シーン	推奨モード	確認ポイント
主にブラウザーとシステムプロキシ対応ソフトを使う	システムプロキシ	HTTPプロキシが`127.0.0.1:7890`を指しているか
コマンドライン、ストアアプリ、ゲームも一元的に接続を引き受けたい	TUN	管理者権限、仮想NIC、ルーティングテーブル
ルール設定だけを検証したい	まずシステムプロキシを使う	ルーティングとDNSリダイレクトの変数を減らす
TUNを有効にするとLAN機器へアクセスできない	strict-routeとプライベートネットワークのルールを確認	`GEOSITE,private`、`GEOIP,private`

中国本土は直接接続、海外はプロキシになっているか確認する方法

ステップ1：実行モードと設定のリロードを確認

クライアントのホーム画面で、実行モードがRuleまたはルールモードになっていることを確認します。
「設定」→「現在の設定」を開き、先ほど編集したファイルが有効になっていることを確認します。
「設定」→「リロード」を実行します。TUNを変更した直後なら、いったん切断してから再接続してください。
ログレベルは一時的にinfoへ設定します。最初から出力量の多いdebugを使う必要はありません。

ステップ2：接続一覧で一致したルールの経路を確認

クライアントの「接続」または「Connections」画面を開き、中国本土向けサイトとプロキシが必要なサイトへそれぞれアクセスします。中国本土向けのリクエストには、GEOSITE,cn → DIRECT、RULE-SET,cn-domain → DIRECT、GEOIP,CN → DIRECTなどが表示されます。その他のリクエストには、MATCH → PROXY → 具体的なノードが表示されます。

1つのWebページは通常、メインドメイン、画像CDN、アクセス解析、ログインAPI、サードパーティーリソースを同時にリクエストします。そのため、接続一覧にDIRECTとPROXYが同時に表示されても、必ずしもエラーではありません。判断する際は個別の接続を選択し、接続先ドメイン、一致したルール、プロキシグループ、最終ノードを確認してください。ページのメインドメインだけを見て判断してはいけません。

ステップ3：コマンドラインでブラウザーキャッシュを回避

システムプロキシモードでは、ローカルの混合ポートを明示してテストできます。次の2つのコマンドはいずれも127.0.0.1:7890を通じてClashへ入り、その後ルールによって直接接続かプロキシかが決まります。

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com
curl -I --proxy http://127.0.0.1:7890 https://www.google.com/generate_204

コマンドの実行中は、接続パネルも同時に確認します。1つ目のリクエストは通常、中国本土向けドメインルールまたは中国本土IPルールに一致し、2つ目はPROXYへ進みます。HTTPステータスコードは接続先が応答したかどうかを示すだけです。最終的な分流結果は、接続詳細に表示されるルール経路と最終ポリシーで判断してください。

よくある異常と切り分けの順番

中国本土のサイトがすべてPROXYへ送られる

GEOSITE,cn,DIRECTとGEOIP,CN,DIRECTがMATCHより前にあることを確認します。
カーネルがGEOSITEをサポートしているか、地理データファイルが読み込まれているかを確認します。
現在のモードが誤ってGlobalになっていないか確認します。
接続詳細で、接続先がドメインかIPかを確認します。IPしか表示されない場合は、DNSが別のプログラムに迂回されていないかを調べます。
一部のドメインだけに影響する場合は、それらをローカルのDIRECTルールセットへ追加し、プロキシグループ全体を直接接続へ変更しないでください。

海外サイトがMATCHになるのにアクセスできない

MATCH,PROXYに一致するのは、ルールの選択が正しいことを示すだけで、プロキシグループ内のノードが利用できるとは限りません。接続経路をさらに展開し、PROXYが最終的にどのノードを選択したかを確認します。DIRECTで止まっている場合は、プロキシグループが手動で直接接続へ切り替えられています。ノードが選択されているのに接続がタイムアウトする場合は、ノードの状態、サブスクリプションの更新、対象プロトコルへの対応を確認してください。

ルールファイルを更新しても変化がない

type: fileのローカルルールは自動ダウンロードされません。変更後は必ず設定をリロードしてください。
type: httpのルールプロバイダーはintervalによって更新されます。クライアントのプロバイダーページから手動で更新することもできます。
pathが、クライアントからアクセスを許可された設定ディレクトリを指しているか確認します。
YAMLのインデントを確認します。リスト項目の前には通常、半角スペース2つとハイフンを置き、タブを混在させないでください。
behaviorとファイル内容が一致していることを確認します。ドメインのpayloadをipcidrとして宣言してはいけません。

TUNを有効にするとLAN機器へアクセスできない

まず、プライベートアドレスのルールが他の広範なルールより前にあり、一般的なネットワーク範囲をカバーしていることを確認します。代表的なプライベートアドレスには10.0.0.0/8、172.16.0.0/12、192.168.0.0/16があります。.localで終わるデバイスへアクセスする場合は、該当ドメインをFake-IPの除外リストにも追加してください。その後、システムファイアウォールが新しく作成されたTUNインターフェースをパブリックネットワークとして認識し、LAN通信を制限していないか確認します。

設定の保守方針：管理しやすい最小構成を保つ

中国本土は直接接続、海外はプロキシという構成に、ルールの種類を際限なく増やす必要はありません。多くの設定では、プライベートアドレスの直接接続、中国本土向けドメインの直接接続、中国本土IPによる補完、指定サービスの例外、最終的なプロキシフォールバックで十分です。ルールが増えるほど、出典、更新日時、優先度を明確に管理する必要があります。そうしないと、ルールセットの更新だけで従来の動作が変わる可能性があります。

カスタム設定は3層に分けるのがおすすめです。サブスクリプションはノードの提供、プロキシグループはノードの選択、ルールセットは通信をどのポリシーへ送るかの決定を担当します。サブスクリプション更新時にローカルルールを上書きせず、ルールセット更新時にプロキシノードを書き換えず、ノードを切り替える際にもルールを変更しません。3層を分離すれば、問題を「ノードが使えない」「ポリシーの選択ミス」「ルールに一致しない」のいずれかへ安定して切り分けられます。

設定が完了したら、少なくとも3つの確認情報を保存してください。現在のカーネル名とバージョン、実際に読み込まれている設定ファイル、中国本土向けリクエストとプロキシ経由リクエストの接続詳細です。後で異常が起きたとき、これらの情報は単に「サイトが開けない」と説明するよりも、原因の特定に役立ちます。