高度な設定 読了目安 12分

Clashのカスタムルール構文を徹底解説：マッチング順序・優先度・ルール上書き

主要なルール種類、上から順に判定される仕組み、フォールバックの置き場所、カスタムルールが反映されない場合の確認方法を解説します。

Clashのルールシステムが答えるのは、新しい接続をどのポリシーグループ、プロキシノード、またはダイレクト接続に振り分けるかという具体的な問題です。多くの「ルールが効かない」ケースは、構文そのものの誤りではありません。より前にあるルールが先にマッチした、変更内容がサブスクリプション更新で置き換わるファイルに書き込まれた、あるいはテスト通信が実行中のカーネルに届いていない、といった原因です。

ルールを読むときは、ドメイン名、宛先IP、プロセス、ポート、ネットワークプロトコルを別々のマッチング条件として捉えます。ルールリストは「より具体的に見える順」に自動整列されず、記述が長いからといって優先度が高くなることもありません。実際の判定は通常、rules リストを上から下へ進み、最初にマッチしたルールのポリシーを直ちに採用します。その接続について、後続のルールは判定に参加しません。

マッチングモデル：接続がルールに到達するまで

アプリがアクセスを開始すると、Clashまたはmihomoカーネルは宛先情報を取得する必要があります。ブラウザのプロキシリクエストでは、カーネルが宛先ドメインを直接確認できることが一般的です。一方、一部の透過プロキシやTUN通信では、先に宛先IPを取得し、DNSマッピング、スニッフィング結果、接続メタデータを組み合わせてドメインを復元する場合があります。利用できる情報が異なるため、同じルールセットでも通信の取り込み方式によってマッチ結果が変わることがあります。

ルールリストに、特定の完全修飾ドメインをダイレクト接続するルール、そのドメインが属するサフィックスをプロキシへ送るルール、最後にフォールバックルールが順番に並んでいるとします。完全なドメインへアクセスすると、最初のルールですでにマッチするため、サフィックスルールは実行されません。サフィックスルールを前に置くと、サブドメイン全体を先に受け取るため、後ろにある完全ドメインの例外は機能しなくなります。ルール作成時に、通常は狭い範囲の例外を広い範囲のルールより前に置くのはこのためです。

rules:
  - DOMAIN,updates.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - MATCH,取りこぼし

上の例では、updates.example.com はダイレクト接続となり、example.com をサフィックスとするその他のドメインは「ノード選択」に入り、残りの接続は「取りこぼし」に渡されます。ここでいう「ノード選択」と「取りこぼし」は、設定内に実在するポリシーグループ名でなければなりません。名前に含まれる日本語、空白、大文字・小文字は、proxy-groups の定義と完全に一致させてください。

ルールのマッチとノードの利用可否は別の段階

ルールのマッチが決めるのは接続の送り先であり、ポリシーグループ内で選択されたノードが必ず利用できることを保証するものではありません。ログに「ノード選択」と表示されていてもページを開けない場合、問題はポリシーグループの現在の選択、ノードの接続性、DNSの応答、TLSハンドシェイク、上流ネットワークにある可能性があります。逆に、ノードの速度テストが正常でも、カスタムドメインルールがマッチした証明にはなりません。速度テストの宛先と実際のアクセス先は異なることが多いため、分けて確認します。

よく使うルール構文と適用範囲

従来型のルールは通常、カンマ区切りで記述します。先頭がルールタイプ、中間がマッチ対象、続いて適用先のポリシー、末尾にそのタイプがサポートする追加パラメータを指定します。対応するルールタイプはカーネルやクライアントのバージョンによって完全には一致しません。特にプロセス、インバウンド、ルールセット、論理結合に関する機能は差が出やすい部分です。編集前に、使用中のクライアントが従来のClashカーネルかClash Meta（mihomo）カーネルかを確認し、そのカーネルの設定ドキュメントと実行ログを基準にしてください。

DOMAIN：完全一致のドメイン

DOMAIN は指定した完全なホスト名だけにマッチし、単一の例外を設定するのに適しています。そのドメインの別のサブドメインまで自動的に対象にはしません。例：

- DOMAIN,api.example.com,DIRECT

