ルール設定 読了目安 13分

Clash カスタムルールの書き方：DOMAIN・IP-CIDR・GEOSITEの構文とマッチ順

Clashのルール構文を種類別に解説。ルールは上から順に評価され、最初に一致した時点で停止します。no-resolve、MATCHのフォールバック、ルールセットの順序が振り分けに与える影響も説明します。

まずClashルールの実行方式を理解する

Clash、Clash Meta、そして後継のmihomoコアは、接続情報をルールモジュールに渡して処理します。ルールモジュールは対象ドメイン、対象IP、ポート、ネットワーク種別、プロセスなどを確認し、プロキシグループ、特定ノード、DIRECT、REJECTのいずれを使うか判断します。重要なのはルールの数ではなく、並び順です。

ルールは上から順に1つずつ確認されます。条件に一致するルールが1つ見つかると、その接続について後続のルールは評価されません。そのため、範囲が狭く意図が明確なルールを前に、広いルールを後ろに置き、最後にMATCHで未一致の接続を受けます。

rules:
  - DOMAIN,api.example.com,開発用インターフェース
  - DOMAIN-SUFFIX,example.com,海外サイト
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,デフォルトプロキシ

この設定では、api.example.comへのアクセスは最初のルールに一致し、「開発用インターフェース」ポリシーグループが使われます。DOMAIN-SUFFIX,example.comにも一致しますが、2つ目のルールは評価されません。www.example.comへのアクセスは1つ目を通過し、2つ目で一致します。

1つのルールに含まれる主なフィールド

一般的なルールはカンマ区切りで記述し、基本構造は「ルールタイプ、マッチ対象、ポリシー」です。ルールによっては末尾にno-resolveなどのパラメーターを追加できます。

ルールタイプ,マッチ対象,ポリシー
IP-CIDR,203.0.113.0/24,ノード選択,no-resolve

ポリシー名は大文字・小文字や文字の違いが区別されます。ルール内の名前はproxy-groupsにあるnameと完全に一致させてください。設定で「ノード選択」と定義しているのに、ルールで「ノード選択 」や「プロキシ選択」と記述すると、設定の読み込みに失敗したり、ポリシーが見つからなくなったりします。

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDの使い分け

ドメインルールは、WebサイトやAPIの振り分けに適しています。接続時のホスト名を直接使って判定するため、対象サーバーが現在どのIPに解決されているかに左右されません。CDNを利用しているサービスや、アドレスを頻繁に変更するサービス、複数のネットワークに分散したサービスでは、固定IPよりドメインルールのほうが安定しやすい傾向があります。

DOMAIN：完全一致する1つのドメインだけを指定

rules:
  - DOMAIN,login.example.com,ログインサービス
  - DOMAIN,cdn.example.net,静的リソース

DOMAINは対象ドメイン全体の完全一致を求めます。1つ目のルールはlogin.example.comに一致しますが、www.example.com、api.login.example.com、ルートドメインのexample.comには一致しません。単一のAPI、ログイン用ドメイン、ダウンロード用ドメインなど、対象範囲が明確な場合に適しています。

DOMAIN-SUFFIX：ルートドメインとサブドメインに一致

rules:
  - DOMAIN-SUFFIX,example.com,海外サイト
  - DOMAIN-SUFFIX,example.org,DIRECT

DOMAIN-SUFFIX,example.comはexample.com、www.example.com、a.b.example.comを対象にします。先頭にアスタリスクを付ける必要はなく、*.example.comと記述してはいけません。Webページ、画像、APIが同じメインドメインの異なるサブドメインにある場合は、DOMAIN-SUFFIXを使うと簡潔です。

DOMAIN-KEYWORD：ドメイン内の文字列で一致

rules:
  - DOMAIN-KEYWORD,example,テスト用ポリシー

このルールは、ドメイン内にexampleを含む接続に一致し、文字列がドメイン末尾にある必要はありません。example.comだけでなく、example-cdn.netやnotexample.orgにも一致する可能性があります。対象範囲が広く無関係なドメインまで含みやすいため、完全一致ルールの後ろに置き、できるだけ固有性の高いキーワードを使ってください。

ルール 適した用途 主な適用範囲
DOMAIN 単一のAPI、ログイン用またはダウンロード用ドメイン 他のサブドメインは含まない
DOMAIN-SUFFIX メインドメイン全体とすべてのサブドメイン 同じドメイン内で用途の異なるサービスまで含む可能性がある
DOMAIN-KEYWORD ドメイン構成は変わってもキーワードが安定している場合 誤一致の可能性が高い

