Clashのカスタムルール構文と優先順位｜DOMAIN・IP-CIDR・MATCH | Clash 全プラットフォームダウンロード

ルールの判定順序：上から確認し、最初に一致したルールを適用

Clashクライアントをルールモードで使う場合、カーネルは設定ファイルのrulesリストを上から順に確認します。条件に合うルールが見つかると、そのルールで指定されたポリシーに接続を渡し、より「詳細な」ルールを探すことはありません。つまり、ルールの記述順そのものが優先順位です。DOMAINがIP-CIDRより常に優先される、といった共通の並び順はありません。

以下の例では、設定に「プロキシ選択」というプロキシグループがすでにあるものとします。この名前はproxy-groups内のnameと完全に一致させてください。例示ドメインのexample.comは構文の説明用であり、このサイトに特定のポリシーを適用することを意味しません。

mode: rule

rules:
  - DOMAIN,api.example.com,プロキシ選択
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,プロキシ選択

api.example.comにアクセス：最初のルールに一致し、「プロキシ選択」が適用されます。
www.example.comにアクセス：最初のルールには一致せず、2つ目のルールに一致してDIRECTが適用されます。
前の2つのルールに一致しない宛先への接続は、最後のMATCHで処理されます。

2つ目のルールを1つ目より前に置くと、api.example.comも先にサフィックスルールに一致し、直接接続されます。後ろに正しく記述した完全一致のドメインルールは、もう確認されません。ルールを管理するときは、まず例外を決めてから、より広い範囲をカバーするルールを配置します。

DOMAIN系ルール：完全一致・サフィックス・キーワード

ドメインルールは通常、「ルールタイプ、マッチ対象、適用ポリシー」の3項目で記述します。指定するのは完全なURLではありません。https://、ポート、パス、クエリパラメーターは付けないでください。https://api.example.com/v1/statusに一致させる場合は、URL全体ではなくapi.example.comと記述します。

よく使うドメインルール3種類のマッチ範囲
タイプ	例	マッチ結果
DOMAIN	`DOMAIN,example.com,DIRECT`	example.comだけに一致し、www.example.comには一致しません。
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,DIRECT`	example.comとそのサブドメインに一致し、notexample.comには一致しません。
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,プロキシ選択`	ドメイン名にexampleという文字列を含む宛先に一致します。サフィックスルールより広い範囲が対象です。

例外ドメインはサフィックスルールより前に配置

rules:
  - DOMAIN,download.example.com,プロキシ選択
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - MATCH,プロキシ選択

この順序なら、ダウンロード用ドメインの接続先を個別に指定してから、ドメイン全体のサフィックスを処理できます。キーワードルールはサフィックスルールの後にあるため、telemetry.example.comにキーワードが含まれていても、先にexample.comのサフィックスルールに一致し、直接接続されます。拒否したい場合は、REJECTが自動的に最優先になると考えず、該当ドメインの完全一致ルールを前に配置してください。

キーワードルールは範囲を絞って使う

DOMAIN-KEYWORD,ad,REJECTは、多くの正常なドメインに含まれる短い文字列にも一致し、意図しない接続まで拒否するおそれがあります。完全なドメイン名が分かっている場合はDOMAINを、複数のサブドメインを対象にする場合はDOMAIN-SUFFIXを使いましょう。キーワードルールは、共通の命名パターンがあり、マッチ範囲を確認できている宛先に適しています。

ドメインルールで判定するには、接続メタデータに利用可能なドメイン名が必要です。アプリがIPアドレスへ直接接続する場合や、DNSの経路が異なる場合、ドメインスニッフィングが機能していない場合は、接続記録に宛先アドレスしか残らないことがあります。ブラウザーのアドレスバーにドメインが表示されているだけでは、カーネルが対応するDOMAINルールに一致すると断定できません。

IP-CIDRとno-resolve：名前解決の実行を制御

IP-CIDRは宛先のIPv4アドレスを使ってネットワーク範囲を判定します。IPv6には通常IP-CIDR6を使います。CIDRの後ろの数字はネットワークプレフィックス長です。IPv4の/32は単一のアドレスを表し、192.168.1.0/24は192.168.1.0から192.168.1.255までの範囲を表します。

rules:
  - IP-CIDR,192.168.1.10/32,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,プロキシ選択

no-resolveは、このIPルールの判定だけを目的として、未解決の宛先ドメインを新たに名前解決しないための指定です。「DNSを無効にする」指定でも、「すべてのドメインがこのルールを通らなくなる」指定でもありません。宛先IPがすでに分かっていれば、そのアドレスを使ってネットワーク範囲を判定できます。利用可能な宛先IPがない場合は、ルール判定のための名前解決は行われません。