このルールは api.example.com にはマッチしますが、img.api.example.com にはマッチしません。サイトがメインサイト、API、画像、ダウンロードなど複数のサブドメインを使う場合は、個別に列挙するか、サフィックスルールでドメイン全体を対象にします。

DOMAIN-SUFFIX：ドメインサフィックス

DOMAIN-SUFFIX は特定のドメインとそのサブドメインにマッチし、サイト単位の振り分けに適しています。

- DOMAIN-SUFFIX,example.com,ノード選択

example.com、www.example.com、さらに深い階層のサブドメインまで対象にできます。サフィックスルールは範囲が広いため、その中の更新用ドメインだけをダイレクト接続にしたい場合は、対応する DOMAIN の例外を前に置きます。

DOMAIN-KEYWORD：ドメインキーワード

DOMAIN-KEYWORD は、ドメイン名に指定した文字列が含まれているかを確認します。短く書ける一方、想定より広い範囲に誤マッチしやすい点に注意が必要です。たとえば music というキーワードは、互いに関係のない複数のドメインにもマッチする可能性があります。対象ドメインの構造が頻繁に変わり、安定した特徴がある場合を除き、完全一致のドメインまたはドメインサフィックスを優先してください。

- DOMAIN-KEYWORD,example,ノード選択

IP-CIDR と IP-CIDR6：宛先アドレス範囲

IP-CIDR はIPv4アドレス範囲に、IP-CIDR6 はIPv6アドレス範囲にマッチします。社内ネットワーク、固定サービスアドレス、明確に公開されたネットワーク範囲に適しています。

- 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

no-resolve は、このIPルールを判定するとき、IPを取得するためにドメイン名を追加で解決しないことを示します。既存の宛先IPだけを確認したいプライベートアドレス範囲などでよく使われます。このパラメータを付けるかどうかはルールの目的に応じて決めてください。ドメイン接続の解決後にも特定のIP範囲の判定へ参加させたい場合、すべてのIPルールに機械的に no-resolve を付けるべきではありません。

GEOIP、GEOSITE とルールデータ

GEOIP は、宛先IPが属する地域データベースの分類に基づいてマッチします。mihomoでよく使われる設定では、GEOSITE によってドメインを集合単位で分類することもできます。これらのルールはクライアントが読み込む地理データファイルに依存し、マッチ結果はデータのバージョンにも左右されます。広範囲の分類には適していますが、すべてのドメインやアドレスが将来も同じ所属になるとは限りません。安定した例外が必要な場合は、分類ルールより前に完全一致ルールを追加してください。

- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,ノード選択

従来のClashブランチでは、同じGEOSITE構文やデータ読み込み方式に対応していない場合があります。設定チェックで未知のルールタイプが指摘されたら、インデントを何度も調整するのではなく、まずカーネルの対応状況を確認してください。

ポート、ネットワークプロトコル、プロセスルール

DST-PORT は宛先ポートで振り分け、NETWORK はTCPとUDPを区別できます。プロセスルールはプログラム名やパスでマッチできますが、OSの権限、カーネルの実装、クライアントが関連メタデータを提供するかどうかに依存します。モバイルOS、制限付きサンドボックス、一部の透過プロキシ環境では、カーネルがプロセス情報を確実に取得できないことがあります。

- DST-PORT,22,業務用回線
- NETWORK,UDP,低遅延回線
- PROCESS-NAME,example.exe,DIRECT

ポートルールは配置に注意が必要です。443のような一般的なポートは多種多様なサービスで使われるため、ドメインルールより前に置くと、ほぼすべてのHTTPS接続が先に振り分けられる可能性があります。プロセスルールも、プログラム名だけを根拠にセキュリティ境界を設定するのは避けてください。アプリが別のシステムプロセスを呼び出して接続することがあるためです。

順序と優先度：より具体的なルールが効かない理由

