Clashのカスタムルール設定ガイド｜DOMAIN-SUFFIX・IP-CIDR・RULE-SETの優先順位

ルールの評価順序：上から順に確認し、一致した時点で終了

特定のサイトをDIRECTに設定したのにプロキシ経由になる場合、ルールの種類ではなく、先にあるルールが一致していることがよくあります。Clashのrulesは順序のあるリストです。コアは先頭から確認し、条件に合うルールが見つかると、そのルールで指定された接続先を使用します。より具体的なルールを探して下へ進むことはありません。

ここでいうコアとは、接続を処理して通信を振り分けるプログラムです。Clash Metaは後継のmihomoとして開発が続いています。クライアントはサブスクリプションや接続のオン・オフ、接続履歴を管理する画面です。以下では、mihomoでよく使われるYAML設定を例に説明します。YAMLはインデントで階層を表すテキスト形式です。インデントにはスペースを使い、タブを混在させないでください。

具体的なルールが自動的に優先されるわけではない

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN,docs.example.com,DIRECT
  - MATCH,PROXY

docs.example.comにアクセスすると、最初のサフィックスルールに一致するため、PROXYが使われます。2番目のルールはより具体的ですが、評価されることはありません。ドキュメントサイトをDIRECTにしたい場合は、2番目のルールを先頭に移動してください。

この記事のPROXYは、説明用のポリシーグループ名です。すべての設定に固定で用意されているキーワードではありません。実際の設定に存在するポリシーグループ名に置き換え、大文字・小文字やスペースも一致させてください。DIRECTは組み込みの直接接続ポリシー、REJECTは組み込みの拒否ポリシーなので、そのまま使用できます。

DOMAINとDOMAIN-SUFFIX：ドメインの完全一致とサフィックス一致

一般的なルールは「種類、対象、適用するポリシー」の順で記述し、各項目を半角カンマで区切ります。ドメインルールにはホスト名だけを記述します。https://やパス、クエリ、末尾のスラッシュは含めません。URLの/accountはドメインの一部ではありません。

サフィックスルールはドメインの境界に沿って一致する

DOMAIN-SUFFIX,example.com,PROXYは、example.com、api.example.com、a.b.example.comに一致しますが、notexample.comには一致しません。*.example.comと書く必要はなく、対象の先頭にドットを付ける必要もありません。

ログイン用ホストだけをDIRECTにしたい場合は、DOMAIN,login.example.com,DIRECTを指定します。組織のサブドメイン全体を同じ接続先にしたい場合は、DOMAIN-SUFFIXを使います。キーワードルールは広い範囲に一致させたい場合に適しています。すべてのドメインサフィックスルールをこれで置き換えると、関係のないサイトまで一緒に振り分けるおそれがあります。

IP-CIDRとno-resolve：接続先アドレスによる振り分け

IP-CIDRはIPv4の接続先アドレス範囲に一致します。CIDRは「アドレスとプレフィックス長」で範囲を表す方法です。たとえば192.168.50.0/24は、192.168.50.0から192.168.50.255までの範囲を示します。末尾に記載した1つのアドレスだけに一致するわけではありません。単一のIPv4アドレスは/32で指定できます。

rules:
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR,10.20.30.40/32,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,PROXY

上の例のIP-CIDR6はIPv6用です。3つのアドレス範囲は書式の例なので、実際のLANに合わせて調整してください。特に、広すぎる範囲をそのままDIRECTのルールに加えると、本来プロキシ経由にしたい接続まで変わるおそれがあります。

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

DNSはドメイン名をIPアドレスに変換する仕組みです。ドメイン名はあるものの接続先IPがまだ取得されていない場合、IPルールの判定にDNS解決が必要になることがあります。末尾にno-resolveを付けると、そのルールの確認だけを目的としたDNS解決を行いません。接続に利用可能な接続先IPがすでに含まれていれば、引き続き一致判定できます。

つまり、no-resolveを付けてもクライアント全体のDNSが無効になるわけではなく、特定のドメインが自動的にプロキシを迂回するわけでもありません。「特定のサイトを常にDIRECTにする」なら、まずドメインルールを設定します。「LAN内の特定範囲をDIRECTにする」なら、IPルールを設定します。ドメインの取得方法やDNSモード、スニッフィングの設定によって、コアが判定に利用できる情報は異なります。問題を調べるときはブラウザーのアドレスバーだけでなく、接続の詳細を確認してください。

RULE-SET：ルールセットを参照しても評価順序は変わらない

RULE-SETはルールプロバイダー（rule-provider）を参照するために使います。プロバイダーはドメインやアドレスのルール群を読み込み、rules内の参照ルールが、一致した項目に適用するポリシーを決めます。セット名、プロバイダーの種類、ファイルの内容は互いに対応させる必要があります。参照ルールを貼り付けるだけで、セットが自動的に用意されるわけではありません。

ローカルドメインセットの例

以下は既存の設定に統合するための断片であり、単独で動作する完全なサブスクリプションではありません。既存の設定にPROXYというポリシーグループがあることを確認してから、プロバイダーとルールをそれぞれ対応するトップレベルの項目に統合してください。

rule-providers:
  work-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work-domains.yaml

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

次に、コアが使用する作業ディレクトリにrules/work-domains.yamlを作成します。相対パスの基準は、クライアントが実際に使用するコアの作業ディレクトリです。インストール先とは限りません。ファイルの内容は次のように記述できます。

payload:
  - 'example.com'
  - '+.example.org'

