Clashの国内・海外向けルール設定｜中国国内サイトは直結、海外サービスはプロキシへ

まずルールモードを有効にし、通信がコアに届いているか確認

クライアントのモード選択を開き、「ルール / Rule」に切り替えます。続いて「プロキシ / Proxies」を開き、使用するプロキシグループで接続可能なノードを選択してください。国内・海外の振り分けはルールによって接続先が決まります。グローバルモードではこの振り分けが適用されず、直結モードでも以下のルールに基づくプロキシ選択は行われません。

この記事では、mihomoコアを使用するクライアントを対象に設定します。Clashはクライアントや設定エコシステムの一般的な呼称ですが、旧バージョンのClashコアはGEOSITEやデータファイル、一部のパラメーターへの対応が異なります。まずクライアントの「バージョン情報」またはコア情報でコア名を確認してください。設定エラーが発生した場合は、アプリ名だけで判断せず、実際に使用中のコアとログを確認しましょう。

現在の設定を確認：「設定 / Profiles」ページで有効なサブスクリプションを確認し、先にバックアップをエクスポートします。独自の設定はクライアントのオーバーライド、マージ、拡張設定に追加すると、サブスクリプション更新時の消失を防げます。
通信の取り込み方法を確認：ブラウザーのテストでは、まずシステムプロキシを有効にします。システムプロキシを参照しないアプリも対象にする場合は、TUNを有効にしてください。どちらの方法でも同じ振り分けルールを使用できます。
待ち受けポートを確認：以下の例ではmixed-port: 7890を使用します。実際のポートは現在有効な設定に従ってください。例に7890とあるからといって、クライアントもそのポートで待ち受けているとは限りません。
接続ログを有効にする：「接続 / Connections」と「ログ / Logs」を開きます。以降の確認では、対象ドメイン、適用されたルール、最終的なポリシーチェーンを照合します。

GEOSITE・GEOIP・RULE-SETの役割を理解する

振り分けはドメイン名でも接続先IPアドレスでも判定できます。中国国内のサービスが地域をまたぐCDNを使うこともあれば、海外サービスが近隣のIPアドレスに解決されることもあります。そのため、「IPアドレスの所在地域」と「サービスをどの出口に通すべきか」は別の問題です。通常は明確なドメインルールを先に適用し、IPの地域データベースは補助的な判定に使います。

ルールの種類	判定基準	適した用途
`DOMAIN-SUFFIX`	ドメイン名とそのサブドメイン	接続先を固定したい特定のサービス
`GEOSITE`	ドメイン分類データベース	中国国内・海外サービスなどの一括分類
`GEOIP`	接続先IPアドレスとアドレスデータベース	プライベートネットワークや地域別IPの補助判定
`RULE-SET`	設定で名前を指定したルールプロバイダー	個別に管理する直結・プロキシ・ブロックのリスト
`MATCH`	それまでのルールに一致しなかった接続を処理	ルールリストの最後の行

ルールの順序：最初に一致したルールを適用

rulesは上から順に照合され、最初に一致したルールのポリシーが適用されます。おすすめの順序は、必要な例外許可、広告ブロック、LANの直結、サービス別ドメインルール、中国国内ドメイン、海外ドメイン、中国国内IP、最後のフォールバックです。MATCHを前に置くと、それ以降のルールは実行されません。

GEOSITEのcnとgeolocation-!cnは、よく使われるデータセットの分類名ですが、すべてのデータソースで提供されるとは限りません。また、後者は「中国国内以外のすべてのドメイン」を意味するものではありません。有効にする前に、現在のgeositeデータに該当する分類が含まれているか確認してください。GEOIPデータファイルがあるだけでは、GEOSITEも利用可能とは限りません。

設定例：中国国内は直結、海外はプロキシ、広告はブロック

以下の例では、広告ドメインとサービスの直結ドメインをそれぞれローカルルールセットで管理します。まずルールの読み込みと一致を確認してから、リモートで管理されるリストへの切り替えを検討できます。例にあるPROXYはポリシーグループ名です。実際の設定に存在するプロキシグループ名に置き換えるか、同名のグループがあることを確認してください。ノードを自動作成するキーワードではありません。

手順1：ローカルルールセットのファイルを作成

コアからアクセスできる設定ディレクトリにrulesフォルダーを作成し、以下の2ファイルをそれぞれ保存します。相対パスの基準は通常、コアの作業ディレクトリです。サブスクリプションのダウンロード先とは限りません。GUIクライアントによってはファイルパスが制限されるため、クライアントが許可する設定ディレクトリを使用してください。

rules/local-ads.yaml：動作にはclassicalを指定します。ファイルにはルールの種類を含めて記述し、接続先ポリシーは指定しません。

payload:
  - DOMAIN-SUFFIX,doubleclick.net
  - DOMAIN-SUFFIX,googlesyndication.com

rules/local-direct.yaml：動作にはdomainを指定し、内容にはドメインパターンだけを記述します。このルールセットの構文では、先頭の+.によってドメイン自体とそのサブドメインが対象になります。

