ルール応用 読了時間：約12分

Clash カスタムルールの書き方｜DOMAIN-SUFFIX・IP-CIDR・GEOIPとルールの評価順

Clashのルール形式と使い分け、上から順に評価して最初の一致で処理を決める仕組み、rule-providersとMATCHの配置を解説します。

ルールの形式：タイプ、マッチ対象、出力先ポリシー

Clashのカスタムルールは、YAML設定の rules: リストに記述します。ルールモードでは、リストの内容に従って接続の出力先が決まります。この記事ではClash共通のルール構文をもとに解説し、ルールセットの読み込みにはmihomoがサポートする設定を使用します。GUIクライアントは編集画面を提供しますが、ルールを実際に処理するのは有効なカーネルです。

mode: rule
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,ノード選択

これは既存の設定に追加する断片であり、サブスクリプション全体ではありません。例の ノード選択 は、既存の proxy-groups にあるポリシーグループ名を指定してください。設定内に存在するノード名に置き換えることもできます。大文字・小文字や空白も含め、名前は完全一致させます。存在しないポリシーを指定すると、設定の読み込みに失敗することがあります。

  • DOMAIN：ルールタイプです。2番目のフィールドの解釈方法を指定します。
  • example.com：マッチ対象です。ここではプロトコル、パス、ポートを含まない完全なドメイン名を指定します。
  • DIRECT：組み込みの直接接続ポリシーです。ローカルネットワークから接続先へ直接接続します。
  • REJECT：組み込みの拒否ポリシーです。一致した接続を遮断します。
  • no-resolve：一部のIPルールで使える追加パラメーターです。出力先の名前ではありません。

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

単一のホスト名だけに適用する場合は DOMAIN、ドメインとそのすべてのサブドメインに適用する場合は DOMAIN-SUFFIX を使います。サフィックスはドメインのラベル境界に沿って判定され、任意の文字列を探すものではありません。

ルールの例マッチするマッチしない
DOMAIN,example.com,DIRECTexample.comwww.example.com
DOMAIN-SUFFIX,example.com,DIRECTexample.com、api.example.comnotexample.com
DOMAIN-KEYWORD,example,DIRECTドメイン名に example を含むホストこの文字列を含まないドメイン

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

example.com 全体を直接接続し、api.example.com だけをプロキシ経由にする場合を考えます。まず完全一致のルールを書き、その後に対象範囲の広いサフィックスルールを記述します。

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

最初の2行を入れ替えると、APIドメインが先にサフィックスルールに一致して直接接続されます。後ろにより具体的なルールがあっても、カーネルが選び直すことはありません。DOMAIN-KEYWORD は対象範囲が広く、無関係なドメインまで一致するおそれがあります。完全一致またはサフィックスで表現できる場合は、対象を明確にできるルールを優先してください。

ドメインルールではWebページのパスを判定できない

https://example.com/video を DOMAIN に指定しないでください。マッチ対象は完全なURLではなくホスト名です。同じドメイン内の /video と /docs を、前述のドメインルールで区別することはできません。HTTPSでは、暗号化されたWebページのパスをこれらのルールだけで読み取ることもできません。

IP-CIDRとGEOIP：アドレス範囲、データベース、no-resolve

IP-CIDR は接続先のIPv4ネットワークにマッチし、IPv6には IP-CIDR6 を使います。スラッシュの後の数字はプレフィックス長であり、ポート番号ではありません。単一のIPv4アドレスは /32、単一のIPv6アドレスは /128 として指定できます。

rules:
  - 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
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

最初の3行は一般的なIPv4プライベートアドレス範囲、4行目はIPv6のユニークローカルアドレス範囲を対象にします。これはカーネル内で通信を振り分けるルールであり、すべてのLAN接続がカーネルを経由するという意味ではありません。システムプロキシのバイパスリストやTUNのルート除外設定によって、該当する接続がクライアントを迂回することがあります。

GEOIPはWebサイトの国籍を判定する機能ではない

GEOIP,CN,DIRECT は、カーネルが使用するIP位置情報データに基づいて接続先のアドレスを判定します。ドメインのサフィックス、企業の登記国、ユーザーアカウントの地域を調べるものではありません。CDNのアドレス変更、DNSの応答差、位置情報データベースのバージョン差によって、マッチ結果が変わることがあります。特定のサービスの処理を固定したい場合は、GEOIPより前に対象を明示したドメインルールを配置してください。

