応用設定 読了目安：12分

Clashのルール分岐設定ガイド：GEOIP・DOMAIN-SUFFIX・RULE-SETの組み合わせ

ルールの評価順序から、中国国内は直接接続・海外はプロキシ経由にする基本設定、rule-providersの参照方法と更新手順まで解説します。

ルールモードと設定画面を確認する

ルール分岐は接続の出先を決めるもので、プロキシノードを作成する機能ではありません。始める前に、サブスクリプションを読み込み、ノードに接続できることを確認したうえで、クライアントの「プロキシモード」で「ルール」を選択してください。全体モードでは通常、すべての通信が全体向けのポリシーに送られ、直接接続モードではこの記事のルール一覧による振り分けは行われません。

この記事では、Clash Metaの後継プロジェクトであるmihomoのYAML設定を対象に説明します。従来版Clashや各クライアントでは、ルールセット形式や更新画面の対応状況が異なります。編集前に「バージョン情報」または「コア情報」で使用中のコアを確認してください。以下の例ではYAML形式のルールセットを使用し、MRS形式のバイナリルールセットには依存しません。

  1. 「設定」または「サブスクリプション」画面から現在の設定を書き出し、再インポートできるバックアップを保存します。
  2. 設定に 代理选择 という名前のポリシーグループがあることを確認します。実際の名前が異なる場合は、例にあるすべての参照箇所を同じ名前に変更してください。
  3. クライアントにある「オーバーライド」「拡張設定」「設定編集」などの画面を開き、ルールがマージされるのか置き換えられるのかを確認します。
  4. まず最小限のルールを保存し、正常に読み込めたことを確認してからリモートルールセットを追加します。

評価順序：最初に一致したルールで出先が決まる

rules は順序を持つリストです。コアは上から順に確認し、ルールに一致すると指定されたポリシーを適用します。「より詳細な」次のルールを探すことはありません。そのため、個別の例外ルールを先頭に、共通ルールセットを中ほどに置き、最後にフォールバックの MATCH を配置します。

mode: rule

rules:
  - DOMAIN,github.com,代理选择
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理选择

これは設定の一部であり、ノードやポリシーグループの定義は含まれていません。既存の設定にマージする場合は、トップレベルの rules を1つだけ残し、同じキーを続けて貼り付けないでください。最後の行は「それ以前のルールに一致しなければ代理选择を使う」という意味で、対象が海外にあるとコアが判定したことを示すものではありません。

混同しやすい3つの名称

  • DIRECT：組み込みの直接接続先です。端末のネットワークから接続先へ直接アクセスします。
  • 代理选择：この例で使うポリシーグループ名です。あらかじめ定義され、現在選択中のノードが利用可能である必要があります。
  • MATCH：フォールバック用のルールタイプで、ポリシーグループではありません。その後のフィールドに出先を指定します。

MATCH,代理选择 を1行目に置くと、後続の直接接続ルールは一切適用されません。また、ポリシーグループで DIRECT が選択されていれば、ログに「代理选择」と表示されても接続は直接接続になる場合があります。問題を調べる際は、ルールと最終的な出先の両方を確認してください。

DOMAIN-SUFFIX：対象が明確なドメインを先に処理する

ドメインルールは、接続先サイトを明確に指定する場合に適しています。DOMAIN はドメイン名との完全一致、DOMAIN-SUFFIX はそのドメイン自体とサブドメインに一致します。ルール値にはドメイン名だけを指定し、スキーム・パス・ポートは含めません。

ルールの書き方一致する範囲用途
DOMAIN,github.com,代理选择github.comのみ特定のホスト名だけを指定
DOMAIN-SUFFIX,github.com,代理选择github.comとapi.github.comなどのサブドメイン同一ドメイン配下のサービスをまとめて指定
DOMAIN-SUFFIX,home.arpa,DIRECThome.arpaとそのサブドメイン家庭内ネットワークのローカルドメイン

DOMAIN-SUFFIX,github.com は notgithub.com には一致せず、githubusercontent.com も自動的には対象になりません。サイトのログイン、画像、ダウンロードで異なるドメインが使われる場合があるため、ブラウザーのアドレス欄だけで全リクエストを判断できません。接続ログで実際の接続先を確認し、必要なルールを追加してください。

ドメインルールが一致するかどうかは、コアがドメイン名を取得できるかで決まる

HTTPプロキシ経由のドメインリクエストでは、通常ホスト名が保持されます。一方、アプリがIPアドレスへ直接接続する場合は状況が異なります。TUN利用時は、DNSの制御、fake-ipの対応付け、通信のスニッフィングなどでドメインを復元できる場合がありますが、すべてのプロトコルで保証されるわけではありません。ブラウザーで独自の暗号化DNSを有効にしている場合は、実際のDNS通信が想定した設定を迂回していないかも確認してください。

