高度な設定 読了目安 13分

Clashのカスタムルール構文を詳しく解説：マッチ条件・順序・優先度

ドメイン、IP、プロセス、フォールバックルールの書き方を整理し、上から順に評価される仕組みと、よくある適用失敗の原因を解説します。

PROOF / 01

ルールのマッチングモデル：上から順に評価し、最初の一致で停止

Clashのrulesは、行ごとに並んだトラフィックの振り分け表です。各ルールは通常、「タイプ、マッチ対象、ポリシー」で構成され、一部のタイプでは追加パラメータも指定できます。カーネルは接続を処理する際、リストの先頭から確認し、条件に一致する最初のルールを見つけると、その行で指定されたポリシーを直ちに適用します。後続のルールは評価されません。

ここでいう「優先度」は、ルールタイプによって自動的に決まるものではありません。DOMAINが自動的にDOMAIN-SUFFIXより優先されるわけではなく、IP-CIDRが前にあるドメインルールを自動的に上書きすることもありません。優先度を実際に決めるのは、リスト内の行位置です。そのため、範囲の広いルールを前方に置くと、後ろに記述したより具体的な例外ルールが先に捕捉されてしまうことがあります。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

この順序では、まずapi.example.comを直接接続し、それ以外の同ドメイン配下のサブドメインを「ノード選択」に振り分けます。先頭2行を入れ替えると、完全一致のドメインも先にサフィックスルールへ捕捉され、1行目の直接接続という例外が機能しなくなります。最後のMATCHはフォールバックルールで、それまでに一致しなかった接続を受け取ります。通常は1つだけを末尾に置きます。

PROOF / 02

ドメインルール：完全一致・サフィックス・キーワード

ドメインルールは、接続先のホスト名が明確なリクエストに適しており、カスタム振り分けで最もよく使われるタイプです。接続にドメイン情報が残っていれば、カーネルは接続先をIPに解決する前に直接マッチングできます。代表的なタイプは次のとおりです。

ルールタイプ マッチ範囲 主な用途
DOMAIN 完全一致のドメインのみ 単一のエンドポイントやホストに例外を設定
DOMAIN-SUFFIX 指定ドメインとそのサブドメイン サイト全体またはサービスドメイン単位で振り分け
DOMAIN-KEYWORD ドメイン内に含まれる文字列 命名規則は明確だがサフィックスが分散しているドメインを対象にする
GEOSITE データセットに収録されたドメイン分類 対応するデータセットを利用できるmihomo設定で一括振り分け 
rules:
  - DOMAIN,login.example.net,DIRECT
  - DOMAIN-SUFFIX,example.net,業務サービス
  - DOMAIN-KEYWORD,streaming,メディアノード
  - GEOSITE,cn,DIRECT
  - MATCH,ノード選択

DOMAIN,login.example.netはこの完全なホスト名だけに一致し、static.login.example.netには一致しません。DOMAIN-SUFFIX,example.netは通常、example.netとその各階層のサブドメインをまとめて対象にでき、サイト単位のルールに適しています。DOMAIN-KEYWORDは範囲を制御しにくく、接続先ドメインに指定文字列が含まれるだけで一致する可能性があります。そのため、十分に具体的なキーワードを使い、完全一致ルールの後ろに配置してください。

GEOSITEはデータセットを利用したマッチング方式です。利用できるかどうかや分類名の書き方は、使用するカーネル、クライアント、地理データファイルによって異なります。設定を移行する際は、あるクライアントで認識できる分類が、すべてのClash派生カーネルで使えるとは限りません。まずカーネルの種類とデータファイルが正しく読み込まれているかを確認してください。

PROOF / 03

IP、送信元アドレス、ネットワークプロトコルのルール

サービスをアドレス範囲でしか識別できない場合や、LANからの送信元、接続先の地域に応じて制御したい場合は、IP系のルールを使用できます。IPv4のアドレス範囲には通常IP-CIDR、IPv6にはIP-CIDR6を使います。GEOIPは地理データベースに基づいて接続先IPの分類を判定します。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