no-resolveが制限するのは現在のルールでの名前解決

接続にドメイン名しかなく、実際の接続先IPがまだ得られていない場合、IPルールの判定時にDNS解決が行われることがあります。no-resolve を付けると、そのルールのマッチ判定を目的としたドメイン名の解決は行われません。接続に利用可能なIPアドレスがすでにある場合は、引き続きアドレスで判定できます。

  • プライベートネットワークのルールに no-resolve を付けると、プライベートアドレスの判定だけを目的とした名前解決を抑えられます。
  • GEOIP にこのパラメーターを付けると、ドメイン名しかなく利用可能なIPがない接続はこのルールをスキップし、後続のルールに進むことがあります。
  • 前のルールですでに名前解決が行われている場合、後続ルールの no-resolve によって取得済みの結果が取り消されることはありません。

ルールの評価順：上から順に確認し、最初の一致で終了

ルールリストには「具体的なルールを優先」する自動ソート機能はなく、ルールタイプに応じてDOMAINがGEOIPより前に移動することもありません。通常は上から順にルールを確認し、一致しなければ次へ進みます。一致した時点で接続が該当ポリシーに渡され、それ以上適切なルールを探すことはありません。

  1. 最初に明確な例外を置きます。たとえば、特定のAPIはプロキシ経由にする、テスト用ドメインは拒否する、といったルールです。
  2. 次にドメインルールとサービス別ルールセットを置きます。IPの地域判定より先に、個別サービスの方針を指定します。
  3. その後にプライベートネットワークと地域別IPのルールを置きます。どちらを先にするかは、ドメインルールでアドレスルールを上書きできるようにするかによって決まります。
  4. 最後にMATCHを置きます。それまでのルールに一致しなかった接続の出力先を指定します。

この順序は一般的な構成例であり、カーネルの必須要件ではありません。「プライベートネットワーク宛ての通信はすべて直接接続する」方針なら、それを上書きする可能性のあるサービス別ルールより前に、プライベートネットワークのルールを配置します。順序が適切か判断するには、どのポリシーを優先するのかを先に明確にしてください。

rules:
  - DOMAIN,blocked.example.com,REJECT
  - DOMAIN,api.example.com,ノード選択
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

このリストでは、blocked.example.com は拒否され、api.example.com はノード選択に渡され、www.example.com は直接接続されます。APIの解決先が後続のGEOIP条件に一致しても、先にドメインルールが一致しているため、そのルールは評価されません。

MATCHより後ろの通常ルールは実行されない

MATCH,ノード選択 にはマッチ対象のフィールドがなく、この行に到達したすべての接続に適用されます。リストの途中に置くと、後続の通常ルールが機能しなくなります。MATCH,*,ノード選択 のようにも書かないでください。出力先は2番目のフィールドで指定します。

ルールに一致した接続でエラーが発生しても、通常カーネルが次のルールに戻って試すことはありません。ノード障害時の切り替えが必要な場合は、rules に同じドメインを複数回記述して別々の出力先を指定するのではなく、ポリシーグループに適切な選択方法を設定してください。

rule-providers：ルールセットを定義し、RULE-SETで参照する

rule-providers でルールセットの取得元を定義し、RULE-SET でマッチングリストに追加します。定義しただけでは通信の振り分けに使われません。以下では、mihomoのローカルファイル形式のルールセットを例に、クラシック形式でルールを記述します。

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

rules:
  - DOMAIN,api.example.com,ノード選択
  - RULE-SET,office-services,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

以下の内容を、カーネルの作業ディレクトリにある rules/office-services.yaml として保存します。相対パスの基準は、クライアントがカーネルを起動するときに使用する作業ディレクトリです。ダウンロード先とは限りません。また、クライアントからカーネルがアクセスできる場所にファイルを置く必要があります。

payload:
  - DOMAIN-SUFFIX,example.org
  - DOMAIN,intranet.example.com
  - IP-CIDR,10.20.0.0/16

ここでは payload の項目に DIRECT やポリシーグループ名を記述せず、参照側の RULE-SET,office-services,DIRECT で出力先をまとめて指定します。通常の設定にある rules と、ルールセットファイル内の payload は異なるファイル構造のため、相互に置き換えることはできません。