ルールリストには、自動計算される「具体性優先」の仕組みはありません。DOMAIN が前にある DOMAIN-SUFFIX より自動的に優先されることも、小さなIP範囲が前の大きな範囲を自動的に上回ることもありません。前方のルールが条件を満たした時点で、その接続は下へ検索されなくなります。そのため、カスタムリストは通常、「明確な例外、具体的な分類、広範囲の集合、地域分類、最終フォールバック」の順に構成します。

  1. ローカルおよび必要なダイレクト接続の例外：LANアドレス、ルーター管理用ドメイン、社内ネットワーク、または明確にダイレクト接続が必要な更新サービス。
  2. 完全一致のドメインとプロセスの例外：後続のサフィックスルール、ルールセット、地域分類を上書きするために使います。
  3. サイト単位のサフィックスルール：安定した複数のサブドメインを同じポリシーへ振り分けます。
  4. ルールセット：大規模なドメイン、アドレス範囲、サービス分類を管理します。
  5. GEOIP、GEOSITEなどの広範囲判定：前のルールで対象にならなかった接続を処理します。
  6. MATCHによるフォールバック：まだマッチしていない残りの通信を受け取り、リストの末尾に置きます。

MATCH は残りの接続にマッチするため、その後ろにある通常のルールは実行時にはほぼ機能しません。古い設定では、似たフォールバックの意味を FINAL で表していることがありますが、受け付ける名称はカーネルによって異なる場合があります。設定を移行するときは文字列だけを置き換えず、設定検証を実行してカーネルログを確認してください。

同じドメインから複数の接続が発生することがある

Webページへのアクセスは単一のリクエストではありません。メインドキュメント、静的リソース、動画、計測API、サードパーティーログインは異なるドメインから提供されることがあり、HTTP/3ではUDPが使われる場合もあります。メインドメインが想定どおりのポリシーにマッチしていても、ページ内のすべての接続が同じ経路を使うとは限りません。サイトのトラブル解決では、アドレスバーのドメインにルールを1つ追加するだけでなく、接続一覧やログで実際に失敗したホスト名、宛先ポート、ネットワークプロトコル、マッチしたルールを確認します。

DNSの結果がIPルールの確認に影響する

ドメインルールはカーネルが把握しているホスト名に基づいて判定し、IPルールは宛先アドレスに依存します。アプリが独自に暗号化DNSを使う、キャッシュ済みのIPへ直接接続する、TUNのスニッフィングでドメインを復元できない、といった場合、ログにはIPしか表示されないことがあります。この場合、ドメインルールに利用できるマッチ条件がない可能性があります。逆にfake-ipモードでは、カーネルが仮想アドレスとドメインの対応を管理するため、接続画面に表示されたアドレスだけで実際の上流IPを判断することはできません。DNSモード、ログのドメイン項目、最終的なルール名を組み合わせて分析してください。

ルールセットとRULE-SET：大規模設定を分割する

ルール数が多い場合、mihomoなどのカーネルでは rule-providers で外部ルールセットを定義し、メインのルールリストから RULE-SET を使って参照できます。これにより、ドメイン分類、アドレス範囲、メイン設定を分けて管理できます。ルールセットが自動的に高い優先度を得るわけではありません。メインの rules リスト内でどの位置から参照するかによって、マッチに参加するタイミングが決まります。

rule-providers:
  work-services:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/work-services.yaml
    url: https://example.com/rules/work-services.yaml
    interval: 86400

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - RULE-SET,work-services,業務用回線
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

behavior は、集合の内容をどのように構成するかを示します。一般的な値には classical、domain、ipcidr があります。クラシカル集合にはタイプ付きのルール項目を格納できますが、ドメイン集合とアドレス範囲集合は、それぞれ対応する形式で記述する必要があります。集合を domain と宣言しているのに、完全なクラシカルルール文字列を入れると、プロバイダーのダウンロードは成功しても解析に失敗したり、設定チェックの段階で直接エラーになったりします。

リモート集合には、更新時刻、キャッシュパス、ネットワーク到達性も関係します。初回起動時に集合がまだダウンロードされておらず、現在の設定がその集合に依存していると、クライアントが初期化失敗を表示することがあります。トラブル解決では、プロバイダーの状態、最終更新時刻、解析エラーを確認してください。集合URLをブラウザで開けるかどうかだけをテストしてはいけません。URLにアクセスできるのはファイルをダウンロードできることを示すだけで、内容の形式が現在のカーネル要件に合っている証明にはなりません。

複数の集合が重複する場合の判定

