Clash カスタムルールの文法とマッチング優先順位を徹底解説

ルール(rules)は Clash 設定ファイルで「この接続をどのプロキシに流すか」を決める核心部分です。初めて自分で設定ファイルを編集する人の多くは、ルールを何となく積み重ねてしまい、あるルールを正しく書いたつもりでも一度も効いていないという事態に陥ります。原因はほぼ常にマッチング順序にあります。このノートではルールタイプごとに文法を分解し、マッチングエンジンが上から下へヒットしたら停止する仕組みを説明した上で、カスタムルールを書く際にルール同士が互いを上書きしないための実践的な並べ方を紹介します。

ルールの基本構造と実行方式

Clash 設定ファイルの rules はリストで、各行が1つのルールに対応し、書式は常に3セグメント構成です。

RULE-TYPE,VALUE,PROXY

第1セグメントはルールタイプ、第2セグメントはマッチング値(一部のルールタイプにはこのセグメントがありません。例:MATCH)、第3セグメントはヒット時に使うプロキシまたはプロキシグループ名です。このシステムを理解する上で最も重要なのは、Clash が新しい接続を処理する際、ルールリストを上から下へ1行ずつ検査し、あるルールがヒットした時点で即座に対応するプロキシを採用してマッチングを終了するという点です。それより後にヒットする可能性のあるルールがあっても、二度と検査されません。

この「ヒットしたら停止」という原則により、ルールの並び順自体がロジックの一部となります。単なる見た目の整理ではありません。ルールを書くときは、上にあるルールほど優先度が高く、より具体的・例外的な判定ほど前に置き、大まかで受け皿的なルールほど最後に置くという点を常に意識してください。

よく使うルールタイプを1つずつ分解

以下では使用頻度の高い順に、最も一般的なルールタイプの文法とマッチングロジックを説明します。

DOMAIN:完全一致のドメインマッチング

DOMAIN は完全に一致するドメインのみにマッチし、あいまい検索やサブドメインへの拡張は行いません。

DOMAIN,ads.example.com,REJECT
DOMAIN,api.example.com,Proxy

上の1行目は ads.example.com という正確なアドレスだけをブロックします。cdn.ads.example.com や example.com はこのルールにヒットしません。特定のAPIアドレスを精確に遮断・許可したい場合に向いています。

DOMAIN-SUFFIX:ドメインサフィックスマッチング

DOMAIN-SUFFIX は指定した末尾文字列とそのすべてのサブドメインにマッチし、日常的に振り分けルールを書く際に最も多く使われるタイプです。

DOMAIN-SUFFIX,youtube.com,Proxy
DOMAIN-SUFFIX,cn,DIRECT

1行目は youtube.com、www.youtube.com、music.youtube.com など、この末尾を持つすべてのドメインにヒットします。2行目は .cn で終わるすべてのドメインを、プロキシを経由せず直接接続します。このタイプはカバー範囲が広く、カスタムルールを書く際にまず思いつくのが通常これです。

DOMAIN-KEYWORD:ドメインキーワードマッチング

DOMAIN-KEYWORD はドメイン文字列に指定したキーワードが含まれていればヒットし、キーワードが現れる位置は問いません。

DOMAIN-KEYWORD,google,Proxy

このルールは www.google.com にヒットするだけでなく、googleapis.com、googlevideo.com など google という文字列を含むあらゆるドメインにヒットします。このタイプはマッチング範囲が最も広いため、書く際には誤爆に注意が必要です。例えば ad というキーワードは、広告とは無関係でも偶然 ad という文字組み合わせを含む正常なサイトを大量に巻き込むことがあります。より完全なキーワードを使うか、DOMAIN-SUFFIX への切り替えを推奨します。

IP-CIDR と IP-CIDR6:IPレンジによるマッチング

IP-CIDR は 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

