Clashのルール振り分け設定ガイド｜中国本土は直結、海外はプロキシ

1. 設定前に確認すること：コア、ルールモード、プロキシグループ

「中国本土は直結、海外はプロキシ」は、すべてのサイトの所在地を自動判定するスイッチではありません。通常は、明示的なドメインルール、ドメインやIPの分類データベース、最後に適用するフォールバックルールを組み合わせます。よく使う中国本土のサービスは優先的に直結させ、指定した海外サービスはプロキシグループへ振り分け、分類されない接続の出口も予測できるようにするのが目的です。

この記事では、Clash Metaの後継コアとして使われる名称であるmihomoを対象にします。従来のClashコアや各種フォーク、クライアント内蔵の設定変換機能では、対応する項目が完全には一致しません。特にGEOSITEや地理データベースの設定は、クライアント名だけでは利用可否を判断できません。

実際に動作しているコアを確認する。クライアントの「バージョン情報」またはコア情報画面で、コア名とバージョンを確認します。設定の検証で未対応のルールタイプが報告された場合は、同じ種類のルールを追加する前にコアの対応状況を確認してください。
ルールモードを選ぶ。ルールによる振り分けにはmode: ruleが必要です。グローバルモードでは通常、接続がグローバルポリシーに渡されます。直結モードでは、この記事のルールに基づくプロキシ選択は行われません。
出力先の名前を確認する。この記事では、既存のプロキシグループをProxyと表記します。名前は大文字・小文字を区別します。現在の設定のproxy-groupsに定義され、有効なノードを選択できる必要があります。
現在の設定をバックアップする。サブスクリプションから生成された設定は、更新時に上書きされることがあります。クライアントが提供する永続的なオーバーライド、設定のマージ、ルール編集機能を優先して使い、最終的に反映された設定を確認してください。

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

ルールモードでは、コアがrulesを上から順に確認します。一般的な振り分けでは、最初に一致したルールの出力先が使われ、それ以降の「より細かい」ルールは評価されません。そのため、ルールの数より順序が重要です。個別の例外を先頭に置き、分類ルールを続け、MATCHは最後に配置します。

ルールタイプ	対象	主な違い
`DOMAIN`	単一の完全修飾ドメイン名	完全一致。他のサブドメインには自動適用されない
`DOMAIN-SUFFIX`	ドメインとそのサブドメイン	`github.com`は`api.github.com`にも一致
`GEOSITE`	データベース内のドメイン集合	ローカルデータベースに該当する分類が必要
`GEOIP`	接続先IPの所在地	サイト、アカウント、運営主体の所在地は判定できない
`RULE-SET`	ルールプロバイダー内の項目	集合は`rule-providers`で定義
`MATCH`	それ以前のルールに一致しなかった接続	最後のフォールバックとして使う。「海外判定」を意味するものではない

まずは2つのドメインルールで順序を確認

rules:
  - DOMAIN,api.github.com,Proxy
  - DOMAIN-SUFFIX,github.com,DIRECT
  - MATCH,Proxy

この設定は優先順位を示す例です。api.github.comは1つ目のルールに一致してProxyへ送られ、github.comと他のサブドメインは2つ目のルールに一致して直結される場合があります。前後を入れ替えると、サフィックスルールが先にapi.github.comを拾うため、ドメイン完全一致ルールが機能しなくなります。実際の運用では、必要に応じてGitHub関連の出口を統一してください。比較用の例をそのまま使う必要はありません。

MATCH,DIRECTをルールの先頭に置かないでください。また、同じドメインでは常に最も細かいルールが選ばれると考えてはいけません。広告ブロック、社内ネットワーク、ダウンロードサイトなどの例外も、「より具体的な条件を先に書く」のが基本です。

3. 基本の振り分け：ドメインを優先し、GEOIPで補完、プロキシをフォールバックに

外部ルールファイルを使わず、まずは少数のドメインルールで動作を確認できる基本形を作ります。ここでは、プライベートIPv4アドレスは直結、Bilibili関連の主要ドメインは直結、GitHub関連の一般的なドメインはプロキシ、中国本土のIPアドレスは直結、それ以外の接続はProxyへ送ります。

mode: rule

rules:
  - 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,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,bilivideo.com,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

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

no-resolveは、このIPルールとの照合だけを目的に、ドメイン名の解決を能動的に行わないという意味です。接続メタデータに照合可能な実際の接続先IPがあれば、指定されたネットワーク範囲や地域に含まれるかを判定できます。ドメイン名しかなく、利用できるIPがない場合は、このルールをスキップして次のルールへ進むことがあります。

したがって、上記のGEOIP,CN,DIRECT,no-resolveだけでは、中国本土のドメインがすべて直結されるとは限りません。ドメインルールに含まれず、その時点で利用できるIPもない中国本土のドメインは、最終的にProxyへ送られる場合があります。IP分類だけに頼るより、中国本土のドメイン集合を追加するほうが挙動を管理しやすくなります。IPルールで名前解決を許可する場合は、名前解決の経路や所要時間、返されるアドレスが想定どおりかも確認してください。