「TUNを有効にすれば、すべてのドメインルールが自動的に有効になる」とは限りません。まず接続の詳細で、接続先がドメイン名かIPアドレスだけかを確認し、そのうえでDNS、スニッフィング、IPルールを調べてください。関連用語は用語集で確認できます。

GEOIP：接続先IPから地域を判定する

GEOIP,CN,DIRECT は、接続先IPが現在の地理データベースでCNに該当する場合に直接接続するルールです。判定対象はIPアドレスであり、ドメインの末尾や運営元ではありません。中国語のサイトが海外CDNを利用していたり、海外サービスが中国国内のエッジサーバーを利用していたりすると、直感とは異なる結果になる場合があります。

rules:
  - DOMAIN-SUFFIX,github.com,代理选择
  - 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
  - GEOIP,CN,DIRECT
  - MATCH,代理选择

ここでは、プライベートアドレスの代表的な範囲を先に指定し、LAN内の機器がプロキシ向けのフォールバックに入らないようにします。特殊用途アドレスをすべて網羅するものではありません。ループバックアドレス、リンクローカルアドレス、その他の予約済みアドレスを扱う環境では、クライアントのTUNルート除外設定も併せて確認してください。ルールによる直接接続とルート除外は別のレイヤーであり、前者を指定しても通信がコアに入らなくなるわけではありません。

no-resolveの実際の動作

IP系ルールでドメイン名の接続先を確認する際は、先にドメインを名前解決する必要がある場合があります。no-resolve を付けると、そのルールのために名前解決を明示的に行いません。接続全体のDNSを無効にする設定ではなく、接続先IPがすでに分かっている場合のIP判定を省略するものでもありません。

  • LANのIPレンジを指定するルールには、リストの先頭でドメインごとに名前解決が発生するのを避けるため、通常 no-resolve を付けられます。
  • 未解決のドメインに対しても GEOIP,CN で地域判定したい場合は、例のように no-resolve を付けません。
  • GEOIPに no-resolve を付ける場合、一部のドメイン接続は後続のルールへ進み、最終的にプロキシ向けのフォールバックに入る可能性があります。

GEOIPの結果は、データベースの提供元や更新時期、DNSが返すアドレスにも左右されます。ルールを変更してもデータベースは更新されません。一部のサービスで誤判定が起きた場合は、地域ルール全体を逆転させるのではなく、確認済みのドメイン例外を追加してください。

RULE-SET：共通リストと個人ルールを分けて管理する

rule-providers でルールセットのデータ取得元を定義し、RULE-SET でルール一覧から参照します。providerを定義しただけでは振り分けは行われません。rules から同じ名前で参照する必要があります。次の設定例では、共通の直接接続ドメインと個人用のLANルールを分け、リモートリソースの更新間隔を1日に設定しています。

rule-providers:
  direct-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/direct.txt
    path: ./rules/direct-domains.yaml
    interval: 86400

  local-policy:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-policy.yaml

rules:
  - RULE-SET,local-policy,DIRECT
  - DOMAIN-SUFFIX,github.com,代理选择
  - RULE-SET,direct-domains,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,代理选择

リモートURLは第三者が公開しているルールソースで、実行時にコアがダウンロードします。アクセスの可否や内容の更新は、公開元のプロジェクトに依存します。拡張子が .txt でも、内容が単純なテキスト一覧とは限りません。このソースはYAMLの payload 構造を使うため、format: yaml を指定します。

path はコアの作業ディレクトリにあるキャッシュまたはファイルのパスで、ブラウザーのダウンロード先ではありません。GUIクライアントでは作業ディレクトリがアプリのデータフォルダーに置かれる場合があり、インストーラーと同じ場所とは限りません。type: file を使う場合は、設定を読み込む前にファイルを作成してください。

個人用ルールファイルの内容

作業ディレクトリ内の rules/local-policy.yaml に、以下の内容を保存します。ファイル型providerは一致条件を提供し、最終的なポリシーは外側の RULE-SET,local-policy,DIRECT で指定します。そのため、ファイル内に DIRECT を追加する必要はありません。

payload:
  - DOMAIN-SUFFIX,home.arpa
  - IP-CIDR,10.0.0.0/8,no-resolve
  - IP-CIDR,172.16.0.0/12,no-resolve
  - IP-CIDR,192.168.0.0/16,no-resolve
  - IP-CIDR6,fc00::/7,no-resolve

behaviorはルールセットの内容に合わせる

behavior内容の例注意点
domain'+ .example.com' を使う場合は、プラス記号の後ろの空白を削除してください。'+‌.example.com' に不可視文字を含めてはいけません。配布元が提供する内容をそのまま使うのがおすすめですドメイン一覧。rulesの完全な1行ではない
ipcidr192.168.0.0/16IPアドレス範囲の一覧
classicalDOMAIN-SUFFIX,home.arpaルールタイプを含み、最終ポリシーは含まない