IP-CIDR、IP-CIDR6、no-resolveの役割

IP-CIDRはIPv4アドレスまたはネットワークに、IP-CIDR6はIPv6に一致します。CIDRのサフィックスはネットワークプレフィックス長を示します。たとえば/32は単一のIPv4アドレス、/24は通常連続する256個のIPv4アドレスを表し、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,203.0.113.8/32,専用ノード,no-resolve
  - IP-CIDR6,2001:db8::/32,専用ノード,no-resolve

最初の2つはプライベートネットワークへの直接接続に使われることが多いルールです。3つ目は単一のIPv4アドレスにだけ一致します。例に使われている203.0.113.0/24と2001:db8::/32はドキュメント用のアドレスであり、実際のサービスネットワークにそのまま使用しないでください。

no-resolveは「DNSを使わない」という意味ではない

接続にドメイン情報しかない場合、IPルールで判定するには対象IPが必要です。no-resolveを付けないと、コアがルール判定のためにドメイン解決を1回実行することがあります。no-resolveを追加すると、IPルールは判定だけを目的にドメインを能動的にIPへ解決しません。接続自体に対象IPが含まれていれば、通常どおり一致します。

- DOMAIN-SUFFIX,example.com,海外サイト
- IP-CIDR,203.0.113.0/24,専用ノード,no-resolve
- GEOIP,CN,DIRECT,no-resolve
- MATCH,デフォルトプロキシ

この並びでは、まず既存のドメイン情報で判定し、次に既知のIPを確認し、最後にフォールバックします。ルール処理中の追加の名前解決による遅延やDNS依存を減らせます。ただし、no-resolveはClashのDNSモジュールを無効にせず、アプリ自身が行うDNSリクエストも変更しません。

GEOIPと固定ネットワークの違い

GEOIP,CN,DIRECTはGeoIPデータベースを使って、対象IPの所在地域を判定します。広範囲の地域振り分けに適していますが、データベース上の地域分類はサービスの所属先と同じではありません。海外ブランドが中国本土のCDNを使うこともあれば、中国国内のサービスが海外ノードへ接続することもあります。そのため、重要なサービスはDOMAINまたはDOMAIN-SUFFIXを先に記述し、GEOIPは広域の地域判定として後ろに置くのが適切です。

GEOSITE、GEOIP、ルールセットの連携方法

mihomoはGEOSITEルールに対応しています。GEOSITEのデータは、地域、サービス、用途などのカテゴリ別にドメインを整理したものです。大量のDOMAIN-SUFFIXを手作業で記述する負担を減らせますが、利用できるカテゴリは、クライアントに付属またはダウンロードされたgeositeデータファイルに依存します。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,ノード選択

上記の順序では、まず広告カテゴリ、次にプライベートドメインと中国本土のドメイン、続いて取得済みIPのプライベートアドレスと中国本土のアドレスを処理します。一致しなかった接続は「ノード選択」に渡されます。GEOSITE,cn,DIRECTをカスタムプロキシドメインより前に置くと、そのドメインがcnカテゴリに収録されているだけで先に直接接続されます。

RULE-SETでルールセットを実行キューに追加する

rule-providersはルールセットの取得元、形式、更新間隔、ローカル保存先を定義し、RULE-SETはそのルールセットをメインのルールキュー内のどこで実行するかを決めます。providerを宣言しただけでは自動的に実行されないため、rulesで参照する必要があります。

rule-providers:
  direct-sites:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/direct-sites.yaml
    url: https://rules.example.net/direct-sites.yaml
    interval: 86400

  service-rules:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-rules.yaml
    url: https://rules.example.net/service-rules.yaml
    interval: 86400

rules:
  - DOMAIN,api.example.com,専用ノード
  - RULE-SET,service-rules,ノード選択
  - RULE-SET,direct-sites,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,ノード選択

interval: 86400は86400秒、つまり24時間ごとに更新を確認することを示します。behavior: domainの内容はドメイン形式の項目、behavior: ipcidrはネットワーク用、behavior: classicalはタイプ付きのクラシックルールを格納できます。providerの形式は、実際のファイル内容と一致していなければなりません。

payload:
  - example.com
  - api.example.net
  - +.service.example.org