プライベートネットワークのルールが決めるのは、コアに届いた接続の出力先です。LANルートを自動作成したり、アプリに社内ネットワークへのアクセス権を与えたりするものではありません。
このサンプルでは一般的なプライベートIPv4ネットワークだけを扱います。IPv6のLANを使う場合は、実際のネットワークに合わせてルールを追加してください。
fake-ip DNSを使う場合は、コアが復元するドメイン名と実際の名前解決結果を確認してください。fake-ipのアドレス範囲を通常の直結ネットワークとして追加するのは避けてください。
1つのサービスが複数のドメインを使うことがあります。メインページは表示できても画像、ログイン、ダウンロードに失敗する場合は、接続ログから漏れているドメインを探してください。すぐにすべての通信を直結へ切り替えるのは避けましょう。

4. GEOSITEを追加して、ドメイン分類で中国本土への直結を補う

GEOSITEはドメイン集合に基づいて照合するもので、サーバーIPからドメインの所在地を推測する機能ではありません。GEOIPより前に置き、分類済みの中国本土ドメインをDIRECTへ振り分ける用途に適しています。ただし、集合の内容は使用するデータベースによって異なるため、分類名や対象範囲はデータソースごとに一致するとは限りません。

mihomoでは、次のような部分設定を使えます。統合する際は、前のセクションで確認したローカルネットワークと個別ルールを残してください。ここにある短いrulesを、既存のルール一覧全体と置き換える必要はありません。

geodata-mode: true

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

geodata-mode: trueを設定すると、GEOIPはDATデータモードを使います。この構成では、利用可能なgeoip.datが必要です。また、GEOSITEにはgeosite.datが必要です。クライアントが使うコアの作業ディレクトリ、データベースの読み込みログ、データソースにcn分類が実際に存在するかを確認してください。分類がなければ、大文字・小文字を変えたり再起動を繰り返したりしても解決しません。

ログにデータベースの読み込み失敗や分類が見つからない旨が表示されたら、まず前のセクションの基本ルールに戻し、データファイルを修復してください。DNS、データベース、プロキシノードを一度に変更すると、どの変更が挙動に影響したのか判断しにくくなります。

5. rule-providersの設定：手動ルールを管理しやすいファイルに分割

ルールが増えてきたら、中国本土向けの直結ルールとプロキシを強制するルールを別ファイルに分けると、メイン設定の編集を減らせます。ここではローカルのfileタイプを使い、出所が不明なルールURLを設定に直接追加しないようにします。ファイルパスはコアが実際に使う設定ディレクトリを基準にしてください。クライアントからインポートする場合は、設定ディレクトリがコピーまたは書き換えられるかも確認しましょう。

手順1：ルールファイルを2つ作成する

コアの設定ディレクトリにrulesフォルダーを作り、以下の内容をそれぞれrules/direct.yamlとrules/proxy.yamlとして保存します。ここではclassical形式を使うため、各項目にルールタイプを含め、末尾の出力先名は含めません。

# rules/direct.yaml
payload:
  - DOMAIN-SUFFIX,bilibili.com
  - DOMAIN-SUFFIX,bilivideo.com
  - DOMAIN-SUFFIX,qq.com
  - DOMAIN-SUFFIX,jd.com

# rules/proxy.yaml
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,wikipedia.org

手順2：プロバイダーを定義してルールに追加する

以下の例では、ローカルIPv4ネットワーク、2つのルール集合、中国本土のドメイン分類、IP分類をまとめています。既存の設定に有効なProxyグループが定義されていることと、前のセクションで触れたデータベースを読み込めることが前提です。

mode: rule
geodata-mode: true

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/direct.yaml
  local-proxy:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/proxy.yaml

rules:
  - 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
  - RULE-SET,local-proxy,Proxy
  - RULE-SET,local-direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

2つの集合に同じドメインが含まれている場合も、メイン設定のRULE-SETの順序に従って処理されます。この例ではプロキシを強制する集合を中国本土向けの直結集合より前に置き、例外を優先させています。集合名は識別子にすぎず、それ自体で優先順位が決まるわけではありません。

手順3：形式と更新方法を確認する

YAMLの階層：インデントにはスペースを使い、タブは使わないでください。設定全体でトップレベルのrulesとrule-providersはそれぞれ1つにし、追加項目は既存の一覧に統合します。
形式と内容：classical形式のファイルには、DOMAIN-SUFFIX,github.comのような条件を含むルールを記述します。ドメイン名だけの一覧を混在させないでください。domainとipcidrでは、それぞれ異なる形式の内容が必要です。
ローカル更新：type: fileは定期的にネットから内容を取得しません。ファイルを変更したら、クライアントが対応する再読み込みまたはルールセット更新を実行し、ログで反映を確認してください。
リモート更新：type: httpを使う場合は、信頼できる実際のURL、キャッシュパス、更新間隔も設定します。たとえばinterval: 86400は86400秒、つまり24時間を表し、86400ミリ秒ではありません。

