Clashのカスタムルールの書き方：DOMAIN系の構文とマッチング優先順位を徹底解説

Clashルールの構造をまず理解する

Clashのルールシステムは、接続の特徴に応じて通信の行き先を決定します。最も一般的なルールは、ルール種別、マッチング対象、ポリシーの3要素で構成され、各フィールドは英字のカンマで区切ります。ドメインルールの場合、次の行は api.example.com へのアクセスに DIRECT というポリシーを適用することを示します。

DOMAIN,api.example.com,DIRECT

DOMAIN はルール種別、api.example.com はマッチング対象、DIRECT は適用先のポリシーです。適用先には組み込みアクションだけでなく、設定済みのプロキシやポリシーグループ名も指定できます。代表的な組み込みアクションは DIRECT と REJECT です。設定に「ノード選択」というポリシーグループがあれば、ルール末尾にそのまま「ノード選択」と書けます。名前は一字一句一致させる必要があり、空白、大文字・小文字、記号も名前の一部です。

完全なルール一覧はどこに記述するか

従来のClash YAMLでは、インラインルールをトップレベルの rules フィールドに記述します。各項目は先頭にハイフンを置き、並び順がそのまま実際のマッチング順になります。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

設定を編集できるGUIクライアントでは、通常「設定」→現在の設定を選択→「編集」の順に進むとYAMLを開けます。ボタン名はクライアントによって「ファイルを編集」「設定を表示」「拡張設定」など異なります。保存後は設定を再読み込みしてください。ディスク上のファイルだけを変更してリロードしない場合、実行中のカーネルは古いルールを使い続けます。

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDの違い

Webサイトの振り分けには、まずドメインルールを使うのがおすすめです。リクエストのドメインを直接利用でき、先にIPへ名前解決する必要がないためです。代表的なDOMAIN系ルールは対象範囲がそれぞれ異なるため、名前が似ているからといって置き換えることはできません。

ルール種別	例	マッチする対象	マッチしない対象
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	`api.example.com`	`www.example.com`、`v2.api.example.com`
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com` とそのサブドメイン	`example.com.test`
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,DIRECT`	ドメインに `example` を含む接続	この連続した文字列を含まないドメイン

DOMAIN：完全なホスト名だけにマッチ

DOMAIN は、特定のホスト名だけを処理したい場合に適しています。たとえば、ソフトウェアの更新APIだけを直接接続にし、同じ親ドメインにある他のサービスの経路は変えない、といった設定が可能です。

DOMAIN,updates.example.com,DIRECT
DOMAIN,telemetry.example.com,REJECT
DOMAIN-SUFFIX,example.com,ノード選択

updates.example.com へのリクエストは1行目でマッチして停止し、telemetry.example.com へのリクエストは2行目でマッチします。store.example.com へのリクエストだけが3行目のサフィックスルールまで進みます。例外を維持するには、具体的なルールを広範囲のルールより上に置きます。

DOMAIN-SUFFIX：親ドメインとすべての下位ドメインを対象にする

DOMAIN-SUFFIX,example.com,ノード選択 は、example.com、www.example.com、cdn.assets.example.com を対象にします。通常の文字列の末尾一致のように fakeexample.com まで誤ってマッチすることはなく、ドメインラベルの境界に沿って判定されます。

1つのWebサイトが、ログイン、API、画像、静的リソース用のサブドメインを使い分けることは珍しくありません。これらのサブドメインに同じポリシーを適用すると確認できている場合、完全なドメインを1つずつ列挙するより、サフィックスルールを1つ置くほうが管理しやすくなります。特定のサブドメインだけ例外にする場合は、対応する DOMAIN をサフィックスルールの上に置きます。

DOMAIN-KEYWORD：範囲が広いため、誤マッチを確認して使う