この2行はLAN内のセグメントを許可する際によく使われ、ルーターやNAS、LAN内デバイスへのアクセスがプロキシを経由しないようにします。末尾の no-resolve パラメータは重要で、このルールに対して逆引きDNS解決を行わず、宛先IPで直接判定するよう Clash に指示します。これによりドメイン系ルールへの余計な解決コストを避けられ、一部のエッジケースでの誤判定も防げます。

注意点として、IP系ルールはデフォルトでは接続先アドレスがIPである場合にのみ有効です。接続がドメイン名で開始され、Clash がまだ宛先IPを解決していない場合、このタイプのルールはドメイン解決の段階ではヒットせず、DNS解決が完了してから初めてマッチング対象になります。これが、ドメイン系ルールをできるだけ前に置くべきとされる理由の1つです。

GEOIP:国・地域別IPデータベースによるマッチング

GEOIP は内蔵または外部から読み込んだIP地理位置データベースに基づき、宛先IPがどの国・地域に属するかを判定します。

GEOIP,CN,DIRECT
GEOIP,JP,Proxy

1行目は中国本土に属すると判定されたすべてのIPを直接接続にし、2行目は日本に属するIPを Proxy という名前のプロキシグループに流します。GEOIP ルールが依存する地理データベースには更新周期があり、ごく一部のエッジなIPレンジで帰属判定が遅れることがあります。明らかな誤判定に遭遇した場合は、具体的な IP-CIDR ルールを併用して個別に修正できます。

GEOSITE:ドメイン分類セットによるマッチング

GEOSITE(mihomo など一部のコアで対応)は事前に分類済みのドメインルールセットを利用し、1行のルールで動画配信サービスやSNSなど特定カテゴリ下の大量のドメインをまとめてカバーできます。数百〜数千行の DOMAIN-SUFFIX を手書きする必要がありません。

GEOSITE,netflix,Proxy
GEOSITE,cn,DIRECT

このタイプのルールを使う前に、クライアントが対応するルールセットファイルをダウンロードし読み込んでいることを確認してください。そうしないと、分類データが見つからずルールが有効になりません。

PROCESS-NAME と MATCH

PROCESS-NAME は接続を発生させたプロセス名でマッチングし、特定のアプリだけに個別のプロキシ戦略を指定したい場合に向いています。デスクトップ環境でよく使われます。MATCH はマッチング値を持たず、「上記のいずれにも当たらない場合の統一処理」を表し、常にルールリストの最終行として使用します。

PROCESS-NAME,Steam.exe,Proxy
MATCH,DIRECT

マッチング優先順位とヒットしたら停止する原則

前述の各種ルールを同じ設定に入れた場合、実際の挙動を決めるのはルールの並び順であり、タイプそのものの「重み」ではありません。Clash はあるルールが DOMAIN だからといって、それより前にある DOMAIN-KEYWORD より自動的に優先されることはありません。順序は完全にリスト上の物理的な位置によって決まります。

よくある落とし穴の例を見てみましょう。

DOMAIN-KEYWORD,youtube,Proxy
DOMAIN-SUFFIX,youtube.com,DIRECT

本来の意図は、YouTube全体はプロキシ経由にしつつ、特定のサブドメイン(例えば直接接続でも使える静的リソース用のドメインなど)は直接接続にしたいというものかもしれません。しかし DOMAIN-KEYWORD のルールが前に置かれているため、ドメインに youtube という文字列が含まれていればまずこのルールにヒットしてプロキシへ流れてしまい、後ろにあるより精確な DOMAIN-SUFFIX ルールは実行される機会を永遠に得られません。例外ルールを有効にするには、より広範なルールより前に配置し直す必要があります。

DOMAIN-SUFFIX,youtube.com,DIRECT
DOMAIN-KEYWORD,youtube,Proxy

調整後は、精確なドメインサフィックスルールが先に検査され、ヒットすれば直接接続してマッチングを終了します。この精確なルールに当たらない、残りの youtube というキーワードを含むドメインだけが、その後キーワードルールまで進んでプロキシを使うことになります。

カスタムルールを書く際の並べ方のコツ