サブスクリプションの更新とルールプロバイダーの更新は別の処理です。前者は設定全体を再生成することがあり、後者は通常、特定のルール集合だけを更新します。サブスクリプションを更新するたびにルールが消える場合は、一時生成されたファイルを何度も編集するのではなく、クライアントのオーバーライドとマージの順序を確認してください。

6. 振り分けを検証する：ルール、プロキシ経路、新しい接続を確認

Webページが開くことだけでは、通信経路が使えると分かるだけで、想定したルールに一致した証明にはなりません。まずログレベルをinfoに設定し、接続画面で対象ドメイン、対象IP、一致したルール、出力先までの経路を確認しましょう。画面の名称はクライアントによって異なるため、実際に表示される項目を基準にしてください。

読み込み前に構文を確認する。mihomoを直接管理している場合は、同じ作業ディレクトリでmihomo -t -f ./config.yamlを実行できます。設定ファイル名とパスは実際のファイルに合わせてください。GUIクライアントでは、クライアントに搭載された設定検証機能も使いましょう。
直結の動作を確認する。www.bilibili.comへ新しくアクセスし、local-directに一致して最終的にDIRECTが使われているか確認します。ページ内の他のリソースは別のルールに一致することがあるため、接続ログを個別に確認してください。
プロキシの動作を確認する。github.comへ新しくアクセスし、local-proxyに一致しているか確認します。出力先の経路を開き、Proxyで選ばれているのがプロキシノードであり、グループ内のDIRECTではないことを確認してください。
フォールバックを確認する。個別ルールの集合に含まれないドメインを選び、GEOSITE、GEOIP、MATCHのどれに一致するかを確認します。「個別ルールにないドメインは必ずプロキシ」と決めつけないでください。
既存の接続を閉じて再テストする。ルールを再読み込みしても、確立済みの接続は通常そのままです。ブラウザーの接続再利用、HTTP/2、QUICによって以前の経路が残ることがあります。対象の接続を閉じるかアプリを終了してから、あらためてリクエストしてください。

明示的なプロキシ接続で「通信がコアに届かない」と「ルールに一致しない」を切り分ける

設定したmixed-portが7890の場合は、ターミナルで次の2つのリクエストを実行できます。ポートが異なる場合は実際の値に置き換えてください。Windows PowerShellでは、他のコマンドのエイリアスとの混同を避けるためcurl.exeを使えます。7890は例示用のポートで、すべてのクライアント共通の固定値ではありません。

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

サーバーがHEADリクエストに対してリダイレクトや拒否を返すことがありますが、通信がコアに届いたかどうかの確認には影響しません。接続ログも同時に確認してください。明示的なプロキシリクエストは記録されるのに、ブラウザーやゲームの接続が記録されない場合は、ルールを増やす前にシステムプロキシ、アプリ独自のプロキシ設定、TUNの対象範囲を確認しましょう。

TUNモードはルーティング条件に合う通信を受け取る機能であり、すべての通信を強制的にプロキシへ送る機能ではありません。コアに届いた後も、モードとルールに従って出力先が選ばれます。また、すべてのアプリがシステムプロキシに従うわけではありません。どちらも通信を取り込む経路を扱うもので、ルール照合の代わりにはなりません。

7. よくある問題と確認の順序

症状	まず確認すること	対処方法
中国本土のサイトがプロキシ経由になる	MATCHに一致していないか、ドメイン情報しかない状態ではないか	ドメインルールを追加し、GEOSITEの分類とno-resolveの影響を確認する
Proxyと表示されるのにローカル回線を使う	プロキシグループの選択項目と出力先までの経路	グループ内で有効なプロキシノードを選択しているか確認する。DIRECTが選ばれていないかも確認
設定を変えても動作が変わらない	実際に反映された設定、現在のモード、既存の接続	正しい設定を再読み込みし、古い接続を閉じてから再テストする
ルールプロバイダーの読み込みに失敗する	ファイルパス、payload、behavior、インデント	まずローカルファイルを修正し、その後でリモート取得の問題に対処する
一部の画像やログインだけ失敗する	失敗したリクエストで使われた別ドメインとその出力先	必要な関連ドメインの出力先をそろえる
特定のアプリだけルールどおりに動かない	そのアプリの接続がコアに記録されているか	分類データベースを変更する前に、アプリのプロキシ設定やTUNのルート取り込みを確認する

保守時は「通信の取り込み経路 → ルールモード → 実際に反映された設定 → 一致したルール → プロキシグループの選択 → ノードの接続状態」の順に確認してください。ルールが決めるのは出力先であり、停止したノードを復旧させたり、直結回線の利用を保証したりするものではありません。正しいルールに一致していると確認できたら、同じドメインを繰り返し追加せず、該当する出力先を調べてください。

ルールモード、リスニングポート、プロキシグループについて詳しく知りたい場合は、プロキシモードの説明、ポートの説明、プロキシグループの説明をご覧ください。サブスクリプション更新による上書きは、サブスクリプション関連のトラブル対処で確認できます。