no-resolveは、マッチングのためにこのIPルールがドメイン解決を自動的に開始するのを防ぎます。接続自体に接続先IPが含まれている場合は、そのアドレスを引き続き確認できます。一方、接続先がドメイン名だけで、カーネルがまだ実際のアドレスを取得していない場合、このルールはDNS問い合わせを強制的に追加しません。LANのプライベートアドレス用ルールでは、通常のドメインを追加解決する必要がないため、このパラメータを付けることがよくあります。

no-resolveを付けるかどうかは、対象に応じて判断してください。GEOIPで解決結果をもとに直接接続かプロキシかを決めたい場合、解決を禁止すると必要なアドレスを取得できず、ルールが機能しないことがあります。逆に、主要サービスをドメインルールでカバーしており、IPルールがIPアドレスへ直接アクセスする接続だけを処理する場合は、このパラメータで不要な解決を避けられます。

Fake-IPモードでは、アプリがカーネルから割り当てられたプライベートアドレスを先に認識し、Clashがドメインと実際の接続先の対応関係を管理します。ドメインルールは通常、元のホスト名にもとづいて引き続き機能しますが、IPルールを調べる際は「アプリに表示されたFake-IP」「カーネルが保持するドメインの対応情報」「上流DNSが返した実IP」を区別する必要があります。ブラウザーやアプリに表示された接続先アドレスだけを見ると、ルールが一致したかどうかを誤って判断しやすくなります。

送信元アドレスとネットワークタイプ

SRC-IP-CIDRは、接続を開始したデバイスのアドレスでマッチングします。ルーターやLANゲートウェイの利用時に適しており、たとえば特定のテスト端末だけに専用ポリシーを適用できます。NETWORKはTCPまたはUDPで接続を区別し、より具体的なポート条件と組み合わせるのに向いています。すべてのUDP通信を早い段階で1つのポリシーに振り分けると、対象範囲が広くなりすぎることがあります。

rules:
  - SRC-IP-CIDR,192.168.50.25/32,テストポリシー
  - NETWORK,UDP,ノード選択
  - MATCH,DIRECT

デスクトップクライアントが本体の通信だけをプロキシする場合、送信元アドレスはルーターの透過プロキシ環境ほど有効な区別要素にならないことがあります。使用前に、クライアントの動作モード、TUNの取り込み範囲、カーネルが実際に取得できる接続メタデータを確認してください。

PROOF / 04

プロセス、パス、ポートによるマッチング

プロセスルールでは、接続を開始したアプリごとに通信を振り分けられます。PROCESS-NAMEは通常、実行ファイル名に一致し、PROCESS-PATHは完全なパスに一致します。同じドメインを複数のアプリが共有していて、特定のプログラムだけに専用ポリシーを適用したい場合に適しています。

rules:
  - PROCESS-NAME,example-client.exe,業務サービス
  - PROCESS-PATH,C:\Apps\Example\example-client.exe,業務サービス
  - DST-PORT,22,開発ノード
  - DST-PORT,123,DIRECT
  - MATCH,ノード選択

プロセスを識別できるかどうかは、OSの権限、クライアントの実装、カーネルのバージョン、通信の取り込みモードに左右されます。Windows、macOS、Linuxではプロセス名やパスの表現が異なり、モバイルOSではデスクトップ向けの実行ファイルルールをそのまま使えないこともあります。ログに接続先アドレスしかなく、プロセス情報がない場合、プロセス名を調整し続けても解決しません。まず現在のプラットフォームがプロセスメタデータを提供できるか確認してください。

