応用設定 読了時間：約11分

Clashのカスタムルール

Clashのルール構文、上から順に照合する仕組み、RULE-SETやMATCHの使い方、設定ミスの確認方法を解説します。

ルールの優先順位：先に照合し、次に接続先を選ぶ

Clashのルールはドメインの具体性に応じて自動で並び替えられるのではなく、設定された順に上から照合され、最初に一致した時点で処理が止まります。完全一致ドメイン、ドメインサフィックス、ルールセットの間に「具体的なルールが自動的に優先される」という仕組みはありません。例外ルールを先に、汎用ルールを後に置き、MATCHを最後にするのが管理しやすい並べ方です。

また、ルール判定と接続先の選択は別の段階です。ルールによって接続がどのポリシーに渡され、その後ポリシーグループが実際の出口を選びます。「業務用ポリシー」に一致していても、グループでDIRECTが選択されていれば接続は直接通信になります。これはルールが無効なのではなく、ポリシーグループの選択が想定と異なる状態です。

順番を逆にするとどうなるか

rules:
  - DOMAIN-SUFFIX,example.org,業務用ポリシー
  - DOMAIN,login.example.org,DIRECT
  - MATCH,業務用ポリシー

login.example.orgにアクセスすると、最初のサフィックスルールに一致した時点で処理が終わるため、2つ目の完全一致ルールによる直接接続は適用されません。2つのルールを入れ替えると、ログイン用サブドメインが先にDIRECTに一致します。ここでいう「より具体的」は設定を整理する際の並べ替え基準であり、コアが自動的に並べ替えるアルゴリズムではありません。

3つのフィールドから成る構文とドメイン照合の範囲

一般的なルールは種類,照合対象,適用するポリシーの形式です。カンマはルールのフィールドを区切り、行頭のハイフンはYAMLのリスト記法です。混同しないようにしましょう。適用先には組み込みポリシーのDIRECTやREJECTのほか、設定済みのノード名やポリシーグループ名を指定できます。

よく使うルールの書き方と照合範囲
種類例説明
DOMAINDOMAIN,login.example.org,DIRECT指定した完全一致ドメインのみが対象です。サブドメインは含みません。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.org,業務用ポリシールートドメインとそのサブドメインに一致します。notexample.orgには一致しません。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,業務用ポリシードメイン名に含まれる文字列で照合するため、通常はサフィックスルールより広い範囲に一致します。
IP-CIDRIP-CIDR,192.168.0.0/16,DIRECT,no-resolve宛先IPv4アドレスが属するネットワークに一致します。末尾に名前解決の制御オプションを付けられます。
RULE-SETRULE-SET,work-domains,業務用ポリシー定義済みのルールプロバイダーを参照し、その中の条件に一致した項目を指定したポリシーに渡します。
MATCHMATCH,業務用ポリシー照合対象を指定せず、前のルールに一致しなかった通信を受け止めるフォールバックです。

ドメインルールにURLをそのまま指定しない

DOMAIN-SUFFIXの後にはexample.orgを指定し、https://example.org/pathのようなURLは使いません。スキーム、ポート、パス、クエリパラメーターはドメインの一部ではありません。また、通常のドメインルールでは、同じサイトの/videoだけをプロキシ経由にし、/accountを直接接続にすることもできません。HTTPS通信の一般的な振り分けは、完全なURLパスを基準にしていません。

サフィックス照合ではドメインのラベル境界が考慮されます。example.orgとapi.example.orgは上記のサフィックスルールに一致しますが、example.org.other.netは一致しません。関連ドメインをまとめて同じポリシーに振り分ける場合は、広すぎるキーワードで似た名前のサイトまで巻き込まないよう、サフィックスルールを優先しましょう。

RULE-SET：参照する位置が優先順位を決める

rule-providersでルールの取得元を定義し、rules内のRULE-SETで照合処理に組み込みます。ルールファイルをダウンロードしただけで、メインのルール一覧から参照していなければ、通信の振り分けには使われません。逆に、定義されていないプロバイダー名を参照すると、設定の読み込みやルールの初期化でエラーになります。

mihomoのローカルdomainルールセット例

以下はファイル型ルールプロバイダーの例です。パスはコアの作業ディレクトリを基準に解決され、エディターで開いている設定ファイルの場所を基準にするとは限りません。デスクトップクライアントでは、実際の作業ディレクトリを先に確認してください。例の「業務用ポリシー」は、現在の設定のproxy-groupsまたはノード一覧に定義されている必要があります。

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