2つのルールセットに同じドメインが含まれたり、アドレス範囲が重複したりすることがあります。結果を決めるのは集合の更新時刻でも項目数でもなく、メインのルールリストにおける2つの RULE-SET 参照の順序です。公開集合を上書きしたい場合は、まずローカルの完全一致例外を置き、次に自分の小規模な集合を参照し、最後により広い公開集合を参照します。

rules:
  - DOMAIN,build.example.com,DIRECT
  - RULE-SET,my-exceptions,専用回線
  - RULE-SET,public-services,ノード選択
  - MATCH,取りこぼし

この構成は、大規模な公開集合を直接コピーして編集するよりも保守しやすい方法です。例外が明確になり、公開集合が更新されてもファイル全体を再統合する必要がありません。

サブスクリプション更新、上書き、設定の永続化

多くのデスクトップ・モバイルクライアントは、リモートサブスクリプションをローカル設定ファイルとしてダウンロードします。生成されたファイルを直接編集するとすぐに反映される場合がありますが、次回の自動更新、手動更新、サブスクリプションの切り替えで変更内容が新しいファイルに置き換わることがあります。安定した方法は、クライアントが提供する上書き、マージ、拡張スクリプト、ローカル設定機能を使い、カスタムルールをサブスクリプションファイルの外に保存することです。

クライアントによって、「前置ルール」「後置ルール」「マージルール」の扱いは異なります。前置ルールは通常、サブスクリプションのルールより先に適用する必要がある完全一致例外に適しています。後置ルールをサブスクリプションに含まれる MATCH の後ろへ追加しても、実際の効果はありません。上書き画面を使った後は、最終生成設定または実行ログを開き、ルールが想定した位置に本当に挿入されていることを確認してください。

ポリシーグループ名も依存関係の一部

カスタムルールが「業務用回線」を参照するなら、最終設定にも同名のポリシーグループが存在していなければなりません。サブスクリプション提供元がグループ名を変更したり、クライアントの設定変換やマージスクリプトがグループ名を変更したりすると、ルールが存在しない宛先を指し、読み込みに失敗することがあります。より安全な方法は、カスタムポリシーグループも同じ永続化機能から注入し、頻繁に変わる表示名への依存を避けることです。

変更後は実行設定を再読み込みする

YAMLファイルを保存しただけで、実行中のカーネルが新しいルールを直ちに採用するとは限りません。自動再読み込みに対応するクライアントもあれば、適用ボタンのクリック、設定の再選択、カーネルの再起動が必要なクライアントもあります。再読み込みに成功したかは、設定の更新時刻、カーネルログ、接続詳細に表示されるルールの変化で確認できます。既存の長時間接続は確立時の経路を使い続けることがあるため、テスト時は対象アプリの接続を閉じ、ページを更新するか、古い接続が終了するまで待ってください。

カスタムルールが反映されない場合の段階的な確認

トラブル解決は「現在、実際に何が実行されているか」の確認から始め、続いてマッチ条件を調べます。DNSの変更、TUNの切り替え、ノードの変更、クライアントの再インストールを頻繁に行うと、複数の変数が同時に変わり、原因を特定しにくくなります。次の手順は、ドメインルール、IPルール、ルールセットの多くの障害に適しています。

  1. 正しい設定が使用されていることを確認する。

    クライアントで現在選択されているサブスクリプションまたは設定名と、最終読み込み時刻を確認します。設定のコピーが複数ある場合は、編集したファイルがカーネルの現在の読み込み対象であることを確認してください。

  2. まず設定を検証する。

    クライアントの設定チェック結果とカーネルの起動ログを確認します。YAMLのインデント、カンマ区切り、未知のルールタイプ、重複キー、ルールセットの解析失敗、存在しないポリシーグループに注目してください。

  3. 通信がClashを経由していることを確認する。

    システムプロキシが無効、アプリがプロキシを回避、アプリ独自のプロキシ設定がシステム設定を上書き、またはTUNが起動していない場合、接続はルールエンジンを通りません。接続一覧にテスト通信がまったく表示されないなら、まず取り込み方式を確認します。

  4. 実際にマッチしたルールを確認する。

    接続詳細またはログで、宛先ドメイン、宛先IP、プロセス、ポート、ネットワークプロトコル、ルールタイプ、ポリシー名を確認します。前方の広範囲ルールにマッチしていた場合は、同じドメインを繰り返し追加するのではなく、順序を調整してください。

  5. ドメインとIPの条件が確認できる状態か調べる。

    ログにIPしか表示されない場合、ドメインルールに必要なマッチ情報が不足している可能性があります。ドメインがすでにマッチしているなら、後続のIPルールを疑い続ける必要はありません。DNSモード、スニッフィング設定、アプリの動作を合わせて判断します。

  6. ポリシーグループの現在の選択を確認する。

    ルールが正しいポリシーグループへ送られた後、グループ内で具体的なノード、自動テストグループ、ダイレクト接続、拒否のいずれが選択されているか確認します。ポリシーグループの選択ミスとルール順序のミスは、見た目が同じ結果になることがあります。

  7. 既存の接続とキャッシュを除外する。

    テスト対象アプリの既存接続を閉じ、必要に応じてアプリのDNSキャッシュを消去してから、新しい接続を開始します。ルールは主に接続確立時に判定されるため、リストを変更しても既存セッションが自動的に再判定されることはありません。

  8. サブスクリプション更新後の結果を確認する。

    サブスクリプションを手動で一度更新し、カスタムルールが残っていて位置も変わっていないことを確認します。更新後に消える場合は、クライアントが対応する上書きまたはマージ機能へ移行してください。