behavior内容の形式使用上の注意
classicalDOMAIN-SUFFIX,example.org など、タイプを指定した項目ドメイン条件とIP条件を組み合わせる場合に適しています
domainドメイン専用のマッチ項目DOMAIN-SUFFIX, で始まるクラシック形式の項目は貼り付けないでください
ipcidr10.20.0.0/16 などのアドレス範囲ドメインや出力先ポリシーを混在させないでください

RULE-SET の優先順位は、rules 内での配置場所によって決まります。MATCH の後ろに置いても実行されず、例外ルールより前に置くと例外に該当する接続を先に処理することがあります。トップレベルの rule-providers を rules より前に書くか後に書くかは、マッチの優先順位に影響しません。

リモートHTTPルールセットを使う場合、interval: 86400 はproviderの更新間隔が86400秒（24時間）であることを示します。サブスクリプション設定の更新間隔や、プロキシノード一覧の更新間隔とは別の設定です。この記事ではローカルファイルを例にするため、HTTPの更新パラメーターは設定しません。

クライアントでの適用：上書き、再読み込み、接続の確認

サブスクリプションのファイルを直接編集しても、次回の更新で元の内容に戻ることがあります。カスタムルールを継続して使う場合は、クライアントの上書き、設定のマージ、スクリプト機能を優先して利用し、最終的に生成された rules の順序を確認してください。クライアントによって配列全体を置き換える場合と、先頭・末尾に追加する場合があります。編集画面の内容だけで最終設定を判断しないでください。

編集内容だけでなく、最終設定を確認する

  1. 現在使用しているクライアントとカーネルのバージョンを記録します。クライアントの「設定」または「バージョン情報」で、mihomoとその他のどのカーネルが動作しているか確認し、新しい構文を古いカーネルに適用しないようにします。
  2. 「設定」画面で使用中のサブスクリプションを選び、その設定の編集または上書き画面を開きます。メニュー名はクライアントのバージョンによって異なります。保存後は設定を再読み込みするか、適用してください。
  3. 最終的に有効な設定にトップレベルの rules: が1つだけあることを確認し、追加した例外ルールがサブスクリプションで生成される MATCH より前にあることを確認します。
  4. モードを「ルール / Rule」に切り替え、「接続 / Connections」で対象の接続詳細を開き、マッチしたルール、ルール内容、ポリシーの経路を確認します。

新しい接続でルールを検証する

既存のTCP接続では、通常、接続確立時の出力先が引き続き使われます。ルールを変更した後は、関連する古い接続を閉じるか、アプリを終了してからリクエストを再実行してください。ブラウザーの接続再利用による誤判定を防げます。以下のコマンドは、最終設定で実際に mixed-port: 7890 が待ち受けており、そのアドレスにローカルからアクセスできる場合に限り使用できます。

curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/

Windowsでは curl.exe を使うと、curlプログラムを明示的に実行できます。ここではHTTPプロキシを指定しているため、ブラウザーがシステムプロキシを参照するかどうかに左右されません。7890はテスト用のポート例であり、すべてのクライアントの標準ポートではありません。実行後、「接続」画面で example.com を探し、マッチしたルールとポリシーの経路を確認してください。ページが開くかどうかだけで振り分けの正否を判断しないでください。

よくあるエラーと対処方法

  • 設定の解析に失敗する：インデントに半角スペースを使っているか、リスト項目に - が付いているか、全角の読点を誤って使っていないか確認します。同じトップレベルキーを重複して追加しないでください。
  • ポリシーが見つからない：ルールの3番目のフィールドと実際のポリシーグループ名を一字ずつ照合します。特にサブスクリプション更新後にグループ名が変わっていないか確認してください。
  • ルールセットの読み込みに失敗する：provider名、ファイルパス、behavior、ファイルの内容を確認し、payload のインデントが正しいことを確認します。
  • MATCHにしか一致しない：接続詳細にドメイン名が表示されているか、接続先が別のホスト名に変わっていないか、ルールが最終設定に反映されているか確認します。
  • 接続画面に記録がない：まず、アプリがプロキシを使用しているか、TUNで通信を取り込んでいるか確認します。まだカーネルに入っていない通信は、ルールの順序を変更しても解決できません。

設定項目を確認する場合はプロトコルリファレンスをご覧ください。ポリシーグループ、システムプロキシ、TUNの違いが不明な場合は、まず用語集をご確認ください。ルールを適切に管理するには、例外を明確にし、出力先を有効に保ち、MATCHを常にフォールバック位置に置くことが重要です。

Clash をダウンロードOSに合ったインストーラーを選択