Clashのカスタムルール設定方法｜ルールの種類・上から順の判定・MATCHのフォールバック | Clashチュートリアル

ルール適用の前提：ルールモード・通信の取り込み・設定の保存

Clashのカスタムルールは、コアに取り込まれた通信の出口を振り分けるためのものです。ルールが正しくても、すべてのアプリの通信が対象になるとは限りません。システムプロキシの影響を受けるのは、通常、プロキシ設定に従うアプリだけです。TUNはより多くの通信を取り込めますが、ルーティング、権限、除外設定の影響を受けます。問題を調べる際は、まずクライアントの「接続」画面に対象の通信が表示されるか確認し、その後で適用されたルールを確認してください。

この記事では、Clashで一般的なルール構文を扱います。プロセスの識別については、Clash Meta（mihomo）を主な参考としています。コアやOSによって対応範囲は異なるため、クライアントの編集画面にある機能が、そのままコアの対応機能を示すとは限りません。実際に動作しているコアをクライアントのコア情報または起動ログで確認してから、対応する機能を使ってください。

動作モードを「ルール」に切り替え、設定ファイルで mode: rule にします。グローバルモードでは、ここで説明する通常の振り分けルールによって出口が選ばれません。
編集中の設定が現在有効になっているか確認してください。同じ名前の別のサブスクリプションが有効になっている場合があります。
元の設定をバックアップし、クライアントの設定検証機能でYAMLを確認してから再読み込みします。
対象アプリの既存の接続を閉じて、新しくリクエストを送信してください。確立済みの接続は、ルールを更新しても通常、自動的に出口が切り替わりません。

ルールの基本構文：タイプ・マッチ対象・ポリシー名

多くのルールは タイプ,マッチ対象,ポリシー の形式で記述します。ポリシーには DIRECT や REJECT などの組み込みポリシーのほか、設定済みのプロキシノード名やプロキシグループ名を指定できます。MATCH にはマッチ対象が不要で、MATCH,ポリシー と記述します。フィールドの区切りには半角カンマを使い、各ルールはYAMLリストの1項目として記述します。