DST-PORTは接続先ポート、SRC-PORTはローカルの送信元ポートでマッチングします。接続先ポートは送信元ポートより安定しますが、それだけで用途を特定できるわけではありません。たとえばTCP 443は多くのHTTPSサービスで共用されているため、これを早い段階で単一のプロキシポリシーにすると、大半のWeb接続をまとめて上書きしてしまいます。ポートルールは、用途が明確なプロトコルの処理や、mihomoの論理結合ルールでドメイン・ネットワークタイプと組み合わせて条件を絞る場合に適しています。

PROOF / 05

ルール順序と優先度の実践的な組み立て

管理しやすいルール表は通常、「例外を前に、通常ルールを中央に、フォールバックを後ろに」配置します。まず、必ず直接接続または拒否したい正確なホストを置き、次に業務ドメインやプロセスルールを記述します。その後にアドレス範囲や地域分類を処理し、最後にMATCHで受け止めます。実際の目的に合わせて順序を調整し、固定テンプレートを機械的に当てはめないことが重要です。

  1. ローカルおよび管理用アドレス：ルーターの管理画面、LANのアドレス範囲、ローカルサービスは通常、先に直接接続へ振り分け、広範なプロキシルールに捕捉されないようにします。
  2. 完全一致の例外：DOMAIN、単一アドレスのCIDR、明確なプロセス名を使って特殊な要件を処理します。
  3. 業務ルール：ドメインサフィックス、ルールセット、アプリのプロセスにもとづいて、対応するポリシーグループへ振り分けます。
  4. 広範な分類：地理データベース、キーワード、大規模なルールセットは、より具体的なルールの後ろに置きます。
  5. 最終フォールバック：MATCHを想定するデフォルトポリシーへ向けます。
rules:
  # LAN
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 完全一致の例外
  - DOMAIN,update.example.org,DIRECT
  - DOMAIN,blocked.example.org,REJECT

  # 通常の業務通信
  - DOMAIN-SUFFIX,example.org,業務サービス
  - PROCESS-NAME,media-player.exe,メディアノード

  # 地域分類とフォールバック
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

コメントはルールの動作を変えませんが、後から検証する手間を大幅に減らせます。出どころだけでなく、各ルールグループの用途を記載するのがおすすめです。サブスクリプションを更新したり、設定を手動で統合したりした後も、カスタム部分が想定した位置に残っているかをすぐ確認できます。特にクライアントの上書き機能には注意が必要です。カスタムルールを先頭に挿入するもの、末尾に追加するもの、サブスクリプション更新時に設定全体を再生成するものがあります。

PROOF / 06

ルールセットとmihomoの論理ルール

ルールが多い場合は、rule-providersを使ってルール内容を独立したファイルに分け、メインのルール表からRULE-SETで参照できます。ルールセットはマッチ項目を保持しますが、全体の優先度を決めるのはメイン設定内での参照位置です。設定の先頭でルールセットを定義しても、他のルールより自動的に先に実行されるわけではありません。

rule-providers:
  service-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/service-domains.yaml
    url: https://rules.example.net/service-domains.yaml
    interval: 86400

rules:
  - DOMAIN,internal.example.net,DIRECT
  - RULE-SET,service-domains,業務サービス
  - MATCH,ノード選択

behaviorはルールファイルの内容と一致していなければなりません。ドメイン系のセットにはdomain、IP範囲のセットにはipcidrを使えます。複数の一般的なルールタイプを含むセットには、通常classicalを指定します。カーネルのバージョンによって、format、対応するbehavior、データファイル形式が異なる場合があります。既存のルールセットを導入する前に、クライアント画面の名称だけで判断せず、実際に使用されているカーネルを確認してください。

mihomoには論理結合機能もあり、AND、OR、NOTを使って複数の条件を1つのルールにまとめられます。たとえば、UDP 443だけを処理する条件は次のように記述できます。

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),REJECT
  - MATCH,ノード選択

