ruleモードで接続先を決める仕組み
Clashのruleモードでは、rules リストを上から順に確認し、最初に一致したルールがすぐに適用されます。後続のルールは判定されません。ルールの左側はマッチタイプ、中央は判定対象、右側はポリシー名です。ポリシーには DIRECT や REJECT のほか、設定済みのプロキシグループである PROXY、Auto、海外ノード などを指定できます。
1つのリクエストで判定に使える情報には、通常、対象ドメイン、対象IP、対象ポート、ネットワーク種別、プロセス情報などがあります。取得できる情報はインバウンド方式によって異なります。システムプロキシでHTTPまたはSOCKS接続を処理する場合、ドメインは比較的明確です。一方、TUNモードでシステム通信を引き受けると、ドメインが保持されるかどうかはDNSモード、ドメインスニッフィング、アプリの接続方式にも左右されます。そのため、同じルールでもシステムプロキシとTUNではヒット記録が異なる場合があります。
基本となる4つの結果
| ルールの結果 | 接続の動作 | 主な用途 |
|---|---|---|
DIRECT |
現在の端末から対象へ直接接続 | 中国国内のサイト、LAN機器、信頼できるダウンロード元 |
REJECT |
接続を拒否し、後続ルールには渡さない | 広告ドメイン、トラッキングリクエスト、既知の妨害先 |
| プロキシグループ名 | 選択したノードまたは自動選択グループに渡す | 海外サイト、開発サービス、ストリーミング |
MATCH |
前のルールに一致しなかった接続を受け取る | ルールリストの最後に置くフォールバック |
DOMAIN-SUFFIX、GEOIP、RULE-SET、MATCHの書き方
DOMAIN-SUFFIX:ドメインサフィックスで処理する
DOMAIN-SUFFIX,example.com,PROXY は example.com 本体と、www.example.com や api.example.com などのサブドメインに一致します。同じサービスの複数サブドメインを処理するのに向いており、完全なドメインを1つずつ書くより効率的です。手動ルールでもよく使われるタイプです。
rules:
- DOMAIN,router.local,DIRECT
- DOMAIN-SUFFIX,gov.cn,DIRECT
- DOMAIN-SUFFIX,cn,DIRECT
- DOMAIN-SUFFIX,example.com,PROXY
DOMAIN は1つの完全なドメインだけに一致し、サブドメインは自動的に含みません。DOMAIN-KEYWORD はドメイン内に指定文字列があれば一致するため、対象範囲が広く、誤判定も起きやすくなります。ログイン先や更新先を正確に許可する場合は DOMAIN、サイト全体を対象にする場合は DOMAIN-SUFFIX を使います。
GEOIP:対象IPの地域情報で処理する
GEOIP,CN,DIRECT は、クライアントが読み込んだIP地理データベースを使い、対象アドレスが中国本土に属するかを判定します。ドメインを持たない直接IP接続や、ドメインルールで拾えなかった中国国内向けリクエストの処理に適しています。GEOIPの判定はローカルデータベースに依存するため、データが古いと新しく割り当てられたネットワークがフォールバック側に誤分類されることがあります。
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
- GEOIP,CN,DIRECT
- MATCH,PROXY
no-resolve は、IPルールでドメインを積極的にIPへ解決しないことを示します。LANのCIDRルールでは、すでに取得済みの対象アドレスだけを確認すればよいため、このパラメーターで余分なDNS問い合わせを減らせます。ただし、すべてのGEOIPルールに機械的に no-resolve を付けるのは避けてください。対象IPがまだないドメインリクエストが地域判定を通過してしまう可能性があります。
RULE-SET:大量のルールを独立ファイルに分ける
広告ルールや中国国内ドメインのルールが数百、数千件になると、すべてをメイン設定に詰め込むことで可読性が下がります。rule-providers でルールファイルを定義し、RULE-SET でメインのルールリストから呼び出します。Clash Meta、つまり mihomoは、domain、ipcidr、classical などのbehaviorタイプに対応しています。タイプごとにペイロードの形式が異なります。
rule-providers:
allow:
type: file
behavior: domain
path: ./ruleset/allow.yaml
ads:
type: file
behavior: classical
path: ./ruleset/ads.yaml
direct-domain:
type: file
behavior: domain
path: ./ruleset/direct-domain.yaml
rules:
- RULE-SET,allow,DIRECT
- RULE-SET,ads,REJECT
- RULE-SET,direct-domain,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
behavior: domain のファイルにはドメインのペイロードだけを保存し、中国国内ドメインや許可リストに適しています。behavior: classical では、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR など、タイプを含む完全なルールを保存できます。ローカルファイルなら内容を確認してから有効化できます。自動更新が必要な場合は type: http に変更し、ルールのURL、保存先、更新間隔も設定します。
MATCH:必ず最後に置く
MATCH,PROXY はドメインやIPを確認せず、まだ一致していないすべての接続に一致します。MATCHを途中に置くと、その下のルールは実行されません。よくある目的は「中国国内は直接接続、それ以外はプロキシ」です。そのため、例外の許可、広告の拒否、LANの直接接続、中国国内ドメイン、GEOIPを先に置き、最後にMATCHでプロキシグループへ渡します。
中国国内は直接接続、海外はプロキシ、広告はブロックする設定ひな形
以下のひな形は、既存のサブスクリプション設定に追加して使えます。サブスクリプション内に PROXY というポリシーグループがすでにある前提です。クライアント上のグループ名が「ノード選択」や「プロキシ」の場合は、ルール末尾の PROXY を実際の名前に変更してください。ポリシー名は大文字・小文字を区別し、空白や日本語も完全に一致させる必要があります。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
profile:
store-selected: true
rule-providers:
allow:
type: file
behavior: domain
path: ./ruleset/allow.yaml
ads:
type: file
behavior: classical
path: ./ruleset/ads.yaml
direct-domain:
type: file
behavior: domain
path: ./ruleset/direct-domain.yaml
rules:
- RULE-SET,allow,DIRECT
- RULE-SET,ads,REJECT
- DOMAIN,localhost,DIRECT
- DOMAIN-SUFFIX,local,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
- IP-CIDR,169.254.0.0/16,DIRECT,no-resolve
- RULE-SET,direct-domain,DIRECT
- DOMAIN-SUFFIX,gov.cn,DIRECT
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
mixed-port: 7890 は、同じポートでHTTPとSOCKS5接続を受け付けます。デスクトップクライアントのシステムプロキシを 127.0.0.1:7890 に統一する場合に便利です。allow-lan: false は、この例ではプロキシポートをLANに公開しないことを示します。テレビ、スマートフォン、ゲーム機からこのPCへ接続する必要がある場合は、待受アドレスとファイアウォールルールも別途設定してください。ルールリストだけを変更しても不十分です。
3つのローカルルールファイル
allow.yaml は、広告リストによる誤ブロックを上書きするために使います。広告ルールより前に置くため、同じドメインは先に許可されます。domainタイプのペイロードは次の形式で記述できます。
payload:
- 'login.example.net'
- '+.account.example.net'
ads.yaml はclassicalタイプを使い、各項目に完全なルールタイプを含めます。広告リストでは、できるだけ正確なドメインとサフィックスを使い、範囲の広すぎるキーワードは慎重に扱います。
payload:
- DOMAIN,ads.example.net
- DOMAIN-SUFFIX,tracking.example.net
- DOMAIN-KEYWORD,telemetry-example
direct-domain.yaml はdomainタイプを使い、直接接続する中国国内サービスのサフィックスを保存します。
payload:
- '+.gov.cn'
- '+.edu.cn'
- '+.example.cn'
評価順:許可、ブロック、直接接続、フォールバック
ルールの順番は単なる整理方法ではなく、最終的な接続先を変えます。推奨順は、正確な許可リスト、広告拒否、LANアドレス、中国国内ドメイン、中国国内IP、専用サービス用ポリシー、最後にMATCHです。許可リストを広告リストより前に置くことで、ログインAPI、認証コード、決済ページが第三者ルールに誤ブロックされる問題に対処できます。
- 正確な許可:直接接続が必要で、広告ルールにもブロックされたくないドメインを処理します。
- 広告拒否:明確な広告・トラッキングドメインに拒否結果を返します。
- LANの直接接続:ルーター、NAS、プリンター、ローカル開発サービスをプロキシ経由にしません。
- 中国国内ドメインの直接接続:まずドメインルールで分流し、不要なIP判定を減らします。
- 中国国内IPの直接接続:IPへの直接アクセスや、ドメインルールで拾えなかった接続を処理します。
- 海外サービスのグループ分け:ストリーミングやコードホスティングなど、専用ポリシーが必要なものをMATCHの前に置きます。
- MATCHのフォールバック:残りの接続をデフォルトのプロキシグループへ渡します。
なぜGEOIPを広告ルールより先に置いてはいけないのか
広告ドメインが中国国内のIPへ解決されることがあります。GEOIP,CN,DIRECT が広告ルールより前にあると、リクエストはIP判定によって先に直接接続され、後続の RULE-SET,ads,REJECT は実行されません。広告ドメインのルールをGEOIPより前に置くことで、ドメインを優先してリクエストを拒否できます。
DOMAIN-SUFFIX,cnだけに頼らないほうがよい理由
DOMAIN-SUFFIX,cn,DIRECT は、.cn で終わる多数のサイトをカバーできます。しかし、中国国内のサービスが .com、.net、クラウドサービスのドメインを使うこともあり、海外サービスが一部のAPIに中国のドメインを使う場合もあります。保守された中国国内ドメインのルールセットを主な判定に使い、.cn と GEOIP,CN で漏れを補うほうが安定します。
サブスクリプション更新後もカスタムルールを残す方法
サブスクリプションが生成したYAMLファイルを直接編集すると、次回の更新で変更が上書きされることがあります。デスクトップクライアントに「グローバル拡張設定」「オーバーライド」「Merge」「スクリプト」などの機能がある場合は、カスタムの rule-providers とルール挿入処理をオーバーライド層に配置します。メニュー名はクライアントによって異なりますが、一般的な入口は「サブスクリプション」→「編集」→「設定を上書き」、または「設定」→「設定ファイル」→「グローバル拡張」です。
マージ時は、クライアントが追加方式か置換方式かを先に確認してください。rules がサブスクリプションのルール末尾に単純追加され、元の設定にMATCHがある場合、新しいルールは一致しません。正しくは、カスタムルールを元のMATCHより前に挿入するか、rules 全体を明示的に置き換えます。
オリジナルClashとmihomoの互換範囲
基本的な DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、RULE-SET、MATCH は、一般的なClash設定で広くサポートされています。mihomoには、GEOSITE、複合論理ルール、ルールセットのバイナリ形式、より完全なプロセスマッチング機能もあります。複数のコアで設定を共用する場合は、まず基本構文を維持し、クライアントの対応状況に応じて拡張フィールドを追加してください。
TUN、DNS、ルールのヒットの関係
TUNモードが引き受けるのはブラウザーの通信だけではありません。システムプロキシに従わないアプリ、コマンドラインツールの一部、UDP接続も対象になります。このときクライアントは、ネットワークパケット、DNSマッピング、スニッフィング結果から対象ドメインを復元する必要があります。対象IPしか確認できない場合、DOMAIN-SUFFIXとdomainタイプのRULE-SETは利用できず、接続はIP-CIDR、GEOIP、MATCHへ進みます。
fake-ipモード
mihomoでよく使われる fake-ip DNSモードでは、ドメインに予約アドレスを返し、コア内に「仮想IP—元のドメイン」の対応を保存します。アプリがこの仮想アドレスへ接続しても、コアはドメインを取得してドメインルールを適用できます。LAN機器の検出、企業内ネットワーク、実際のDNS応答に依存するプログラムで問題がある場合は、DNSモード全体を切り替えるのではなく、対象ドメインをfake-ipの除外リストに追加します。
redir-hostモード
redir-host は実際の名前解決結果を返し、その後にドメインまたはIPで分流します。一部のLANや特殊なアプリでは分かりやすい方式ですが、DNSの問い合わせ経路と実際の接続経路を一致させる必要があります。一致しないと、名前解決は中国国内なのに接続だけ海外プロキシへ送られることがあります。調査時はDNSログと接続ログを同時に確認し、ノードの速度テスト結果だけで判断しないでください。
推奨テスト手順
- クライアントの「ログ」画面でレベルを一時的にInfoへ変更し、対象サイトへ再アクセスします。
- 接続記録のHost、Destination IP、Rule、Chainフィールドを確認します。
- 広告ドメインが
RULE-SET,adsに一致し、結果がREJECTになっていることを確認します。 - LANアドレスが
IP-CIDRに一致し、結果がDIRECTになっていることを確認します。 - 中国国内サイトがdirect-domainまたは
GEOIP,CNに一致していることを確認します。 - 分類されていない海外サイトが最終的にMATCHへ一致し、想定したプロキシグループに入ることを確認します。
テストでは一度に1つの条件だけを変更してください。ルールを調整したら「設定」→「再読み込み」を実行し、既存の接続を閉じてから新しいリクエストを開始します。ブラウザーの長時間接続、HTTP/2セッション、アプリの接続プールは変更前の出口を使い続けることがあるため、ページを更新するだけでは新しいルールが適用されない場合があります。
よくあるトラブルと確認方法
設定は読み込めるのに、すべての通信がプロキシ経由になる
まずモードがRuleのままか確認し、次にルールリストの先頭にMATCHや範囲の広すぎるプロキシルールがないか確認します。中国国内ドメインのルールにRULE-SETを使っている場合は、ルールプロバイダーの項目数が0でないことを確認し、ローカルの path が設定ファイルのあるディレクトリを基準に正しく解決されているかも確認してください。
広告ルールを有効にしたらログインや決済ページが開けない
接続記録からREJECTされた具体的なドメインを探し、必要なドメインをallowルールセットに追加します。そのうえで RULE-SET,allow,DIRECT が広告ルールより前にあることを確認してください。広告リスト全体を無効にしたり、範囲の広すぎるトップレベルドメインを許可したりせず、ログインAPIの完全なドメインまたは必要最小限のサフィックスを追加します。
中国国内のサイトがMATCHに一致する
接続記録にHostが残っているか確認します。ドメインがあるのに一致しない場合は、通常、中国国内ドメインのルールにその項目が不足しています。対象IPしかない場合は、GEOIPデータベースとDNS設定を確認してください。また、ルールで使うポリシー名が実際に存在することも確認します。クライアントによっては、無効なポリシーがあると設定全体の読み込みを拒否します。
YAMLを変更したら解析に失敗する
YAMLのインデントにはスペースを使い、タブは使えません。rules と rule-providers が正しい階層にあり、リスト項目の前にハイフンがあることを確認します。コロン、シャープ記号、特殊文字を含むドメインのペイロードはシングルクォートで囲めます。エラーメッセージに行番号が表示される場合は、直前の行でコロンを書き忘れていないかも確認してください。実際のエラー位置が次の行として示されることがよくあります。
遅延テストは正常なのに、Webページが開けない
遅延テストで確認できるのは、テスト先が特定のプロキシグループを通って接続できるかどうかだけで、対象ページが同じポリシーに一致するとは限りません。接続画面を開き、実際のRuleとChainを確認してください。リクエストがDIRECT、REJECT、または別の専用グループに先に処理されている場合は、速度テストのノードを何度も切り替えるのではなく、ルールの順番を調整します。