DOMAIN-KEYWORD は、ドメインに指定した文字列が含まれているかを確認します。ドメインが頻繁に変わるものの、共通するブランド名の一部があるサービスに向いていますが、名前が似ている無関係なドメインまで対象にする可能性があります。キーワードが短いほど対象範囲は広くなります。たとえば cdn なら、互いに無関係な多数のコンテンツ配信ドメインにマッチすることがあります。

DOMAIN-KEYWORD,company-service,ノード選択

DOMAIN や DOMAIN-SUFFIX で表現できる場合は、対象範囲が明確なルールを優先してください。キーワードルールは、完全一致のドメインルールとサフィックスルールの後、IP系ルールの前に置くのが適しています。

ルールの優先順位は一つだけ：上から順に判定し、最初にマッチしたものを使う

Clashは、すべてのマッチ結果を集めてから「より具体的な」ルールを選ぶわけではありません。カーネルは rules の1行目から確認し、最初にマッチしたルールのポリシーを直ちに適用します。後続のルールは判定されません。つまり、優先順位の本質は設定ファイル内の並び順です。

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

この設定では、api.example.com が先に1行目の DOMAIN-SUFFIX にマッチするため、2行目の完全一致ルールは永遠に適用されません。正しくは、例外を広範囲のルールより上に置きます。

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

管理しやすい並べ替え方

最も具体的な拒否、直接接続、指定ノードの例外。たとえば単一の DOMAIN。
複数のサービスをまとめて対象にする DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOSITE。
LAN、予約済みアドレス、既知のネットワーク帯域に対する IP-CIDR、IP-CIDR6。
国や地域で分類する GEOIP。
最後にフォールバックルールの MATCH。

これは構文上の必須テンプレートではなく、ルール同士の遮蔽を減らすための実用的な順序です。本当に優先すべきルールは、より上に置いてください。たとえば、特定のIP帯域へのアクセスを拒否する必要があるなら、先にマッチする可能性のある広範囲の直接接続ルールの後ろに置いてはいけません。

IP-CIDR、GEOIP、no-resolveの実際の役割

IP-CIDR は宛先のIPv4アドレスまたはネットワーク帯域に、IP-CIDR6 はIPv6にマッチします。CIDRの後ろの数字はネットワークプレフィックス長を示します。192.168.1.0/24 は 192.168.1.0 から 192.168.1.255 までを対象にし、10.0.0.0/8 は 10.0.0.0 のプライベートアドレス帯域全体を対象にします。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fd00::/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
MATCH,ノード選択

GEOIP は、宛先IPが地理データベースでどの地域に割り当てられているかをもとにマッチします。たとえば GEOIP,CN,DIRECT は、データベース上で中国本土のアドレスと判定された接続を直接接続にします。判定精度は、カーネルが実際に読み込んでいるGeoIPデータに左右されます。クラウドサービス、Anycast、アドレス変更などにより、サーバーの物理的な所在地と結果が一致しない場合もあります。

IPルールでDNS名前解決が発生する理由

アプリが接続を開始するとき、カーネルが受け取る宛先はドメイン名の場合もあれば、すでにIPになっている場合もあります。IP-CIDR や GEOIP を確認する際、現在の情報がドメイン名だけなら、対象IPを取得するために名前解決が必要になることがあります。そのIPが指定されたネットワーク帯域や地域に属するかを判定するためです。これがIPルールとDNSクエリの関係です。

このパラメータに対応するIP系ルールの末尾に no-resolve を追加すると、そのルールを確認するためだけにドメイン名を解決しないよう指定できます。接続自体に宛先IPが含まれていれば、ルールは通常どおりマッチします。ドメイン名しかなく宛先IPを取得できない場合は、名前解決が必要な判定をスキップし、後続のルールを確認します。

IP-CIDR,203.0.113.0/24,ノード選択,no-resolve

no-resolve は汎用的なパフォーマンス設定ではなく、DOMAIN、DOMAIN-SUFFIX、MATCH の後ろに付けるものでもありません。主にIP系ルールで使用します。使うかどうかは目的次第です。LANのネットワーク帯域なら、宛先がもともとプライベートIPなので追加しても問題ありません。一方、ドメイン名を解決した後のIPで所属を判定する必要がある場合は、名前解決を止めるために使用してはいけません。