上記の原則をまとめると、ルール同士の競合によるデバッグコストを大幅に減らせる実践的な並べ方が導けます。

1. LANおよび内部ネットワークアドレスを最前列に:IP-CIDR と no-resolve を組み合わせてプライベートネットワークセグメントを許可し、以降のどのルールも内部ネットワークのトラフィックを誤ってプロキシに送らないようにします。
2. 精確な例外ルールをその直後に:「大分類はプロキシ経由、一部の子項目だけ直接接続」あるいはその逆のシナリオでは、具体的なドメインに対する DOMAIN・DOMAIN-SUFFIX 例外ルールを、対応する大分類ルールより前に置きます。
3. 分類ルールセットを中間に:GEOSITE や一般的な広告・プライバシー遮断用ルールセットは、例外ルールの後・広範なキーワードルールの前に置き、分類ライブラリに大半の通常ドメインを先に処理させます。
4. 広範なキーワードマッチングは後方に:DOMAIN-KEYWORD はヒット範囲が最も広く誤判定しやすいため、より精確なすべてのルールが一通り判定を終えた後に置くべきです。
5. 地域・IP帰属ルールはその次:GEOIP は一般的にドメインルールでカバーできず、かつすでに具体的なIPまで解決された接続を処理するためのもので、通常ドメイン系ルールの後に置きます。
6. MATCH の受け皿ルールは最終行に:前段のいずれのルールにもヒットしなかった接続はすべてこの1行に集約され、ネットワーク方針に応じてデフォルトのプロキシグループあるいは直接接続へ振られます。

この順序で整理した簡略版のサンプルです。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
DOMAIN-SUFFIX,cn-cdn.example.com,DIRECT
GEOSITE,cn,DIRECT
GEOSITE,geolocation-!cn,Proxy
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
MATCH,Proxy

このサンプルのロジックは一貫して読み取れます。まず内部ネットワークを処理し、次に明確に直接接続させたい特定のCDNドメインを処理し、続いて分類ルールセットが中国本土向けと海外向けそれぞれの大多数のドメインを処理します。さらにキーワードルールで散発的な広告ドメインを遮断し、GEOIP が前段のドメインルールで処理されなかったがすでに帰属を判定できるIPを受け止め、最後に MATCH で締めて残りすべての接続をプロキシグループへ送ります。

よくある誤りとトラブルシューティングの考え方

実際にルールを調整する際によく遭遇するケースをまとめておくと、問題を素早く特定できます。

• ルールがまったく効かない:まずその前に、より広範囲をカバーする既にヒットしているルールがないかを確認します。試しにそのルールをリストの最上部に移動してテストし、文法自体に問題がないことを確認した上で並び順の調整を検討してください。
• MATCH より後にまだルールがある:これらのルールは永遠に実行されません。MATCH より前に移動する必要があります。
• IP系ルールがドメイン接続に効かない:クライアントのDNSと解決モードの設定を確認し、マッチングの段階で接続が宛先IPを取得できているかを確認してください。必要であれば対応するドメイン系ルールに置き換えます。
• キーワードルールが無関係なドメインを大量に誤爆する:キーワードをより完全な文字列に変えるか、DOMAIN-SUFFIX に切り替えて末尾を限定し、無関係なヒットを減らします。
• ルールセットの読み込み失敗により分類ルール全体が効かない:対応するルールセットファイルが正しくローカルにダウンロードされ、設定内で正しいパスが指定されているかを確認してください。ネットワークの問題やパスの記述ミスは、この一群のルール全体を無効化します。

ルールを変更したら、まず小さな範囲で新規追加・調整した1行だけをテストし、期待通りの結果になっているか確認してから次のルールを重ねていくことをおすすめします。一度に多くを変更すると原因の切り分けが難しくなります。多くのクライアントは設定を保存すると自動でルールを再読み込みしますが、期待した効果が見られない場合は、手動で設定の再読み込みを実行してキャッシュの問題を排除してみるのも有効です。