2種類の接続経路の違い

アプリが192.168.1.10:443に直接接続：宛先IPが分かっているため、単一アドレスのルールに一致します。no-resolveがこの判定を妨げることはありません。
アプリがnas.example.comを指定：カーネルが実際の宛先IPをまだ取得していない場合、no-resolve付きのネットワーク範囲ルールは名前解決を行いません。そのまま後続のルールに進むことがあります。

このNASのドメインを必ず直接接続したい場合は、発動するとは限らないIP判定に頼らず、通常はDOMAIN,nas.example.com,DIRECTを追加します。名前解決結果に応じて接続を振り分ける必要があるドメインでは、DNS設定も確認したうえで、該当ルールからno-resolveを外すか判断してください。

fake-ip環境でクライアントに表示される合成アドレスも、Webサイトの実際のサーバーアドレスとは限りません。接続の詳細、ドメインとの対応関係、DNSログを確認してください。特定のサイトの問題を解決するために、fake-ipのアドレスプール全体を直接接続ルールへ追加するのは避けましょう。

ポリシーとMATCH：接続先の選択とフォールバック

ルールの末尾に指定するのはポリシーであり、必ずしも個別のプロキシノードとは限りません。DIRECTは直接接続、REJECTは接続拒否を表します。任意の名前を指定して、定義済みのプロキシやプロキシグループを参照することもできます。「プロキシ選択」に一致した場合、実際の接続先はグループ内で現在選択されているメンバーによって決まります。

接続詳細に「プロキシグループに一致」と表示されても、実際には直接接続されていることがあります。必ずしもルールの不具合とは限りません。グループ内でDIRECTが選択されていないか、DIRECTを含む別のグループを経由していないか、自動選択グループが現在どの接続先を選んでいるかを確認してください。ルールの一致判定と最終的な接続先の決定は、連続して行われる別々の処理です。

rules:
  - DOMAIN,blocked.example.com,REJECT
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,プロキシ選択
  - MATCH,プロキシ選択

MATCHは最後のフォールバックに配置

MATCHにはドメイン名やネットワーク範囲の引数がなく、構文はMATCH,ポリシーだけです。この行に到達した接続には無条件で一致します。ルールリストの先頭に置くと、後続のルールはすべて実行されません。2つのルールセットの間に置いた場合も、2つ目のルールセットは確認されません。

未分類の通信をプロキシグループに送る場合：MATCH,プロキシ選択を指定します。
未分類の通信を直接接続する場合：MATCH,DIRECTを指定します。
明示した接続だけを許可する場合は、MATCH,REJECTを使えます。ただし、必要な接続先を先に許可しておかないと、ログインや更新、コンテンツの読み込みまで拒否されるおそれがあります。

フォールバックポリシーを変更すると、未分類の通信の多くに影響します。変更前に現在の設定を保存し、変更後はWebサイトのトップページが開くかだけでなく、一連の利用手順を確認してください。

mihomoのルールセット：配置場所が優先順位を決める

mihomoではrule-providersでルールセットを管理し、RULE-SETで参照できます。ルールセットはメインリストとは別の優先順位で動くわけではありません。RULE-SETは記述した行の位置で判定されます。前の通常ルールに一致した場合、後続のルールセットは実行されません。

以下はmihomoでローカルファイルのルールセットを使う例です。既存の設定に統合し、元のノードと「プロキシ選択」グループは残してください。./rules/work.yamlがカーネルの設定作業ディレクトリから参照できる場所に存在することを確認してください。宣言だけ追加してファイルを用意し忘れないようにしましょう。

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

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work,プロキシ選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,プロキシ選択

対応するwork.yamlの内容は次のとおりです。適用するポリシーは参照元のRULE-SETで指定するため、classicalルールセット内の各項目に「プロキシ選択」を追加する必要はありません。

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,203.0.113.0/24

203.0.113.0/24はドキュメント用のサンプルネットワークであり、実際の通信にそのまま使える宛先ではありません。実際の設定では、サービス提供元から指定されたネットワーク範囲を使用してください。ここではlogin.example.comがメインリストの1行目に先に一致するため、workルールセット内のドメインサフィックスに該当しても、直接接続されます。

behaviorとファイルの内容を一致させる

classical：DOMAIN-SUFFIXやIP-CIDRなどのルールタイプを含む項目に使います。複数の種類を混在させる場合に適しています。
domain：項目はドメインのマッチ対象です。ルールタイプの接頭辞が付いたclassical形式の項目を、そのままコピーしないでください。
ipcidr：項目はIPネットワーク範囲です。ドメインのリストではありません。