payload:
  - '+.bilibili.com'
  - '+.bilibili.cn'

ここでの広告リストは2ドメインのみで、ブロックの流れを示すための例です。広告を網羅するものではありません。広告ドメインがログイン、計測、コンテンツ読み込みに必要な場合もあるため、リストを増やしたら項目ごとに動作を確認してください。直結リストも記述例にすぎません。動画、画像、アカウント関連のサービスが別ドメインを使う場合は、接続ログを確認して追加します。

手順2：ルールプロバイダーと振り分けルールを統合

以下の項目を現在の設定に統合します。すでにrule-providersがある場合は既存の項目を残してください。rulesがある場合は順序を保って統合し、同じYAML階層に同名のキーを重複して記述しないでください。クライアントの「ルールを追加」機能でサブスクリプションのMATCHより後ろに追加すると、同様に適用されません。先行ルールを使うか、全体の順序を制御できるオーバーライド方法を選びましょう。

mixed-port: 7890
mode: rule

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

rules:
  - RULE-SET,local-ads,REJECT
  - 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,fc00::/7,DIRECT,no-resolve
  - RULE-SET,local-direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

これは既存設定への統合例です。ノード、proxy-groups、利用可能な地理データベースが必要なため、単独ではサブスクリプションとして使えません。プライベートアドレス範囲は一般的なものだけを挙げており、特殊用途アドレスをすべて網羅しているわけではありません。独自の内部ネットワークを使う企業では、実際のネットワーク設計に合わせて追加してください。

手順3：フォールバックポリシーと互換性を確認

中国国内ドメインは優先して直結：GEOSITE,cn,DIRECTをIP判定より前に置きます。これにより、中国国内のサービスが他地域のCDNに解決された場合でも、プロキシへのフォールバックを避けやすくなります。
分類済みの海外サービスは優先してプロキシ：海外ドメインのルールを中国国内IPのルールより前に置くと、CDNのIPアドレスの所在地を理由に海外サービスが誤って直結されるのを防げます。
分類されていない接続はプロキシへ：MATCH,PROXYは海外サービスへのアクセス性を優先する設定です。MATCH,DIRECTに変更すると、リストにない海外ドメインへの直結に失敗することがあります。利用目的に合った方を選んでください。
分類が見つからない場合は該当行をいったん削除：コアがGEOSITEの分類を見つけられないと表示した場合は、まず設定を読み込める状態に戻し、対応するデータソースを設定してください。読み込みエラーを放置したまま、クライアントを何度も再起動するのは避けましょう。

DNSとno-resolve：名前解決の問題をルールの問題と混同しない

設定を保存して再読み込みしたら、まずログでルールセットファイルの欠落、ポリシーグループの未定義、地理データベースの読み込み失敗などがないか確認します。読み込みに成功したら、次にDNSを確認してください。ドメイン名が異常なアドレスに解決されると、ルールの順序が正しくても直結がタイムアウトしたり、サービスにアクセスできなかったりすることがあります。

中国国内IPのルールにno-resolveを付けるか

例のGEOIP,CN,DIRECTにはno-resolveを付けていません。そのため、IPアドレスを必要とするルールに対して接続情報がドメイン名しかない場合、判定を続けるためにコアが名前解決を行えます。中国国内ドメインとして分類されていない国内アドレスを直結に回しやすくなりますが、DNSの結果への依存も大きくなります。

GEOIP,CN,DIRECT,no-resolveに変更すると、このルールは自身の判定のために名前解決を行いません。接続先IPがすでに分かっている接続には適用できますが、ドメイン名しかなく利用可能なアドレスもない場合は、MATCHに進むことがあります。このパラメーターを追加しても、中国国内の判定精度が上がるわけではありません。

Fake-IPとTUNで確認するポイント

Fake-IP：アプリには198.18.0.0/16などの範囲内のマッピングアドレスが渡されることがあります。実際の範囲はfake-ip-rangeを確認してください。このアドレスはサーバーの実際の所在地を示すものではないため、地域を調べて振り分けの良し悪しを判断することはできません。
ドメイン情報：DNSの適切な取り込みとマッピングにより、コアがドメイン名を復元してGEOSITEを適用しやすくなります。アプリが独自の暗号化DNSを使う場合、キャッシュ済みIPアドレスに直接接続する場合、または既存の接続を再利用する場合は、確認結果が異なることがあります。
TUN：仮想ネットワークインターフェースのルートとDNSの取り込みが実際に有効か確認してください。TUNを有効にすると取り込み対象は広がりますが、ポリシーグループ名、ルールの順序、データベースの分類が自動的に修正されるわけではありません。
DNSリゾルバーの選択：中国国内ドメインとプロキシ経由のドメインで、名前解決の結果をそれぞれテストします。ドメインごとにリゾルバーを選ぶ必要がある場合は、nameserver-policyを設定してください。変更前に、現在のmihomoドキュメントとクライアントのDNSオーバーライドの動作を確認しましょう。