Fake-IPモードでもドメインルールを先に置く

Fake-IP DNSモードでは、クライアントが先にマッピングアドレスを受け取ることがあります。しかしカーネルはドメイン名とマッピングの関係を保持しているため、ドメインルールによる振り分けは引き続き可能です。明確なドメインルールをIPの地理ルールより上に置けば、CDNアドレスの変化によって同じサービスの行き先が変わるのを防げます。利用できるドメイン情報がない場合やドメインルールにマッチしない場合にだけ、IPによる判定がより重要になります。

mihomoで使える代表的な拡張ルール：GEOSITE、ポート、プロセス

Clash Metaの現行カーネルであるmihomoは、初期のClashより豊富なルール種別に対応しています。複数のカーネルで設定を共用する場合は、まずクライアントが実際にどのカーネルを起動しているか確認してください。非対応のルール種別は、設定の読み込みに失敗する直接の原因になることがあります。

ルール	用途	例
`GEOSITE`	ドメイン分類データベースでサイト群にマッチさせる	`GEOSITE,category-ads-all,REJECT`
`DST-PORT`	宛先ポートでマッチさせる	`DST-PORT,22,DIRECT`
`SRC-IP-CIDR`	接続元アドレスでマッチさせる	`SRC-IP-CIDR,192.168.1.50/32,DIRECT`
`PROCESS-NAME`	プロセス名でマッチさせる	`PROCESS-NAME,backup.exe,DIRECT`

GEOSITE はデータベース内のドメイン集合にマッチするもので、サーバーIPの所在国を判定するものではありません。一方、GEOIP はIPデータベースをもとに判定します。名前は似ていますが、対象はまったく異なります。設定で GEOSITE を使う前に、クライアントが対応するGeoSiteデータを設定し、読み込めることを確認してください。

プロセスルールは、OSとカーネルがプロセス情報を取得できるかどうかに依存します。TUNモードでは、プロセス識別の対応状況がプラットフォームによって完全には統一されていません。Windows、macOS、Linuxで設定を共用する場合、ドメインルールとIPルールのほうが安定しやすくなります。プロセスルールは特定の端末で補助的に使うのが適しており、唯一の判定条件にするのは避けたほうがよいでしょう。

カスタムルールはどの行に追加するか

カスタムルールが有効になるかどうかは、通常「正しく書けているか」だけでなく、先にマッチするルールより上に置かれているかで決まります。挿入位置を探すときは、まず設定末尾にある GEOIP、広範囲の RULE-SET、MATCH を確認し、追加するルールがどの動作を上書きするのか判断します。

ケース1：1つのドメインをプロキシ経由から除外する

元の設定で DOMAIN-SUFFIX,example.com,ノード選択 が親ドメイン全体を対象にしている場合、追加する直接接続の例外はその上に置く必要があります。

rules:
  - DOMAIN,office.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ケース2：特定のネットワーク帯域を常にプロキシ経由にする

そのネットワーク帯域が先に GEOIP,CN,DIRECT にマッチする可能性があるなら、帯域ルールをGEOIPより上に追加します。

rules:
  - IP-CIDR,198.51.100.0/24,ノード選択,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ケース3：サブスクリプション設定でルールを長期的に維持する

サブスクリプションが生成したYAMLを直接編集しても、次回更新までしか維持できないことが多くあります。更新後、クライアントは通常、リモートの内容でローカルコピーを上書きします。より確実なのは、クライアントの設定オーバーライド、設定マージ、拡張スクリプトを使い、サブスクリプションのルールより前にカスタムルールを挿入する方法です。具体的な入口は使用中のクライアントに従ってください。一般的には「設定」→「設定管理」→「オーバーライド」、または現在のサブスクリプションのメニューから「拡張設定」を選びます。