ルールタイプ	例	マッチ範囲
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	このドメインに完全一致
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	ルートドメインとそのサブドメイン
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,REJECT`	ドメインに指定した文字列を含む
`IP-CIDR`	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	宛先IPv4アドレスがこのCIDR範囲に含まれる
`IP-CIDR6`	`IP-CIDR6,fc00::/7,DIRECT,no-resolve`	宛先IPv6アドレスがこのCIDR範囲に含まれる
`PROCESS-NAME`	`PROCESS-NAME,curl.exe,DIRECT`	識別されたプロセス名に一致
`MATCH`	`MATCH,DIRECT`	前のルールに一致しなかった通信を受け取る

プロキシグループ名が実際に定義されているか確認する

PROXY は自動で用意される「プロキシの総合スイッチ」ではありません。設定に PROXY という名前のノードやグループがない場合、指定すると読み込み時にプロキシが見つからないエラーが発生することがあります。同様に、ノード選択 と ノード選択 2 は別の名前です。画面上の表示だけで名前を推測しないでください。

以下はルールリストの記述例です。元の設定に「ノード選択」という名前のプロキシグループが定義されていることを前提としています。存在しない場合はそのまま貼り付けるのではなく、実際に設定済みのポリシー名に置き換えてください。

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

ルールのドメインには https://、パス、ポート番号を付けません。https://example.com/docs の /docs のようなパスだけを対象にすることも、DOMAIN ではできません。ここで行うのは接続レベルの振り分けであり、HTTPパスのルーティングではありません。

上から順に判定：具体的な例外を前に、広いルールを後ろに

通常のルールはリストの順に評価され、最初に一致したルールでポリシーが決まります。その後にある「より具体的な」ルールまで判定されることはありません。システムが DOMAIN を DOMAIN-SUFFIX より前に自動で並べ替えたり、CIDRの範囲に応じて順序を調整したりすることもありません。つまり、ルールの順番そのものが設定のロジックの一部です。

rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,REJECT"
  - "MATCH,DIRECT"

api.example.com：最初のルールに一致して DIRECT になります。2つ目のルールでは拒否されません。
www.example.com：最初のルールには一致せず、2つ目に一致して REJECT になります。
example.com：2つ目のルールにも一致します。サフィックスルールはルートドメイン自体も対象にします。
notexample.com：example.com のドメイン階層には含まれないため、最終的に3つ目のルールが適用されます。

最初の2つのルールを入れ替えると、api.example.com も拒否されます。この問題を直すために同じルールを増やす必要はありません。例外ルールを広い範囲のルールより前に移動するだけで解決できます。一般的には、明示的な例外、必要に応じたLANの直接接続、カテゴリ別ルールセット、地域別IPルールの順に並べ、最後にフォールバックを置きます。ただし、これは必須の順序ではありません。例外ルールとLANポリシーのどちらを優先するかは、実際の用途に合わせて決めてください。

キーワードルールは意図しない範囲まで一致しやすい

DOMAIN-KEYWORD,example はドメイン階層ではなく、ドメイン名に含まれる文字列を照合するため、notexample.com にも一致することがあります。特定のサイトとそのサブドメインを振り分ける場合は、まず DOMAIN-SUFFIX の利用を検討してください。記述を簡単にするために短いキーワードのルールをリストの先頭に置くと、無関係なサービスまで巻き込むおそれがあります。

IP-CIDRとno-resolve：能動的な名前解決を抑える設定であり、DNSを無効にするものではない

IP-CIDR は、宛先アドレスが指定したCIDR範囲に含まれるかを判定します。リクエストにドメイン名が含まれる場合、IPルールを判定するために、コアが先に宛先IPを取得することがあります。ルールに no-resolve を付けると、このルールを評価するための能動的な名前解決を行わないよう指定できます。「IPマッチをスキップする」という意味でも、「この接続ではDNSを一切使わない」という意味でもありません。

rules:
  - "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"
  - "IP-CIDR6,fc00::/7,DIRECT,no-resolve"
  - "MATCH,DIRECT"

上記はよく使われるIPv4プライベートアドレスの範囲3つと、IPv6のユニークローカルアドレスの範囲を示したLANルールの例です。特殊用途アドレスの完全な一覧ではありません。192.168.1.1 への接続のように、宛先IPがすでに明確な場合は、no-resolve を付けたルールでもマッチします。

ドメイン名でのアクセスとIPアドレスでのアクセスは分けて検証する

192.168.1.1 に直接接続できても、そのアドレスに解決されるドメイン名へのアクセスが同じルールに一致するとは限りません。コアが実際の宛先アドレスをまだ把握していない場合、no-resolve の設定によって、IPルールのために能動的な名前解決を行うかどうかが変わります。利用可能な宛先IP、DNSキャッシュ、Fake-IPのマッピングなども判定に影響するため、接続の詳細を確認してください。

PROCESS-NAME：プロセスルールの権限とプラットフォーム上の制約

プロセスルールは、「特定のプログラムを常に同じ出口に接続する」用途に適しています。たとえばWindowsでは、PROCESS-NAME,curl.exe,DIRECT により、コアが curl.exe と識別した通信を対象にできます。デスクトップのショートカット名やウィンドウタイトルではなく、接続の詳細に表示される実際のプロセス名を使ってください。

システムの対応状況を確認：プロセスの検出は、コア、OS、実行権限に依存します。mihomoの find-process-mode はプロセスの検索動作に影響します。off に設定されている場合、プロセスルールで正常に識別できるとは限りません。
通信元を確認：ルーター経由で転送された別の端末の通信では、通常、ルーターからその端末上のアプリのプロセス名を取得できません。この場合はプロセス名を無理に使わず、送信元アドレスによるルールを検討してください。
ルールの順序を確認：プロセスルールを通常のWebサイト振り分けより優先する場合は、該当するドメインルールより前に置きます。補助的に使う場合は、該当ルールの後、MATCH の前に置いてください。
関連プロセスを確認：1つのアプリが複数のプロセスから通信することがあります。ブラウザーのエンジン、アップデーター、本体で同じプロセス名が表示されるとは限りません。実際の接続を個別に確認してください。

Androidクライアントのアプリ別プロキシ設定やアプリ除外リストは、多くの場合、VPNで通信を取り込む範囲の設定です。デスクトップ環境の PROCESS-NAME と同じものではありません。アプリが除外されて通信がコアに届かなければ、通常のルールではマッチしません。

MATCHのフォールバック：最後のルールで未分類の通信先を決める

MATCH はドメインやCIDRの条件を指定せず、そこまでのルールに一致しなかった通信を受け取ります。通常のルールリストの末尾に配置してください。先頭に置くと、後続の通常ルールがマッチする機会を失います。明示的なフォールバックは通常1つで十分です。複数書いてもフェイルオーバーにはなりません。

mode: rule
rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,REJECT"
  - "IP-CIDR,192.168.0.0/16,DIRECT,no-resolve"
  - "MATCH,DIRECT"

以下は組み込みポリシーだけを使った構文例です。指定したドメインを拒否し、それ以外の通信は直接接続します。汎用的なプロキシ設定ではありません。未分類の通信をプロキシ経由にする場合は、最後の行の DIRECT を既存のプロキシグループ名に置き換え、そのグループで目的の出口が選択されていることを確認してください。

フォールバックのポリシーに唯一の正解はありません。デフォルトをプロキシにすると、未分類の海外サービスを経由できますが、国内サービスが遠回りになることがあります。デフォルトを直接接続にすると、意図しないプロキシ利用を減らせますが、対象サービスのルールを追加する必要があります。まずデフォルトの動作を決めてから例外を追加する方が、グローバルモードを何度も切り替えるより問題を特定しやすくなります。

検証とトラブルシューティング：実行中の設定から新しい接続まで確認

ルールの調査では、設定が読み込まれたか、リクエストがコアに届いたか、どのルールに一致したか、最終的にどの出口が使われたかを確認できるようにしましょう。Webページが開くかどうかだけでは、DNS、ルール、ノードのどこに問題があるか判断しにくいものです。

最終設定を確認：想定した rules: がトップレベルに1つだけあること、リストのインデントが揃っていること、Tabを使っていないことを確認してください。追加したルールが実際にどこにあるか、特に MATCH の後ろに追加されていないかを確認します。
読み込みログを確認：ポリシーが存在しないというエラーが出たら、プロキシグループ名を一字ずつ確認してください。ルールタイプが未対応というエラーが出たら、インデントを変えてごまかすのではなく、コアの対応機能を確認します。
新しいリクエストを送信：既存の接続をいったん閉じてから、テスト対象にアクセスします。「接続」画面でドメイン、宛先IP、ルールタイプ、プロキシチェーンを確認してください。接続の詳細に表示される項目名はクライアントによって異なります。
プロキシへの接続経路を切り分ける：明示的なプロキシを使ったリクエストで、アプリがシステムプロキシに従っていない可能性を切り分けられます。使用するポートが現在のコアのものかどうかも確認してください。

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

ここでは、ローカルのHTTPまたは混合プロキシのポートを 7890 としています。実際の mixed-port が 7897 の場合は、コマンドも同じ値に変更してください。このテストで確認できるのは明示的なHTTPプロキシ経由の通信であり、TUNが正常に通信を取り込めているかは単独では確認できません。前述の拒否ルールの例では、対象ドメインにアクセスできないのが想定どおりの動作です。一致したルールもあわせて確認してください。

よくある3つの症状と確認手順

ルールを保存しても反映されない：まず現在の設定と最終的なルールリストを確認し、次に動作モードを確認します。最後に既存の接続を閉じて再試行してください。すぐに同じルールを追加しないでください。
ドメインルールにまったく一致しない：コアがドメイン情報を取得できているか確認してください。宛先IPしかなく、有効なドメインのマッピングやスニッフィング結果もない場合、ドメインルールがサイトを自動で識別することはできません。
プロキシグループに一致するが出口が違う：グループ内で現在選択されているノードとプロキシチェーンを確認してください。ルールは使用するポリシーを決め、その後にプロキシグループが具体的なノードを決めます。両方を確認しましょう。

安定して設定を変更するには、一度に変更するルールの種類を1つに絞り、読み込みを確認してから新しい接続で再テストします。具体的なルールを前に、範囲の広いルールを後ろに置き、最後を MATCH で締めくくりましょう。変更を保持できるオーバーライド機能も活用すれば、サブスクリプションの更新で直したルートが元に戻るのを防げます。