rules:
  - DOMAIN,login.example.org,DIRECT
  - RULE-SET,work-domains,業務用ポリシー
  - MATCH,業務用ポリシー

対応するファイルrules/work-domains.yamlの内容は次のとおりです。

payload:
  - '+.example.org'
  - 'api.example.net'

このdomain形式のルールセットでは、+.example.orgはルートドメインとそのサブドメインに一致し、api.example.netは完全一致のドメインを表します。最初に記載したログインドメインの例外は、RULE-SETより前にあるため引き続き優先されます。ルールファイル内の2項目を入れ替えても、この外側にある直接接続ルールの優先順位は変わりません。

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

  • behavior: domain：ドメイン照合用の項目を記述します。DOMAIN-SUFFIX,example.org,業務用ポリシーのような3フィールドのルール行を、そのまま入れることはできません。
  • behavior: ipcidr：192.168.0.0/16のようなIPネットワークを記述します。ドメイン一覧ではありません。
  • behavior: classical：DOMAIN-SUFFIX,example.orgなどのルール式を記述できます。適用するポリシーは外側のRULE-SETで指定するため、各payloadに重ねて追加する必要はありません。

リモートプロバイダーでは、ダウンロードURL、更新設定、書き込み可能なローカル保存先も正しく設定する必要があります。更新に成功しても、取得した内容の形式がbehaviorに合っているとは限りません。確認時は「最終更新時刻」が変わったかだけでなく、プロバイダーの読み込みログとルールの照合記録も確認してください。

ルールの並べ方：例外、汎用ルール、フォールバック

以下はメインルール一覧の例であり、サブスクリプション設定全体ではありません。前述のwork-domainsプロバイダーと「業務用ポリシー」がすでに定義されている前提です。既存の設定に反映する場合は、既存のrulesリストを編集してください。ファイル末尾に同じ名前のトップレベルキーをもう1つ作らないようにします。

mode: rule

rules:
  - DOMAIN,login.example.org,DIRECT
  - DOMAIN-SUFFIX,example.net,業務用ポリシー
  - RULE-SET,work-domains,業務用ポリシー
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,業務用ポリシー

この例では、プライベートIPのルールより前にドメインのポリシーを置いています。認識済みの業務用ドメインを業務用ポリシーで優先的に処理する意図です。「すべてのプライベートアドレスを先に直接接続する」場合は、プライベートIPルールを前に移動します。ただし、その時点で宛先IPが判明しているか、名前解決が発生するかも考慮してください。ルールの順序は実際の方針を反映するもので、あらゆるネットワークに適した固定の一覧はありません。

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

IP-CIDRの末尾に付けるno-resolveは、このIPルールとの照合だけを目的とした名前解決を自動で開始しない指定です。接続に宛先IPがすでにある場合はネットワーク範囲を判定できますが、ドメイン名しかなく利用できる宛先IPもない場合、このルールは照合のために追加の名前解決を行いません。ブラウザーの名前解決を禁止したり、mihomoのDNS機能を無効にしたりするものではありません。

前述のIPv4プライベートネットワークの例だけで、すべてのLAN通信をカバーできるわけではありません。IPv6の宛先にはIP-CIDR6を検討し、ローカルネットワーク内の単一ラベルのホスト名にはローカルDNSも考慮する必要があります。TUNの除外ルートは通信を取り込む層の設定です。いくつかのDIRECTルールだけで、すべてのローカル通信が仮想ネットワークインターフェースを経由しないと判断することはできません。

MATCHを先頭に置くと後続ルールは照合されない

MATCHには条件がないため、ルール一覧の先頭に置くと、そこに到達したすべての接続を処理します。後続のルールは、構文が正しくても照合されません。通常は末尾にフォールバックを1つだけ置き、どのポリシーに渡すかを明示します。フォールバックがない場合の暗黙の動作を頼りに、設定が想定どおりか判断しないでください。