この形式のドメインセットでは、example.comはそのドメインを、+.example.orgはexample.org本体とそのサブドメインを表します。プロバイダーのbehaviorはdomainなので、ここにはドメインの一致条件を記述します。DOMAIN-SUFFIX,example.org,PROXYの形式にはしないでください。

domain、ipcidr、classicalの違い

• domain：ドメインの一致条件に沿った内容を記述します。ドメイン一覧に適しています。
• ipcidr：IPアドレス範囲を記述します。例：192.168.50.0/24。
• classical：ルールの種類と一致条件を組み合わせて記述します。例：DOMAIN-SUFFIX,example.org。接続先のポリシーは外側のRULE-SETで指定するため、セット内の各ルールにポリシーグループを追加する必要はありません。

リモートプロバイダーには、URLや更新間隔などの設定も必要です。サブスクリプションに含まれるリモートセットを使う場合は、まず正常に読み込まれているか確認してから、ルールの評価順序を調べてください。ファイルのダウンロード失敗、内容の形式違い、セット名の誤記と、前のルールに先に一致してしまう問題は、それぞれ別の原因です。

カスタムルールはサブスクリプションの前後どちらに置く？

サブスクリプションを更新すると、通常は設定が再生成されます。ダウンロードしたYAMLを直接編集すると、次回の更新で変更が上書きされることがあります。クライアントの永続化された上書き機能やルール統合機能を使う方法がより安全です。上書きとは、サブスクリプションの元設定とは別に変更を保存し、有効化するときにコア用の設定へ統合することです。

クライアントによって、メニュー名や統合方向、スクリプト用インターフェースは異なります。「追加済み」と表示されただけで、ルールが有効になったと判断しないでください。確認すべきなのは、最終的に有効な設定内での位置です。先頭への追加か、末尾への追加か、それとも全体の置き換えかを確認します。画面の基本操作については、使い方ガイドをご覧ください。

おすすめの順序：例外を先頭に、セットを中ほどに、フォールバックを末尾に

rules:
  # カスタム例外：優先して処理
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN,blocked.example.net,REJECT

  # 既存のサブスクリプションルール：ここでは配置のみ表示
  - DOMAIN-SUFFIX,example.com,PROXY
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

  # 最後に、前のルールに一致しなかった接続を処理
  - MATCH,PROXY

MATCHはフォールバックルールで、対象を指定する必要はありません。ここまで到達した接続はすべて、指定したポリシーが適用されます。クライアントが既存のMATCHの後ろにカスタムルールを追加すると、そのルールは実行されません。カスタムルールを先頭に追加するか、最終フォールバックの前に挿入してください。同じルールを繰り返し追加しても解決しません。

ルールが効かないときは接続履歴を順に確認

ルールを変更したら、まず設定を再読み込みし、対象アプリの既存の接続を閉じてからリクエストをやり直してください。ブラウザーが確立済みの接続を再利用する場合があります。既存の接続は、ルールを変更しても通常、自動的に新しい接続先へ切り替わりません。テストでは一度に1～2個のルールだけを変更すると、結果を比較しやすくなります。

1. 有効な設定と動作モードを確認する。現在どのサブスクリプションが有効か、動作モードがルールモードかを確認してください。有効になっていない設定を編集しても、現在の通信には反映されません。
2. 通信がコアに届いているか確認する。クライアントの「接続」画面を開き、対象のドメイン名またはIPアドレスを検索してください。記録が見つからない場合は、システムプロキシ、アプリ独自のプロキシ設定、TUNの対象範囲を確認します。
3. 一致したルールを確認する。接続の詳細で、ルールの種類、ルールの内容、ポリシーの経路を確認してください。項目名はクライアントによって異なりますが、実際に一致したルールを特定することが重要です。
4. 最終設定でのルール順を確認する。範囲の広いサフィックスルールやセットに一致している場合は、より具体的な例外をその前に移動します。MATCHに一致している場合は、ルールの内容とプロバイダーが実際に一致するか確認してください。
5. 接続先が想定どおりか確認する。PROXYに一致した場合、通信がそのポリシーグループに渡されたことを示します。グループ内で現在選択されているポリシーがDIRECTなら、最終的な接続は直接接続です。
6. サブスクリプションを一度更新して再テストする。カスタムルールが保持され、配置も変わっていないことを確認してください。「一時的な編集では成功したが、更新後に消えた」という問題を見つけられます。

3回のリクエストでルールの順序を確認

先ほどのドメイン例で確認します。docs.example.comにアクセスすると、完全一致ルールに一致してDIRECTになる想定です。api.example.comはサフィックスルールに一致してPROXYに渡される想定です。ほかのルールに一致しない宛先はMATCHに到達する想定です。これらのドメインはルール同士の関係を説明するための例です。実際にテストする際は、アクセス可能で用途を把握しているドメインに置き換えてください。

1つのページから、ログイン、画像、動画、APIなど複数のホストへリクエストが送られることがあります。メインサイトだけにルールを設定しても、すべてのリソースが同じ接続先を使うとは限りません。ページは表示されるのに画像を読み込めない場合は、まず接続履歴で失敗したリソースのドメインを特定し、完全一致ルールを追加するか、サフィックスの範囲を広げるか判断してください。

よくあるルールの疑問

ルールを管理するときは、目的が明確な例外を少数に絞ってください。変更のたびに「何に一致するか、どのポリシーに渡すか、どこに置くか」を記録し、接続履歴で確認します。通信の取り込み、ルールの一致、ポリシーグループの接続先を分けて確認すれば、「ルールを書いたのに変化がない」という問題の多くは、原因となる段階を特定できます。