振り分けを検証：ページが開くかだけでなく、適用ルールを確認

再読み込みが完了したら、テスト中のアプリで使われている既存の接続を閉じるか、クライアントの接続画面から該当接続を終了して、新しいリクエストを送信します。既存のTCP接続では、ルールを変更しても経路がすぐに再選択されないことがあります。ブラウザーが接続を再利用すると、古い結果がしばらく続く場合もあります。

中国国内への直結を確認：www.bilibili.comを開き、接続ログをドメイン名で絞り込みます。トップページのドメインにはlocal-directか、それより前にある直結ルールが適用され、ポリシーチェーンの最終結果がDIRECTと表示されるはずです。関連リソースは個別に確認してください。
海外サービスのプロキシ接続を確認：実際にプロキシ接続が必要な海外サービスにアクセスし、geolocation-!cnまたはMATCHに一致しているか確認します。さらに、ポリシーチェーンがPROXYから想定したノードにつながり、グループ内の直結設定になっていないことを確認してください。
ブロックを確認：https://doubleclick.net/にリクエストを送り、local-adsに一致してREJECTが適用されることを確認します。ブラウザーのエラーだけでは不十分です。接続ログを見て、ルールによるブロックなのか、DNSやネットワークの障害なのかを切り分けてください。
LANへの直結を確認：実際に使用しているルーターやNASのアドレスにアクセスし、プライベートネットワークのルールと直結の出口を確認します。社内ネットワークで特殊なルーティングを使っている場合は、システムのルーティングテーブルも確認してください。

明示的なプロキシ指定でシステムプロキシ設定の影響を切り分ける

macOSの「ターミナル」で以下のコマンドを実行すると、リクエストをローカルの7890番ポートに明示的に送信できます。--max-time 15は1回のテストを15秒に制限するオプションで、性能測定の結果を示すものではありません。実際のポートが異なる場合は、先にコマンドを変更してください。

curl -I --max-time 15 \
  --proxy http://127.0.0.1:7890 \
  https://www.bilibili.com/

curl -I --max-time 15 \
  --proxy http://127.0.0.1:7890 \
  https://www.wikipedia.org/

HTTPステータスコードは接続先のサービスによって決まります。リダイレクト、アクセス制限、HEADリクエストの拒否などが出力に影響することがあります。ここでは、リクエストがクライアントの接続ログに表示されるか、どのルールとポリシーチェーンに一致するかを確認します。200や403、一度のタイムアウトだけでは、国内・海外の振り分けが正確かどうかは判断できません。

よくある問題：設定・ルール一致・出口の3段階で確認

症状	まず確認する項目	対処方法
中国国内サイトがプロキシ経由になる	実際のドメイン、直結リスト、ルールの順序	接続ログを確認してドメインを追加し、明確な直結ルールをプロキシルールより前に移動
海外サイトが直結される	範囲の広すぎる直結ルール、グループ内の選択	ドメイン範囲を絞り、プロキシグループでDIRECTが選択されていないか確認
保存してもまったく反映されない	現在の設定、オーバーライドの結果、モード	対象の設定が実行中か確認し、Ruleモードに切り替える
広告が表示され続ける	同じドメインから配信されているか、実際にルールに一致しているか	広告専用ドメインを追加。同じドメイン内のコンテンツはブラウザーのコンテンツフィルターで対処
プロキシ接続がタイムアウトする	一致したルール、ノードの接続状態、DNS	まず経路選択が正しいか確認し、その後ノードと名前解決をテスト。手当たり次第にルールを追加しない
再読み込み時にファイルエラーが表示される	パス、YAMLのインデント、behavior	作業ディレクトリを確認し、ファイル形式とルールプロバイダーの宣言を一致させる

例外ルールは必要最小限の範囲に

広告ルールがログインに影響する場合は、必要性を確認したドメインだけをブロックルールより前に個別で追加してください。サービス事業者のドメイン全体を許可するのではなく、DOMAINによる完全一致を優先します。逆に、特定の海外サービスを常にプロキシ経由にする場合は、中国国内の分類ルールより前にそのサービスの完全一致ルールを追加し、中国国内の直結ルール一式を削除するのは避けましょう。

ルールセットをローカルファイルからリモートサブスクリプションに切り替える場合は、type、behavior、format、更新間隔をまとめて確認してください。domain形式のリストはclassicalルールとしてそのまま読み込めません。YAML形式のルールも拡張子を変えるだけでバイナリルールセットになるわけではありません。更新後は元に戻せる設定を保存し、同じドメインを使ってもう一度動作を確認してください。

最終確認では、通信が確実にコアへ届いていること、想定どおりのルールに一致すること、ポリシーグループの最終的な出口が正しいことの3点を確認します。この3段階を分けて記録すれば、ルールをむやみに増やさず、国内直結・海外プロキシ・広告ブロックを継続して管理できます。クライアントの操作方法は使い方ガイド、設定項目は詳細設定ガイドをご覧ください。