カスタムルールが効かないときの確認手順

  1. 通信がコアに届いているか確認します。システムプロキシ、アプリ内プロキシ、またはTUNで取り込まれた接続だけがルール照合の対象になります。システムプロキシの対象になっていないアプリは、ドメインルールを追加しただけでは自動的にClashを経由しません。
  2. 現在使っている設定を確認します。クライアントの「サブスクリプション」または「設定」画面で選択中の項目を確認し、動作モードがRuleモードであることも確かめます。メニュー名はクライアントによって異なるため、特定の製品の設定手順をすべての製品に当てはめないでください。
  3. 実際に読み込まれたルールの順序を確認します。サブスクリプションのマージ、オーバーライド、スクリプトによって、カスタムルールがMATCHの後ろに追加される場合があります。編集画面での位置と、実際に動作している設定での位置が同じとは限りません。
  4. 名前とインデントを確認します。業務用ポリシーと業務用プロキシは別の名前です。プロバイダーのキー名も定義と完全に一致させてください。YAMLのインデントにはスペースを使い、タブを混在させないでください。
  5. 新しい接続を作ってから確認します。既存のHTTP/2、HTTP/3、WebSocket接続は、以前の出口を引き続き再利用することがあります。設定を反映したら、対象の接続を閉じるかアプリを再起動してからテストしてください。
  6. 一致したルールと実際の出口を照合します。接続の詳細で、宛先ホスト、ルールの種類と内容、ポリシーの経路を確認してください。出口ノードが変わっただけでは、想定したルールに一致した証拠にはなりません。

まずプロキシポート経由のテストを行う

現在の設定でmixed-port: 7890が指定されている場合は、次のコマンドでHTTPプロキシの入口を経由したリクエストを送信できます。7890はここでの例であり、すべてのクライアント共通の固定値ではありません。実際の設定を確認してください。-qはユーザーのcurl設定ファイルを読み込まず、--noproxy ""は環境変数などに設定されたバイパスリストの影響を避けるためのオプションです。

curl -q --noproxy "" --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  --head https://example.org/

このコマンドは問題の切り分けに使うテスト接続を作るもので、性能測定の結果ではありません。リクエストに失敗した場合は、プロキシポートへの接続拒否、DNSエラー、出口への接続失敗、リモートサーバーからのHTTP応答を区別してください。タイムアウトだけを根拠にルール構文の誤りと判断することはできません。ページの応答ステータスも、ルールの照合記録の代わりにはなりません。

curlでは正しく動作するのに、ブラウザーから同じドメインへアクセスしても接続が表示されない場合は、ブラウザーがプロキシを使っているか、古い接続を再利用していないか、関連する通信を別の拡張機能が処理していないかを確認します。DNSキャッシュは接続先IPに影響することがありますが、「キャッシュを消す」だけで通信の取り込み方法や動作中の設定の確認を済ませないでください。

サブスクリプションの更新とルールの管理

サブスクリプションが生成した設定を直接編集すると、次回の更新でリモート側の内容に上書きされる場合があります。少数の例外ルールをローカルに保つには、クライアントが対応しているオーバーライド、マージ、スクリプトの仕組みを使う方法が適しています。具体的な方法はクライアントによって異なりますが、確認すべき点は2つです。カスタムルールが残っていること、そして汎用ルールとMATCHより前に置かれていることです。

変更ごとに対象を1つずつ確認

  • まず完全一致ドメインを追加します。1つのDOMAINルールで、ルールの入口とポリシー名が正しく機能することを確認してから、必要に応じてサフィックスルールに広げます。
  • 次にルールセットへ移します。単独のルールで動作を確認してから、behaviorに合った形式のファイルに移します。構文の問題とルールの取得元の問題を切り分けやすくなります。
  • 最後に例外を整理します。ログインや社内ネットワークなどの例外は、それらに一致する汎用ルールより前に置きます。重複ルールを追加し続けて、順序の整理を先送りしないでください。
  • 更新後にもう一度確認します。最終的なルール一覧を開き、例外ドメインと通常ドメインでそれぞれ新しい接続を作成し、照合されたルールと出口を確認します。

Clashのカスタムルールは、数を増やすことよりも、照合範囲、一覧の順序、出口の意味を一致させることが重要です。まず通信がコアに届いているかを確認し、次に最終的なルールの位置、最後にポリシーグループの選択を見れば、ノードを何度も切り替えるより問題を特定しやすくなります。クライアントごとの通信の取り込みや設定の読み込み方法はクライアントの使い方ガイド、ルールの種類やコアの機能はプロトコルガイドをご覧ください。

Clashをダウンロードプラットフォームに合ったクライアントを選択