設定全体より最小構成のテストのほうが特定しやすい

数千件のルールを扱う場合は、十分に具体的で結果が明確なテストルールを一時的に追加し、リストの前方に置くとよいでしょう。たとえばテスト用ドメインを専用のポリシーグループへ送るルールを追加し、新しい接続のマッチ記録を確認します。テストが終わったらそのルールを削除し、診断専用の振り分け項目を長期的に残さないようにします。

rules:
  - DOMAIN,test.example.com,診断用回線
  - RULE-SET,main-services,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,取りこぼし

先頭に置いた完全一致ルールにもマッチ記録が現れない場合は、まず通信が現在のカーネルを通っているか、ドメインが実際のリクエストと一致しているか、設定の再読み込みに成功しているかを確認します。そのルールにはマッチするのに元のルールにはマッチしない場合は、ネットワークの基本設定を先に変更するのではなく、ルールの位置、タイプ、対象情報を比較してください。

保守しやすいルール一覧：動作する設定から確認しやすい設定へ

長期運用する設定では、ルール数だけを増やすべきではありません。広範囲のルールを1つ追加するたびに、どの場面を対象とするのか、なぜその位置に置くのか、既存の集合と重複しないかを説明できるようにします。例外が少ないユーザーにとっては、複数の似た大型集合を積み重ねるより、完全一致ドメインと安定したフォールバックを組み合わせるほうが判断しやすいことが多いでしょう。

  • LAN、社内ネットワーク、端末管理用アドレスを、明確なダイレクト接続の領域に置く。
  • 単一ドメインの例外を、対応するサフィックス、キーワード、ルールセットより前に置く。
  • ドメイン分類の代わりに汎用ポートルールを使わない。特に80や443など一般的なポートを早い位置でマッチさせない。
  • ルールセットの内容と一致する behavior を選び、更新状況と解析状態を定期的に確認する。
  • MATCH を末尾に置き、対象のポリシーグループが実際に存在することを確認する。
  • クライアントの上書き機能で個別ルールを保存し、サブスクリプションが生成するファイルへ直接依存しない。
  • 変更後に設定を再読み込みし、新しい接続でログ上の実際のマッチ項目を確認する。
  • mihomoへ移行したりクライアントを変更したりする場合は、ルールタイプと拡張構文の対応状況を改めて確認する。

明確なルール設定なら、上から下へ各段階を説明できます。まずどの例外を処理し、次にどの分類へ進み、最後に誰が残りの通信を受け取るのかを確認できます。最初のマッチ、情報の可視性、最終設定、ポリシーグループの状態という4つの確認ポイントを押さえれば、ルール上書きに関する多くの問題をログから直接たどれます。

サブスクリプションの取り込み、システムプロキシ、TUN、DNSの関係を確認したい場合は、当サイトの使用ガイドと設定チュートリアルも参照してください。ルールは振り分けを決めるだけで、完全な接続にはクライアントの取り込み方式、DNS設定、ポリシーノードが連携して動作する必要があります。

Clashをダウンロード