これはdomain形式のルールセットでよく使われるYAML構造です。classical形式を使う場合、項目には通常DOMAIN-SUFFIX,example.comやIP-CIDR,203.0.113.0/24,no-resolveのようにルールタイプを含めます。ポリシーはprovider内の各項目に記述せず、メイン設定のRULE-SET,ルールセット名,ポリシーで一括指定します。

MATCHのフォールバックとよくある順序ミス

MATCHにはマッチ対象がなく、そこまで到達したすべての接続に一致するため、通常はルール一覧の最後に置きます。分類されなかった通信のデフォルトの行き先を決めるルールです。固定ノードよりも手動切り替え可能なプロキシグループを指定すると、ノードが使えない場合にも調整しやすくなります。

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - DIRECT

rules:
  - DOMAIN-SUFFIX,intranet.example,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,ノード選択

ミス1：MATCHを早すぎる位置に置く

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

2つ目のルールが実行される機会は永遠にありません。すべての接続が1つ目のルールで一致するためです。設定自体は読み込めても、振り分け結果は「すべて同じポリシーを通る」状態になります。

ミス2：広いサフィックスが完全一致の例外を上書きする

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,video.example.com,メディアノード

video.example.comは2つのルールに一致しますが、先に1つ目のルールで処理されます。正しくは、完全一致の例外を前に移します。

rules:
  - DOMAIN,video.example.com,メディアノード
  - DOMAIN-SUFFIX,example.com,DIRECT

ミス3：ポリシー名とプロキシグループが一致していない

ルール内の「ノード選択」は、proxy-groupsであらかじめ定義されていなければなりません。プロキシグループの実際の名前が「プロキシ選択」なら、設定の読み込み時にポリシーが見つからないエラーが発生しやすくなります。日本語名、スペース、大文字・小文字を1文字ずつ確認してください。

ミス4：ポートをサービス識別子として扱う

DST-PORT,443,ノード選択は、対象ポートが443のすべての接続に適用され、特定のWebサイトだけを対象にはしません。一般的なHTTPS、アプリのAPI、一部の暗号化DNSサービスも443を使用します。ポートルールは明確なプロトコル境界に適しており、ドメインルールの代用には向きません。

rules:
  - DST-PORT,22,開発ネットワーク
  - NETWORK,udp,UDPポリシー
  - MATCH,ノード選択

ポート22であってもSSH以外のサービスに使われる場合があり、逆にSSHを別のポートで動かすこともできます。業務ネットワークに関わる場合は、単一のフィールドだけで判断せず、対象ドメイン、対象ネットワーク、ポートを組み合わせてください。

保守しやすいルールの並び順テンプレート

実際の設定に唯一の正解となる順序はありませんが、「ローカルの例外、特定サービス、ドメインの一括指定、IPと地域、デフォルトポリシー」の順に整理できます。以下のテンプレートは一般的なデスクトップ利用を想定しています。名前は設定に存在するプロキシグループへ置き換えてください。

rules:
  # 1. ローカルネットワークと明確な例外
  - DOMAIN,router.lan,DIRECT
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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

  # 2. 単一サービスの特定ポリシー
  - DOMAIN,api.example.com,専用ノード
  - DOMAIN-SUFFIX,example.net,メディアノード

  # 3. 外部ルールセット
  - RULE-SET,work-services,業務ネットワーク
  - RULE-SET,streaming-services,メディアノード
  - RULE-SET,direct-sites,DIRECT

  # 4. 広域ドメインと地域判定
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  # 5. 最終フォールバック
  - MATCH,ノード選択

プライベートIPv4ネットワークには10.0.0.0/8、172.16.0.0/12、192.168.0.0/16があります。ループバックアドレスの127.0.0.0/8も通常は直接接続にします。これらを明示的に記述する必要があるかは、既存のプライベートネットワーク用ルールセットとクライアント設定によって異なります。重複したルールを追加してもマッチング能力は向上しません。

ルール数と更新範囲を適切に管理する

設定変更後にルールの適用を確認する方法

YAMLを変更したら、まず設定を再読み込みできることを確認します。デスクトップクライアントには通常、設定の編集と再読み込みの入口があります。たとえば設定管理画面で現在の設定を開き、ファイルを編集・保存してから「再読み込み」を実行するか、その設定へ切り替えます。クライアントによってメニュー名は異なりますが、ファイルを保存するだけで再読み込みを省略しないでください。