論理ルールは「複数の条件を同時に満たす」「いずれか1つを満たす」といった複雑な条件の表現に適しています。ただし、括弧、カンマ、ネストの階層は記述ミスが起こりやすい部分です。これはmihomoなど互換カーネルの拡張機能であり、古い純正Clashカーネルへ移行すると認識されない可能性があります。設定の可読性を保つため、2～3本の明確な通常ルールで解決できる場合は、無理に深いネスト構造へ置き換えないでください。

PROOF / 07

ルールが適用されないときの確認手順

ルールが機能しない原因は、単純な構文ミスだけとは限りません。「設定が読み込まれているか、接続がカーネルに入っているか、メタデータが想定どおりか、前のルールに捕捉されていないか」の順に確認すると、効率よく切り分けられます。

  1. 使用中のProfileを確認：ファイルを編集したら設定を再読み込みし、クライアントで現在有効になっている設定名を確認します。無効なコピーを変更しても、実行結果は変わりません。
  2. 接続画面やログで一致したルールを確認：接続先ドメイン、接続先IP、プロセス、ネットワークタイプ、最終ポリシーを記録します。より前方のルールに一致している場合は、順序を変更するか、そのルールの範囲を狭めてください。
  3. YAMLの階層を確認：rulesは正しいトップレベル位置に置き、リスト項目にはハイフンを使います。全角カンマ、誤ったインデント、不可視文字によって解析に失敗することがあります。
  4. ポリシーグループ名を確認：ルールが参照する名前が実際に存在することを確認します。プロキシグループの名前を変更した場合は、既存ルールの宛先名も合わせて変更してください。
  5. ドメインとIPを区別：アプリがIPアドレスへ直接アクセスする場合、ドメインルールが照合できるホスト名はありません。暗号化DNS、TUN、Fake-IPを有効にしている場合も、カーネルログと合わせて実際のメタデータを確認してください。
  6. クライアントの上書きを確認：サブスクリプション更新、スクリプトによる統合、GUIのルール上書きによって最終的な順序が変わることがあります。実行時の設定を基準に判断してください。
  7. カーネルの対応状況を確認：GEOSITE、論理ルール、一部のプロセス情報、ルールセット形式は、すべてのカーネルバージョンで同じようにサポートされているわけではありません。

最小構成のルールセットで再現する

元の設定に数千本のルールがある場合は、一時的にテスト用ルールとMATCHだけを含む最小構成を作成できます。まず対象ドメインが完全一致ルールにマッチするかを確認し、その後サフィックス、ルールセット、GEOIP、プロセス条件を段階的に追加します。一度に1グループだけ追加すれば、どの行が結果を変えたのか特定しやすくなります。

rules:
  - DOMAIN,test.example.com,DIRECT
  - MATCH,ノード選択

最小構成では一致するのに完全な設定では一致しない場合、原因は通常、前方のルール、上書き順序、またはルールセットの範囲にあります。最小構成でも一致しない場合は、通信がClashに入っているか、接続先に本当にそのドメインが付いているか、クライアントが現在テスト用設定を読み込んでいるかを確認してください。

公開前の検証チェックリスト

  • 完全一致の例外が、範囲の広いサフィックス、キーワード、ルールセットより前に配置されているか。
  • すべてのポリシー名がプロキシグループ名と一致しているか。
  • IPv4、IPv6、LANのアドレス範囲に、それぞれ適切なルールタイプを使用しているか。
  • no-resolveを、明示的な名前解決が不要なIPルールにだけ使用しているか。
  • プロセスルールが、現在のOSとカーネルの識別方式に合っているか。
  • ルールセットのbehaviorが、内容の形式と一致しているか。
  • リスト末尾に、想定したフォールバック処理が1つだけ残っているか。

安定したClashカスタムルールに必要なのは、ルールの本数ではなく、境界が明確で、順序を説明でき、実行結果を再確認できることです。まず完全一致ルールで例外を表現し、段階的にマッチ範囲を広げ、最後にログで最初に一致したルールを確認する方が、キーワードを追加し続けるより確実です。

Clashをダウンロード