広告ブロック用の構文、Clashの設定全体、ウェブページのHTMLをルールセットとして読み込まないでください。ダウンロードに成功しても、応答内容を解析できるとは限りません。解析エラーが起きた場合は、behavior、format、インデント、応答本文を確認してください。

ルールの更新：サブスクリプション、ルールセット、地理データベースを区別する

この3種類のデータは更新経路が異なります。サブスクリプションの更新では、通常ノードとサブスクリプションに含まれる設定が更新されます。HTTPルールセットはproviderの interval に従って更新され、GEOIPデータベースはコアまたはクライアントのデータベース更新機能で管理されます。「サブスクリプションを更新」を1回実行しても、3種類すべてが更新されるわけではありません。

  1. 初回読み込み：ルールセットのダウンロードと解析が完了したか確認します。利用できるキャッシュがなく、ダウンロードにも失敗した場合、設定が想定どおりに読み込まれない可能性があります。直接接続用のリストが自動的に揃うと考えないでください。
  2. 定期更新：interval: 86400 の単位は秒で、24時間を表します。一般的なドメイン一覧を10秒ごとに取得する必要はありません。
  3. 手動で確認：クライアントの「ルールセット」または関連する管理画面から更新します。その項目がない場合は、クライアントが対応する方法で設定を再読み込みし、ログを確認してください。
  4. ローカルファイル：type: file はリモートから内容を取得しません。ファイルを変更したら、クライアントが対応する再読み込み機能を使ってコアに新しい内容を読み込ませてください。

リモートルールも、内容を確認してから使うべき設定データです。多数のドメインを直接接続にするリストによって、ログインやダウンロードの通信がプロキシを経由しなくなる場合があります。接続方法を明確に指定したいドメインには、共通リストより前に個人ルールを置き、検証済みの設定をロールバック用に保存してください。

検証の順序：一致したルールを確認してから最終的な接続先を見る

ウェブページが開けても、利用できる経路があると分かるだけで、分岐が意図どおりとは限りません。変更後はテストページの既存接続を閉じてから再アクセスし、変更前に確立した接続の再利用を避けてください。必要であればクライアントの「接続」画面から対象の接続を終了できますが、実行中のダウンロードも中断される点に注意してください。

3種類の接続先でルールを検証する

  • LAN内の接続先：ルーターの実際のアドレスが 192.168.1.1 なら、管理画面にアクセスし、LANルールに一致して最終的な出先が DIRECT になることを確認します。
  • プロキシ経由にするドメイン：github.com にアクセスし、前方に置いたドメインルールに一致することと、「代理选择」が最終的に想定したノードへ接続することを確認します。
  • 通常の直接接続ドメイン：共通の直接接続ルールセットに含まれているドメインを選び、ページの内容だけでなく、RULE-SET と後続のGEOIPのどちらに一致したかを確認します。

現在の設定で混合プロキシのポートが 7890 の場合は、次のコマンドでローカルHTTPプロキシ経由の通信も明示的にテストできます。ポート番号はクライアントの表示に従ってください。このテストで確認できるのは明示的なプロキシ経由の通信であり、TUNによる通信の取り込みを検証するものではありません。

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://github.com

Windows PowerShellで curl が別のコマンドに割り当てられている場合は、curl.exe を使用してください。HTTPステータスコードだけでは判断できません。リダイレクト応答の場合も、接続ログと併せてリクエストの経路を確認できます。

症状から問題箇所を絞り込む

症状まず確認する項目対処方法
すべての接続がプロキシ経由になる全体モード、またはリストの前方にあるMATCHルールモードに切り替え、MATCHをリストの最後に移動する
ドメインルールに一致しない実際のリクエスト先ドメイン、接続先がIPアドレスだけになっていないか接続の詳細を確認し、DNSとドメイン名の復元経路を調べる
設定の読み込みに失敗するポリシーグループ名、キーの重複、インデントログに示された項目を修正して再読み込みする
ルールセットがあるのに適用されないRULE-SETの名前と参照位置provider名を照合し、前のルールにすでに一致していないか確認する
サブスクリプション更新後にルールが消える編集しているのが生成された設定か、永続的なオーバーライドか個人ルールをクライアントの永続的な拡張設定に移す

説明しやすい順序に整理します。個人用の例外、LANルール、共通ドメインリスト、GEOIP、MATCHの順です。ルールを追加するたびに、「何に一致するか」「どのポリシーを使うか」「なぜこの位置なのか」を説明できるようにしてください。システムプロキシやTUNによる通信の取り込みに問題がある場合は、トラブルシューティングガイドも確認してください。ルール一覧だけでは、コアに取り込まれていない通信を修復できません。

Clashをダウンロード