数十件を超えるルールを管理する場合は、rule-providers を利用できます。ルールセットを個別に更新し、メイン設定からは RULE-SET で参照します。

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

rules:
  - RULE-SET,private-sites,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

behavior: domain は、ルールセットのペイロードがドメイン形式の内容であることを示します。ルールセットに DOMAIN、IP-CIDR などの完全なルールが含まれる場合は、完全なルールに対応する classical ビヘイビアを使ってください。プロバイダーの種類、ファイル形式、実際の内容は一致している必要があります。完全なClashルールを、ドメイン形式のペイロードだけを受け付けるセットにそのまま入れることはできません。

保存後にルールの実際のマッチを確認する方法

ルールの検証は、Webページが開くかどうかだけで判断できません。ページが表示されても、直接接続、プロキシ、キャッシュ、別のネットワーク経路による可能性があります。設定の読み込み状態、接続ログ、実際にマッチしたルールを同時に確認してください。

設定を保存して再読み込みを実行し、画面にYAMLの解析エラーやルール種別のエラーがないことを確認します。
対象アプリの既存の接続を切断し、必要であればアプリを完全に終了してから再起動します。
クライアントの「接続」ページで、ドメイン名を使って対象リクエストを絞り込みます。
接続に表示されたルール種別、ルール内容、最終的に適用されたポリシーグループを確認します。
親ドメイン、サブドメイン、マッチしてはいけない類似ドメインをそれぞれテストし、対象範囲が想定どおりか確認します。

たとえば DOMAIN-SUFFIX,example.com,DIRECT をテストする場合、example.com、api.example.com、example.com.test の順に確認します。前2つはマッチし、3つ目はマッチしないはずです。完全一致ルールをテストするときは v2.api.example.com も追加してください。これは DOMAIN,api.example.com,DIRECT と同じドメインとして扱われるべきではありません。

ルールが有効にならないときの確認手順

まず上にあるルールに先取りされていないか確認：接続の詳細で実際にマッチしたルールを確認し、末尾のカスタム項目を何度も移動するのは避けます。
次にポリシー名を確認：ルール末尾はポリシーグループ名と完全に一致していなければなりません。
現在の設定を確認：編集したファイルが、クライアントで実際に使用中の設定とは限りません。
既存の接続を確認：ルールを変更しても、すでに確立されたTCP接続の振り分けは通常やり直されません。
DNSと宛先種別を確認：アプリがIPへ直接接続している場合や、別のサブドメイン、QUICのUDP接続を使っている場合があります。
カーネルの互換性を確認：GEOSITE、論理的な組み合わせ、複数のプロセスルールにはmihomoの対応が必要です。

順序をすぐ確認できるルール例

次の構成は、「単一ドメインの例外、ドメイン集合、プライベートネットワーク帯域、地域ルール、最終フォールバック」の順序を示しています。ポリシーグループ名は使用中の設定に合わせてください。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN,ads.example.com,REJECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - GEOSITE,category-ads-all,REJECT
  - 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
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

この例では、ログイン用ドメインを優先的に直接接続し、広告用サブドメインを優先的に拒否し、その他の example.com サービスを「ノード選択」へ送ります。その後に一般的な広告カテゴリ、プライベートアドレス、地域別IPを確認します。最後に、どのルールにもマッチしなかった接続を MATCH に渡します。ルールを追加するときは、「どの既存ルールを上書きするべきか」を先に考えれば、挿入位置はおおむね決まります。

ルール管理で重要なのは、数を増やすことではなく対象範囲を制御することです。まず完全なドメイン名を使い、サブドメイン全体でポリシーが統一されていると確認できてからサフィックスを使います。IPルールでは名前解決を許可するか明確にし、広範囲の分類ルールとフォールバックは後ろに置きます。変更後は接続詳細でマッチした項目を確認すると、Webページの表示だけを見るより速く問題を特定できます。