Clashのカスタムルール設定｜ルールの種類・マッチ順序・MATCHのフォールバック
DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIPなどの基本構文と、上から順に最初に一致したルールが適用される仕組みを解説。ルールを上書きする際の並べ方も紹介します。
1. ルールの基本構文：マッチ条件と接続先
Clashのカスタムルールは、「この接続をどの接続先に振り分けるか」を決めるものです。ルールの編集画面はクライアントが提供し、実際のマッチ処理はコアが行います。オリジナルのClashとClash Meta（現mihomo）では、利用できるルール機能が完全には一致しません。この記事では両者に共通する基本構文を説明し、ルールセットについては互換性の条件を別途解説します。
一般的なルールは、YAMLのトップレベルにあるrules:リストに記述します。各行は通常「ルールタイプ、マッチ対象、ポリシー」で構成され、タイプによっては追加パラメーターを指定できます。MATCHにはマッチ対象がないため、接続先のポリシーだけを指定します。
rules:
- DOMAIN,example.com,DIRECT
- DOMAIN-SUFFIX,example.org,REJECT
- IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
- MATCH,DIRECTこれはルール設定の一部であり、サブスクリプション設定全体ではありません。DIRECTは直接接続、REJECTは接続拒否を表します。ポリシーに代理出口と指定する場合、現在の設定に同じ名前のプロキシノードまたはポリシーグループが必要です。名前は完全一致で参照され、中国語の意味から接続先が自動作成されることはありません。
2. DOMAINとDOMAIN-SUFFIX：完全一致とドメインの末尾一致
| タイプ | 例 | マッチ範囲 |
|---|---|---|
| DOMAIN | DOMAIN,api.example.com,DIRECT | api.example.comだけに一致し、そのサブドメインには一致しません。 |
| DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,DIRECT | example.comとapi.example.comなど、そのサブドメインに一致します。 |
| DOMAIN-KEYWORD | DOMAIN-KEYWORD,example,REJECT | ドメイン名にexampleを含む接続に一致します。末尾一致ルールより範囲が広くなります。 |
ドメインルールにURLのパスは指定しない
https://api.example.com/v1/statusを処理する場合、指定するのはapi.example.comです。https://や/v1/status、ポート番号は含めません。通常のドメインルールではHTTPSのページパスごとに振り分けられません。同じドメイン内の異なるパスが別の接続先になることもありません。
- 特定のAPIだけに例外を設定するなら、
DOMAINを使います。 - メインドメインとすべてのサブドメインに同じポリシーを適用するなら、
DOMAIN-SUFFIXを使います。 - キーワードルールは関係のないドメインにも一致しやすいため、接続ログで対象範囲を確認してから継続利用してください。
ドメインルールが機能するかどうかは、コアが接続先のドメインを取得できるかにも左右されます。アプリがIPアドレスへ直接接続する場合や、DNS問い合わせが想定どおりコアを経由しない場合、接続メタデータにドメインが含まれない場合は、DOMAINルールが必ず適用されるとは限りません。mihomoのドメインスニッフィングで情報を補えるケースもありますが、すべてのプロトコルに有効な万能策ではありません。
3. ルールの順序：上から確認し、最初の一致で確定
Clashは一致するルールをすべて集めてから、「最も具体的に見える」ルールを選ぶわけではありません。通常のルールリストは上から順に確認され、条件に最初に一致したルールで接続先が決まり、その接続の判定に後続ルールは使われません。そのため、特定の例外は上に、広い範囲を分類するルールは下に配置するのが基本です。
rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,REJECT
- MATCH,DIRECTこの例では、api.example.comへの接続は直接接続され、www.example.comへの接続は拒否されます。最初の2行を入れ替えると、api.example.comは先にドメイン末尾ルールに一致し、その後の完全一致による直接接続ルールは適用されません。DOMAINの優先度が下がったのではなく、すでにマッチ処理が終わっているためです。
管理しやすいルールの並べ方
- 明確な個別サイトの例外：個別に許可・拒否するドメインや、接続先を固定するドメイン。
- LANと内部サービス：ローカルネットワークに属することを確認したアドレス範囲や内部ドメイン。
- 用途別の分類とルールセット：用途ごとに整理した広範囲の振り分けルール。
- 地域などの広範な判定：地理データベースに基づくIPルールなど。
- MATCH：それまでのルールに一致しなかった接続を処理します。
これはルール管理の考え方であり、そのまま使う必要のある固定テンプレートではありません。セキュリティ要件で特定の接続を優先的に拒否する必要があるなら、該当する許可ルールより拒否ルールを上に置き、競合がないか確認してください。重要なのは、上にある各ルールが下のルールより優先されても問題ないことです。
4. IP-CIDRとGEOIP：接続先IP・名前解決・no-resolve
IP-CIDRは接続先のIPv4アドレス範囲にマッチし、IPv6にはIP-CIDR6を使います。たとえば192.168.50.0/24はそのネットワーク内のアドレスに一致するため、自宅のNASやプリンター、内部サービスを直接接続する設定に使えます。「接続元の端末」のアドレスを絞り込む条件ではありません。
rules:
- IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
- IP-CIDR6,fd00::/8,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,DIRECTGEOIP,CN,DIRECTは、現在のIP地理情報データベースに基づいて接続先IPがCNに分類されるかを判定します。「中国のWebサイト」の完全な一覧を表すものではありません。Webサイトが複数地域のCDNを利用していることもあり、同じドメインでも異なるIPアドレスに解決される場合があります。データベースの内容や更新時期、DNSの結果によって判定は変わるため、実際に解決された接続先IPとデータベースの分類で、一致するGEOIPルールを確認してください。
no-resolveが適用される範囲
接続にドメイン名だけが含まれ、利用可能な接続先IPがない場合、IP系ルールの判定でDNS名前解決が行われることがあります。no-resolveを付けると、そのルールに一致させるためにドメイン名を積極的に解決しません。接続メタデータに利用可能なIPがすでに含まれていれば、引き続きIPアドレスで判定できます。DNSを無効にする設定でも、すべてのドメイン接続でIP判定を回避する設定でもありません。
- LAN内のIPを直接接続するルールには、内部ネットワークの範囲を確認するために他のドメインを先に名前解決しないよう、
no-resolveを付けることがよくあります。 - まだ名前解決されていないドメインもGEOIPで判定したい場合、機械的に
no-resolveを追加しないでください。 - 接続元端末のアドレスに応じて振り分けたい場合は、IP-CIDRに接続元IPを記述するのではなく、コアが対応する送信元アドレス用ルールを確認してください。
上記のfd00::/8はIPv6のローカルアドレス範囲の一例であり、すべてのローカルネットワークをカバーするものではありません。実際の設定では端末のアドレス設計に合わせてネットワーク範囲を選び、DNSがIPv6アドレスを返した場合も想定どおりのポリシーが適用されるか確認してください。
5. MATCHのフォールバック：最後に適用する接続先
MATCHは無条件で一致します。リストの途中に置くと、通常のマッチ処理ではその後のルールに到達できません。一般的には1つだけ残し、リストの末尾に配置します。MATCHの後ろにカスタムルールを追加すると、「設定は読み込めるのに実際には適用されない」原因になりがちです。
rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,example.org,REJECT
- IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
- MATCH,代理出口この例では、設定内に代理出口という名前のポリシーグループがすでに存在するものとします。最初の3つのルールに一致しない接続はこのグループに渡されますが、最終的な接続先はグループ内で選択されている項目によって決まります。グループでDIRECTが選ばれていれば、接続は直接接続されます。ルールが特定のグループに一致することと、最終的に特定のプロキシノードが使われることは、別の段階の結果です。
6. サブスクリプションの上書き：先頭挿入・末尾追加・全置換
サブスクリプションは定期的に更新されるため、ダウンロードして生成された設定ファイルを直接編集すると、次回の更新で変更が上書きされることがあります。クライアントにローカル上書き、設定のマージ、ルール編集機能がある場合は、そちらを使うほうが安全です。設定画面や項目、マージ方法はクライアントやバージョンによって異なります。特定のクライアントの上書き構文を、Clash共通のYAML構文として扱わないでください。
保存できたか判断する前に、最終的な設定を確認
- 現在動作している設定をバックアップし、既存のポリシーグループ名と最後のフォールバックルールを記録します。
- 現在のサブスクリプションに関連付けられたローカル上書き設定で、カスタムルールを先頭に挿入する方法を選びます。末尾追加しかできない場合は、MATCHの後ろに挿入されないことを確認してください。
- マージ後の有効な設定を表示し、テスト用ドメインを検索します。
rules内に実際に追加され、広範囲のルールより前に配置されていることを確認してください。 - 設定を再読み込みしてから新しい接続を作り、一致したルールを確認します。エディター上の元の設定断片だけを見て判断しないでください。
「rulesを置き換える」と元のルールリストが削除され、サブスクリプションに含まれるルールセット参照やLANの例外、フォールバックポリシーまで失われることがあります。ドメインを1つだけ変更するなら、サブスクリプション全体を複製して管理するより、完全一致ルールを1つ先頭に追加する方法を優先してください。
RULE-SETも配置順が重要
rule-providersに対応するコアでは、RULE-SETを使ってルールセットを参照できます。対応範囲はコアとバージョンごとに確認が必要で、すべてのオリジナルClashビルドが対応しているわけではありません。以下の例では、work-domainsというproviderと、代理出口というポリシーグループがすでに定義されているものとします。
rules:
- DOMAIN,status.example.com,DIRECT
- RULE-SET,work-domains,代理出口
- MATCH,DIRECTルールセットにstatus.example.comが含まれていても、その前にあるDOMAINの例外が先に適用されます。ルールセットにrulesリスト内で特別な優先順位が与えられるわけではありません。また、providerのbehaviorとファイルの内容形式も確認してください。domain、ipcidr、classicalのデータ形式は自由に混在させられません。
7. カスタムルールが効かないとき：接続ログで順に確認
ルールの検証では、一度に変更する項目を1つにしてください。まずテスト用ドメインに一時的なREJECTルールを追加し、リストの先頭に配置して再読み込みした後、新しいリクエストを送信します。接続ログでそのルールに一致したことを確認してから、必要な接続先に戻します。テスト後は、一時的な拒否ルールを削除して以降の利用に影響しないようにしてください。
| 症状 | まず確認する項目 | 次の手順 |
|---|---|---|
| 新しいルールがまったく見つからない | 現在有効なサブスクリプション、上書き設定の関連付け、有効な設定 | 編集中の設定が、コアによって読み込まれている設定と同じか確認します。 |
| 別のルールに一致する | リストの前方にあるDOMAIN-SUFFIX、RULE-SET、MATCH | 対象の広範囲ルールより前に、完全一致の例外を移動します。 |
| ポリシーグループには一致するが、接続先が違う | グループで現在選択されている項目と、入れ子になったポリシーグループ | ポリシーの経路をたどり、最終的なノードまたはDIRECTを確認します。 |
| 一部のリクエストだけ想定どおりになる | リダイレクト先ドメイン、リソース用ドメイン、IPv6、既存の接続 | ブラウザーのアドレスバーだけでなく、新しい接続を1つずつ確認します。 |
| 再読み込み時にエラーが出る | YAMLのインデント、ルールの記述、ポリシー名とprovider名 | まず設定の検証を通し、その後で再読み込みします。 |
コアで設定構文を検証する
mihomoをコマンドラインから直接使う場合は、設定ファイルのあるディレクトリで次の検証を実行できます。実行ファイルがコマンド検索パスにあり、設定から参照するリソースを正しく見つけられることを確認してください。
mihomo -t -f config.yaml検証に通れば、そのコアで設定を読み込めることは確認できますが、振り分けが期待どおりであることまでは分かりません。クライアントの接続履歴やログを開き、接続先ドメイン、接続先IP、一致したルール、ポリシーの経路を確認してください。GUIクライアントを使う場合は、手元のバックアップファイルだけでなく、実際に読み込まれている生成済み設定も確認します。
ルールを変更しても、確立済みの長時間接続がすぐに新しい接続先へ移るとは限りません。ブラウザーのHTTP/2接続やダウンロード、インスタントメッセージの接続では、以前の経路が再利用されることがあります。保存して設定を再読み込みした後、新しい接続を作ってテストしてください。必要に応じて古い接続を閉じてから再試行し、接続の再利用をルールの不具合と誤認しないようにします。
ルールを管理するときは、用途が明確な例外だけを残し、なぜその位置に置くのか記録しておきましょう。問題が起きたら、「トラフィックがコアに届いているか」「ルールモードか」「有効なリストの順序」「一致したポリシー」「最終的な接続先」の順に確認すると、プロキシノードを何度も切り替えるより原因を見つけやすくなります。