これらの設定例はmihomoの構文に基づいています。ルールセットの形式や拡張タイプへの対応状況はClashのカーネルによって異なるため、クライアントに表示されるカーネル情報と設定の検証結果を確認してください。ファイル名が同じでも、古いカーネルがすべての項目を読み込めるとは限りません。

カスタムルールの並べ方とサブスクリプションによる上書き

ルールが増えたら、末尾に追加し続けるのではなく、「明確な例外 → 分類ルール → フォールバック」の順で管理するのがおすすめです。以下は見直しやすい並べ方の一例です。拒否ルールを最上部に置くかどうかは、業務上どの例外を許可するかによって決めます。

他の分類ルールより優先させる完全一致ルール。 例：特定のログインドメインを直接接続する、特定のトラッキング用ドメインを拒否する。ルールが競合する場合は、どちらを先に判定するか明確に決めてください。
ローカルサービスとLAN内の宛先。 ドメインが分かっている場合はドメインルール、ネットワーク範囲が分かっている場合はIPルールを使い、名前解決が必要かどうかも確認します。
用途別の分類とルールセット。 オフィス、メディアなどの用途ごとに分けます。範囲が重なるルールセットは、優先する分類を前に配置してください。
広範囲のドメイン・地域・IPの分類。 対象範囲が広いルールセットは、後続の例外ルールに先に一致するおそれがあります。並べ替え後は一部の対象で動作を確認してください。
最後にMATCHを配置。 未分類の接続をどこへ送るか明確にし、その後ろには実行が必要なルールを置きません。

サブスクリプションの更新でメイン設定が再生成される場合があります。サブスクリプションから生成されたYAMLを直接編集しても、次回の更新で変更が失われる可能性があります。クライアントにルールの上書き・マージ・カスタム設定の保存機能があれば、それを使ってください。設定項目の名前や場所はクライアントごとに異なるため、特定の画面のメニュー操作をすべてのClashクライアント共通の設定として案内することはできません。

特に「末尾に追加」と「先頭に追加」の違いを確認してください。カスタムルールがサブスクリプション内のMATCHより後ろに追加されると、設定に存在していても一致することはありません。編集画面の内容だけでなく、カーネルが最終的に読み込んだルールリストを確認し、統合後の実際の位置を確かめてください。

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

トラブルシューティングでは、一度に変更する条件を1つに絞ります。まずapi.example.comのように対象を1つ決め、期待するポリシーを記録したうえで、新しい接続に適用されたルールと最終的な接続先を確認してください。ブラウザーが既存の長時間接続を再利用している場合、ページを再読み込みしても新しい接続が作られるとは限りません。

通信がカーネルを通っているか確認。 システムプロキシを使うのは、システムのプロキシ設定に従うアプリだけです。カーネルを経由しない接続にはrulesが適用されません。TUNを使う場合も、対象の通信がルーティングの範囲に含まれている必要があります。
実行中の設定とモードを確認。 変更した設定が読み込まれているか、実行モードがルールになっているか、サブスクリプションの切り替えで別の設定が読み込まれていないかを確認してください。
構文エラーを確認。 YAMLのインデントにはスペースを使い、タブは使いません。ルールタイプのスペル、カンマの数、ポリシー名も確認してください。トップレベルのrulesキーが重複している場合は、1つのリストにまとめます。
先に一致するルールを確認。 対象をカバーするDOMAIN-SUFFIX、キーワード、RULE-SETや、前に配置されたMATCHがないか調べます。ログに記録された実際の一致ルールは、予想していたルールより有力な判断材料です。
宛先のメタデータを確認。 接続記録にドメインとIPのどちらが表示されているか、IPv6かどうか、名前解決済みかを確認します。IPv4ネットワークのルールだけでは、IPv6の宛先には一致しません。
テスト用の接続を作り直す。 中断しても問題ない場合は、対象の既存接続を閉じるか、テストに使うアプリを終了して再起動し、新しい接続のルール判定を確認してください。

管理しやすいルール設定では、次の3点を説明できる必要があります。なぜこの接続がこの行に一致したのか、その行がどのポリシーに接続を渡すのか、そのポリシーが最終的にどの接続先を使うのか。この3段階を分けて確認すれば、DOMAIN、IP-CIDR、ルールセット、MATCHの関係を個々の接続に即して把握でき、設定ファイル上の並び順だけに頼らずに済みます。