Clash ルール設定の実践ガイド：中国本土サイトは直結、海外サービスはプロキシへ
DOMAIN-SUFFIX、GEOSITE、GEOIP、MATCHの優先順位と組み合わせ方を解説。ポリシーグループを使った中国本土向け直結・海外向けプロキシ設定から、ルール競合の確認方法まで紹介します。
1. まずルールモードと通信経路を確認
「中国本土のサイトは直結、海外サービスはプロキシ」を実現するには、リクエストがクライアントに届いていること、ルールモードが有効であること、設定内のルールが有効な出力先を指定していることの3点が必要です。rulesだけ編集しても、グローバルモードのままでは振り分けを確認できません。ブラウザーがプロキシを使っていない場合、ルールも適用されません。
FlClashはmihomoカーネルを使用しています。この記事ではmihomoのルール構文を説明し、旧版Clashと現行カーネルのデータベース機能が完全に同じとはみなしません。作業前に現在の設定をバックアップし、次の項目を確認してください。
- 使用中の設定を選択：設定一覧で、現在使用しているサブスクリプションまたはローカル設定を確認します。有効化されていないコピーを編集しないでください。
- 出力モードをルールに設定：画面上のルールモードは設定項目
mode: ruleに対応します。グローバルモードや直結モードでは、以下のルールチェーンによる振り分けは行われません。 - リクエストがカーネルに届いている：システムプロキシを使う場合、アプリがシステムプロキシに対応し、それを利用している必要があります。TUNを使う場合は、仮想ネットワークアダプターが起動しているか、ルーティングが対象のリクエストを捕捉しているかを確認します。
- プロキシの出力先が利用可能：対象のポリシーグループが存在し、接続可能なプロキシが選択されている必要があります。ルールが正しく適用されても、上流への接続が成功するとは限りません。
2. rulesは上から順に評価され、最初に一致したルールで出力先が決まる
一般的なルールの形式は「タイプ、照合対象、ポリシー」です。例：DOMAIN-SUFFIX,github.com,PROXY。カーネルは上から順に確認し、ルールに一致すると通常はその接続のポリシーが決まり、後続の「より具体的なルール」は評価されません。そのため、個別の例外は先頭、分類ルールは中間、フォールバックは末尾に配置します。
| ルールタイプ | 照合対象 | 用途 |
|---|---|---|
DOMAIN | 完全一致するドメイン名 | 特定のホスト名だけ出力先を指定 |
DOMAIN-SUFFIX | ドメインのサフィックス | ルートドメインとサブドメインを対象にする |
GEOSITE | ドメイン分類データベース | サイトの分類に応じて振り分ける |
GEOIP | 宛先IPアドレスの分類 | ドメインルールで網羅できない宛先を補完 |
MATCH | 残りすべてのリクエスト | 最後のフォールバック。照合対象のフィールドは不要 |
完全一致とサフィックスの違い
rules:
- DOMAIN,api.github.com,PROXY
- DOMAIN-SUFFIX,github.com,PROXY
- MATCH,PROXY1つ目は api.github.com のみに一致します。2つ目は github.com とそのサブドメインに一致しますが、notgithub.com は対象になりません。上の1つ目は完全一致の例です。どちらも同じポリシーを指定するなら、通常はサフィックスルールだけで十分です。
DIRECTは組み込みの直結出力先です。一方、PROXYは固定の組み込みプロキシキーワードではなく、この記事でポリシーグループ名として使用しています。実際の設定で別のグループ名を使う場合は、例のPROXYを設定内の正確な名前にすべて置き換えてください。
3. ポリシーグループを準備してから中国本土向けの直結ルールを設定
サブスクリプションには通常、proxies、proxy-providers、proxy-groupsの一部またはすべてが含まれています。ルールの例でサブスクリプションファイル全体を置き換えないでください。まずproxy-groupsを探し、プロキシグループのnameと、そのグループで現在選択されている実際の出力先を確認します。
ポリシーグループがある場合：その名前をそのまま使う
現在の設定にPROXYという名前の利用可能なポリシーグループがあれば、後述のルールでそのまま使えます。グループ名が「プロキシ選択」の場合は、ルールをGEOSITE,geolocation-!cn,プロキシ選択と記述します。名前に含まれる空白や大文字・小文字も名前の一部です。画面表示の印象で省略しないでください。
手動設定：既存のプロキシから選択グループを作成
以下はmihomoのポリシーグループ設定例です。設定内に有効なプロキシまたはプロキシプロバイダーが定義されていることが前提です。include-all: trueを指定すると、設定内のプロキシとプロキシプロバイダーのプロキシが選択対象に含まれます。プロキシ接続情報が自動で作られるわけではありません。
proxy-groups:
- name: PROXY
type: select
include-all: trueこの項目は、既存のproxy-groupsリストに統合してください。同じ名前のトップレベル項目を新たに作成しないでください。読み込み後、グループ内に選択可能なプロキシがあることを確認します。リストが空の場合は、ルールを設定する前にサブスクリプションまたはプロキシプロバイダーを修正してください。設定を読み込ませるために唯一の出力先をDIRECTに変更しないでください。そうすると「海外向けプロキシ」も直結になってしまいます。
4. 調整して使える、中国本土向け直結・海外向けプロキシのrules
以下はルールの一部であり、サブスクリプション全体ではありません。使用前に利用可能なPROXYグループがあることと、GeoSiteデータにcnおよびgeolocation-!cnの分類が含まれていることを確認してください。ルールは、プライベートIPv4アドレスの直結、ドメインの例外、ドメイン分類、IPによる補完、最終フォールバックの5段階で構成されています。
mode: rule
rules:
# LANアドレスとローカルドメイン
- DOMAIN,localhost,DIRECT
- DOMAIN-SUFFIX,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,PROXY
# まずドメイン分類で振り分け
- GEOSITE,cn,DIRECT
- GEOSITE,geolocation-!cn,PROXY
# 次に既知の宛先IPを補完
- GEOIP,CN,DIRECT,no-resolve
# 他のルールに一致しない接続
- MATCH,PROXYGEOIPより先にドメイン分類を置く理由
サービスの提供地域とサーバーIPの所在地は一致するとは限りません。同じサービスが複数地域のCDNを利用することもあり、海外サービスが中国本土内の接続先を使う場合もあります。既知のドメイン分類で出力先を決めてからIPルールで漏れを補うと、「IPの所在地だけ」で振り分けることによる誤判定を減らせます。プロキシを使うと明示したドメインは、GEOSITE,cn,DIRECTより前に配置してください。
MATCHを最後に置く意味
MATCH,PROXYは、識別できなかった通信をデフォルトでプロキシに送る設定です。中国本土のサービスがすべて直結することを保証するものではありません。データベースに登録されていない、宛先IPを取得できない、IP分類が正確でないといった場合、リクエストはフォールバックルールに到達する可能性があります。MATCH,DIRECTに変更すると、識別できなかった海外サービスも直結する可能性があります。フォールバックの選択は異なるため、2つのルールを同時に記述して自動判定されることを期待しないでください。
5. GEOSITE、GEOIP、no-resolveの適用範囲
GeoSiteの分類はデータベースに依存し、リアルタイムの地理情報検索ではない
GEOSITE,cn,DIRECTはドメインの集合に基づいて照合するもので、サーバーの所在地を判定するものではありません。geolocation-!cnも特定の分類名であり、その他すべての分類を自動的に反転する汎用構文ではありません。データソースにこの分類がない場合、設定の読み込み時に分類が存在しないというエラーが出ることがあります。
この種のエラーが発生したら、まずクライアントのログでGeoSiteの読み込み状況を確認し、データベースがダウンロード済みであること、ファイルを読み取れること、使用する分類が含まれていることを確認します。すぐに確認できない場合は、海外向け分類ルールをいったん削除し、残りの通信をMATCH,PROXYで処理できます。その場合も、中国本土向けの分類や他のルールが正常に読み込まれることを確認してください。実際には存在しない、似た名前の分類を何度も追加しないでください。
no-resolveは追加の名前解決を避ける一方、一致する機会も変える
GEOIP,CN,DIRECT,no-resolveは、このIPルールのためだけにドメイン名を積極的に解決しないという意味です。利用可能な実際の宛先IPがすでにある場合は、そのIPで判定できます。ドメイン名しかなく、利用可能なIPがない場合、このルールだけで所在地を特定することはできず、リクエストは後続ルールに進みます。
- IPアドレスへ直接接続：宛先が最初からIPアドレスの場合、そのアドレスを使って判定できます。ドメイン名の解決は不要です。
- HTTP CONNECTまたはSOCKSリクエストにドメイン名が含まれる場合：ルールチェーンに入る時点で実際の宛先IPがあるとは限りません。
- Fake-IP環境：ドメイン名を復元できるか、実際のアドレスを取得できるかは、DNSの捕捉状況、マッピングの状態、ルールの処理過程によって異なります。アプリに表示される仮想アドレスだけでは判断できません。
中国本土のIPルールを未知のドメインにも広く適用したい場合は、このルールからno-resolveを外し、必要に応じてカーネルが名前解決できるようにする方法を検討してください。ただし、DNSクエリが発生し、結果は使用するリゾルバーにも左右されます。変更前にDNSリクエストの経路と到達性を確認し、DNSタイムアウトをルールの不具合と誤認しないようにしてください。
6. 接続ログで適用ルールを確認し、ページの表示速度だけで判断しない
設定の読み込みに成功したら、新しい接続で動作を確認します。ブラウザーは既存のHTTP/2またはHTTP/3セッションを再利用することがあり、ルールを変更しても既存の接続すべてで出力先が選び直されるとは限りません。対象ページを閉じ、該当する接続を終了してから再度リクエストすると、結果を判断しやすくなります。
- 設定とモードを確認：現在の設定が再読み込み済みで、ルールモードになっていることを確認します。読み込みに失敗した場合は、まずログに表示されたYAML、ポリシーグループ、データベースのエラーに対処してください。
- LANアドレスをテスト：
192.168.1.1など、実際に存在するルーターの管理アドレスにアクセスします。リクエストがクライアントに届いていれば、プライベートアドレスのルール、または想定した直結ルールが適用されるはずです。 - 中国本土のサイトをテスト：
www.baidu.comにアクセスし、接続詳細で宛先ドメイン、適用ルール、最終出力先を確認します。中国本土のドメイン分類またはIPルールに対応するDIRECTが適用されるのが期待値です。 - 明示的な例外をテスト：
github.comにアクセスします。DOMAIN-SUFFIXの例外に一致し、PROXYグループで選択したプロキシから接続されることを確認します。 - ルールの適用と接続性を区別：
PROXYが適用されていても接続がタイムアウトする場合は、選択中のプロキシ、DNS、接続先サービスを引き続き確認します。中国本土向けのルールをすべて削除するのは避けてください。
1つのウェブページから、メインサイト、画像、ログインAPI、アクセス解析用ドメインへのリクエストが同時に発生することがあります。トップページが直結でも、ページ内のすべての接続が直結とは限りません。失敗したリクエストのドメインを個別に確認してください。ここに記載したアドレスは動作確認用であり、通信速度や成功率を実測・保証するものではありません。
7. よくあるルールの競合と修正方法
| 症状 | まず確認すること | 修正方法 |
|---|---|---|
| すべての接続が同じプロキシを通る | グローバルモードになっていないか、前方にMATCHがないか | ルールモードに切り替え、フォールバックルールを末尾へ移動 |
| 追加したドメインルールが適用されない | 前方のサフィックス、分類、ルールセットが先に一致していないか | 明示的な例外を、より広い範囲に一致するルールより前に移動 |
| 読み込み時にポリシーが存在しないというエラーが出る | ルールの出力先とポリシーグループ名が一致しているか | 既存のグループ名を使い、大文字・小文字と空白を確認 |
| 中国本土のサイトがMATCHに到達する | 分類に登録されているか、実際の宛先IPがあるか | ドメインルールを追加し、no-resolveとDNSの動作を確認 |
| サブスクリプション更新後にカスタムルールが消える | サブスクリプションの生成内容を直接編集していないか | 永続化できるオーバーライド機能を使うか、独立したローカル設定を管理 |
| 接続一覧に対象のリクエストが表示されない | アプリがシステムプロキシを迂回していないか、TUNのルーティングが有効か | まず通信の取り込みを修正し、その後ルールを確認 |
サブスクリプションのオーバーライドは「追加成功」だけで判断しない
FlClashのバージョンによって、設定の編集やオーバーライドの入口が異なる場合があります。現在のバージョンで実際に利用できる機能を確認してください。重要なのは、最終的に有効なルール一覧を確認することです。カスタムルールはフォールバックのMATCHより前に置く必要があります。追加機能によって新しいルールがMATCHの後ろに配置されると、ファイル上で確認できても一致する機会はありません。
サブスクリプションにRULE-SETがすでにある場合も、上から順に評価されます。この記事の例を使うために、既存のルールセットをすべて削除する必要はありません。まず既存の中国本土向け分類、プロキシ向け分類、フォールバックルールを確認してから、重複項目を統合してください。復元可能な設定を保存し、サブスクリプションの更新後に改めて確認すると、ルールが上書きされたことに気づかないままになる事態を防げます。
一度に変更するのは1段階だけ
「ドメイン例外 → GeoSite分類 → GeoIPによる補完 → MATCHフォールバック」の順に、段階ごとに確認する方法をおすすめします。まず明確なドメイン1つで想定したポリシーが適用されることを確認し、その後で対象範囲を広げます。DNSの変更、TUNの切り替え、ルールの全面書き換え、プロキシの交換を同時に行うと、どの変更で結果が変わったのか判断しにくくなります。
最終的に保存するのはルールのテキストだけではありません。ルールモードが有効であること、接続詳細に想定したルールが表示されること、ポリシーグループ内で実際に選択されている出力先が期待どおりであること、この3点も確認してください。すべて満たせば、中国本土向け直結と海外向けプロキシの設定を再確認できる状態で完了です。