mihomoの外部コントローラーを使う場合、一般的な待ち受けアドレスは127.0.0.1:9090です。HTTPとSOCKSの混合ポートは7890、DNSの待ち受けポートは1053がよく使われます。ただし、これらは一般的なデフォルト値にすぎないため、現在の設定にあるexternal-controller、mixed-port、dns.listenを確認してください。

4ステップで一致結果を確認する

  1. 設定を再読み込み：YAMLのインデント、未知のルールタイプ、存在しないポリシーに関するエラーがないことを確認します。
  2. 既存の接続を閉じる：対象アプリの既存接続を終了し、必要に応じてアプリを閉じて再起動します。確立済みの長時間接続は、新しいルールを追加しても自動的に再振り分けされません。
  3. 単一のテストを実行：バックグラウンドの同期、更新、プッシュ接続の影響を減らすため、1つの対象ドメインだけにアクセスします。
  4. 接続の詳細を確認：クライアントの「接続」画面で、Host、対象IP、適用されたルール、使用されたプロキシチェーンを確認します。

DOMAIN,api.example.com,専用ノードを追加したのに、接続の詳細でDOMAIN-SUFFIX,example.comに一致している場合は、まず完全一致ルールがサフィックスルールより前にあるか確認します。IP-CIDRと表示される場合は、アプリがIPへ直接接続しているか、ドメイン情報がコアに渡っていない可能性があります。

TUNモードでも同じルール順序に従う

TUNモードで変わるのは通信がコアへ入る方法であり、ルールが並列評価になるわけではありません。システムプロキシは通常、プロキシ設定に従うアプリを対象にします。一方、TUNモードはより多くのTCP、UDP通信や、システムプロキシを参照しないプログラムを取り込めます。通信がコアに入った後は、引き続き1つ目のルールから順に確認されます。

Fake-IP DNSの強化モードを有効にすると、アプリが予約済みアドレスを先に受け取り、コアがマッピングを使ってドメインを復元し、ルール判定に利用することがあります。そのため、接続画面にFake-IPが表示されても、DOMAINルールが無効とは限りません。アプリがハードコードされたIPにしか接続しない場合は、IP-CIDR、GEOIP、プロセスルールで対応してください。

ルールが適用されない場合の確認順序

ルールの問題は、設定の読み込み、通信の入口、接続情報、ルールの位置という4つの層に分けて確認できます。まずコアが新しい設定を使っていることを確認し、次に対象通信がClashへ入っているかを判断し、最後にルール自体を確認します。構文を何度も変更するだけでは、システムプロキシが有効になっていない、または設定が再読み込みされていない問題を見落としがちです。

設定を読み込めるか

対象通信がコアに入っているか

システムプロキシモードでは、アプリがシステムプロキシ設定を無視することがあります。TUNモードでも、ルート除外、インターフェースの競合、権限の問題が発生する場合があります。接続一覧に対象アプリがまったく表示されないなら、ルールを変更し続ける前に入口を確認してください。ブラウザーの既存接続が接続の再利用で動き続けることもあり、タブを閉じても基盤の接続がすぐ切れるとは限りません。

コアが受け取っているのはドメインかIPか

DOMAIN系のルールにはドメイン情報が必要です。アプリがIPへ直接アクセスする場合、IP-CIDR、GEOIP、ポート、ネットワーク種別、プロセス情報に頼る必要があります。逆に、IP-CIDRへno-resolveを付けた場合、接続にドメインしかないと、そのルールはスキップされ、能動的に解決してから比較することはありません。

前により広いルールがないか

対象ルールより上にあるDOMAIN-SUFFIX、DOMAIN-KEYWORD、RULE-SET、GEOSITE、GEOIP、MATCHを順に確認します。どれか1つが先に一致すると、対象ルールは実行されません。切り分け時は完全一致ルールを一時的にルール一覧の先頭へ移しても構いません。検証に成功したら、構造上適切な位置へ戻します。

ルール作成時にそのまま使える結論

保守しやすいルールは、大量の項目ではなく、各ルールの範囲と位置を説明できる構成で決まります。まず特定の例外、次に一括ルールセット、最後に地域判定とMATCHのフォールバックを置けば、問題が起きても実行順に沿ってすばやく原因を特定できます。

Clashクライアントをダウンロード Windows、macOS、モバイル版を確認