カスタムルールの書き方：DOMAIN・IP-CIDRなどの構文とマッチング優先順位を詳しく解説

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

Clashとmihomoの基本ルールは通常、カンマで区切られます。最も一般的な構成は「ルールタイプ、マッチ対象、適用するポリシー」です。たとえば DOMAIN-SUFFIX,github.com,PROXY は、対象ドメインが github.com で終わる場合に、接続を PROXY という名前のポリシーグループへ渡すことを示します。ポリシー名は大文字・小文字を区別するため、proxy-groups 内の名前と完全に一致させる必要があります。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,FINAL

ここで DIRECT と REJECT は組み込みアクションです。一方、PROXY と FINAL はユーザー定義のポリシーグループにできます。ルールは特定のサーバーを直接指定しなくても有効です。一般的にはルールからポリシーグループを参照し、実際のノードはグループ側で手動選択、遅延テスト、フォールバックなどによって決定します。

YAMLのインデントとルールの位置

rules は設定ファイルのトップレベル項目です。リスト項目の前には通常、半角スペース2つでインデントします。Tab文字は使わず、ルールを proxy-groups や rule-providers の内部に記述しないでください。編集後はクライアントに設定を再読み込みさせる必要があります。ファイルを保存するだけで再読み込みを行わない場合、実行中のカーネルが古い内容を使い続けることがあります。

一般的なデスクトップクライアントでは、まず設定画面で現在有効な設定を開きます。編集後、「保存」または「再読み込み」を実行してください。次に「接続」画面から対象ドメインへアクセスし、その接続に表示されるルールタイプとポリシーの経路を確認します。クライアントによってメニュー名は多少異なりますが、確認すべき点は同じです。現在の設定ファイル、カーネルの稼働状態、接続ログが一致していることを確認しましょう。

DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORDの選び方

DOMAIN：完全一致のドメインだけを対象にする

DOMAIN は単一のホスト名に適しています。次のルールは api.example.com のみにマッチし、www.example.com にはマッチしません。また、v2.api.example.com まで自動的に対象になることもありません。

rules:
  - DOMAIN,api.example.com,PROXY

ログインAPI、更新サーバー、特定の固定APIに個別のポリシーを指定する場合は、まず DOMAIN を使います。対象範囲が明確なので、同じ親ドメインにある別サービスへ意図せず適用されにくいのが特徴です。

DOMAIN-SUFFIX：親ドメインとサブドメインにマッチさせる

DOMAIN-SUFFIX,example.com,PROXY は通常、example.com、www.example.com、a.b.example.com にマッチします。カスタムドメイン分流で最もよく使われるタイプで、1つのサイトにある複数のサブドメインへ同じポリシーを適用したい場合に適しています。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-SUFFIX,example.net,DIRECT

サフィックスにはドメインそのものを記述し、https://、パス、ポート、ワイルドカードは付けません。正しい値は example.com であり、https://example.com/path や *.example.com ではありません。Clashのルールが判定するのは接続先であり、Web URL全体のパスではありません。

DOMAIN-KEYWORD：ドメイン内の文字列でマッチさせる

DOMAIN-KEYWORD は、ドメインに指定した文字列が含まれているかを確認します。たとえば DOMAIN-KEYWORD,google,PROXY は、google を含む複数のドメインにマッチします。短く書ける一方、サフィックスルールより対象範囲が広く、目的のサービスとは無関係なドメインまで拾う可能性があります。

ルールタイプ	対象例	マッチするか	用途
`DOMAIN,api.example.com`	`api.example.com`	はい	固定APIまたは単一ホスト
`DOMAIN,api.example.com`	`v2.api.example.com`	いいえ	サブドメインには適用されない
`DOMAIN-SUFFIX,example.com`	`img.example.com`	はい	サイト全体とサブドメインをまとめて分流
`DOMAIN-KEYWORD,example`	`example-cdn.net`	はい	ドメインが分散しており、安定したキーワードがある場合

IP-CIDR・IP-CIDR6とno-resolveの役割

CIDRはアドレス範囲を表す

IP-CIDR はIPv4アドレスまたはネットワークを対象にします。192.168.1.0/24 は 192.168.1.0 から 192.168.1.255 までをカバーし、1.1.1.1/32 は単一のIPv4アドレスだけにマッチします。IPv6には IP-CIDR6 を使い、例として 2001:db8::/32 のように記述します。

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

これらのルールは、ローカルループバック、家庭内LAN、企業内ネットワークへの直接接続によく使われます。PCがHTTPまたはmixedポートを介して同じネットワーク上の機器へプロキシを共有している場合、ルーターの管理画面、NAS、プリンターへのアクセスがプロキシノードへ回らないよう、LANルールは広範囲のプロキシルールより前に置くのが一般的です。

no-resolveは「DNSを無効にする」機能ではない

接続先がまだドメイン名の場合、IP系ルールにマッチするか判定するため、カーネルがそのドメインに対応するIPを先に取得することがあります。IP-CIDR または GEOIP ルールの末尾に no-resolve を付けると、そのルールの判定だけを目的とした能動的なドメイン解決を行わないよう指定できます。接続先がもともとIPアドレスなら、ルールは通常どおり比較されます。

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,10.20.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

このルール群では、internal.example は先にドメインルールで判定され、接続先が 10.20.3.8 と直接指定されている場合はIP-CIDRルールで判定されます。no-resolve は設定のDNSモジュールを停止するものでも、アプリ自身のDNS問い合わせを妨げるものでもありません。また、ドメインルールをIPルールへ変える機能でもありません。

IPルールが不安定になる理由

大規模サイトではCDNが使われることが多く、同じドメインでもネットワーク、時間帯、DNSサーバーによって異なるIPが返されます。一時的な名前解決結果を /32 ルールにすると、短期間はマッチしてもアドレスの変更後に機能しなくなります。安定したドメインで表現できるサービスには、まずドメインルールを使いましょう。IPルールは、接続先が固定アドレスやLANのネットワークである場合、またはアドレスの地域情報による判定が必要な場合に限定するのが適切です。

ルールの優先順位：タイプではなく、上から順に最初のマッチが適用される

Clashルールの基本原則は順番に判定することです。接続は rules リストの先頭から確認され、いずれかのルールにマッチすると、そのルールに指定されたポリシーが直ちに適用され、後続のルールは確認されません。「DOMAINは本質的にIP-CIDRより優先される」「REJECTは自動的にDIRECTより優先される」といった固定のタイプ別優先順位はありません。

rules:
  - DOMAIN,download.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,FINAL

download.example.com にアクセスすると、1行目がすでにマッチするため結果は DIRECT です。www.example.com では1行目にマッチせず、2行目が適用されるため結果は PROXY になります。2行を入れ替えると、ダウンロード用ドメインが先にサフィックスルールで捕捉され、もともとの完全一致による直接接続ルールは実行されません。

推奨される並び順

ローカルホスト、LAN、明示的に直接接続する固定の対象。
一般ルールより優先させたい、具体的なDOMAIN・DOMAIN-SUFFIXまたはIP-CIDR。
広告ブロック、サービス分類、GEOSITE、外部ルールセット。
地域別のGEOIPルールと、その他の広範囲な判定。
最後にMATCHで、それまでマッチしなかった接続を受ける。

これはカーネルが強制する形式ではなく、保守しやすくするための整理方法です。原則は「対象範囲が具体的であるほど、例外の優先度が高いほど前に置く」です。サブスクリプションが提供する大規模なルールセットより例外ルールを優先させる場合は、該当する RULE-SET より前に記述する必要があります。

MATCHは末尾に置く

MATCH はマッチ対象を持たず、まだどのルールにも該当していないすべての接続を受けます。従来の設定では、末尾のルールタイプとして FINAL が使われていることもありますが、現在のmihomo設定では一般に MATCH が使われます。どちらを使う場合でも、リストの途中に置くと、その後ろにあるルールは実行されません。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - RULE-SET,private,DIRECT
  - RULE-SET,streaming,MEDIA
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOIP・GEOSITE・RULE-SETの使い分け

GEOIPは対象IPの地域情報で判定する

GEOIP,CN,DIRECT が判定するのは対象IPであり、ドメインの登録地、サーバー運営会社、Webページの言語ではありません。データベースの内容が結果に影響するため、クライアントのカーネルと地理データベースは利用可能な状態に保つ必要があります。CDNのエッジノード、Anycastアドレス、データベース更新の遅延により、直感とは異なる分類になることもあります。

Fake-IP DNSモードを使っている場合、ドメイン接続にはルールシステムが判定するためのドメイン情報が保持されます。具体的な解決とマッピングはカーネルが処理します。接続一覧に 198.18.0.0/16 範囲のFake-IPが表示されたからといって、そのアドレス範囲全体をプロキシルールにしないでください。この予約ネットワークはFake-IPのマッピング用であり、Webサイトの実サーバーアドレスを示すものではありません。

GEOSITEはドメインのカテゴリで判定する

mihomoは GEOSITE ルールに対応しており、地理データファイル内のドメイン分類に基づいてマッチさせます。たとえば GEOSITE,cn,DIRECT はドメインの集合を使い、GEOIP,CN,DIRECT はIPの地域データを使います。名前は似ていますが、判定の段階とデータソースは異なります。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOSITEのカテゴリ名は、現在使用しているデータセットに依存し、すべての旧Clashカーネルが対応しているわけではありません。異なるクライアント間で設定を移行する場合は、まずカーネルの種類とルールの対応状況を確認してください。クライアントの「設定」にあるカーネル情報ページで実行中のカーネルを確認できるほか、コマンドラインで mihomo -v を実行してバージョンを確認できます。

RULE-SETでルールプロバイダーを参照する

RULE-SET にドメインを直接記述するのではなく、rule-providers に定義されたルール集合を参照します。ここでの private はプロバイダーのキー名と一致していなければなりません。プロバイダーの behavior は domain、ipcidr、classical のいずれかで、ファイルの内容もそのタイプに合わせる必要があります。

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

rules:
  - RULE-SET,private,DIRECT
  - MATCH,PROXY

interval: 86400 は86400秒ごと、つまり24時間ごとに更新を確認するという意味です。ルールプロバイダーのダウンロードに失敗した場合は、まずURLへアクセスできるか、ファイル形式が behavior に合っているかを確認し、その後クライアントが ./ruleset/ への書き込みを許可しているか確認します。リモートURLを rules に貼り付けるだけで、自動的にルールセットになるわけではありません。

ポート・プロセス・ネットワーク入口のルール

DST-PORTとSRC-PORT

DST-PORT は宛先ポートでマッチします。たとえば DST-PORT,443,PROXY はHTTPSなど443番ポートを使う多数の接続に適用されるため、対象範囲が広くなりがちです。SRC-PORT はローカル側の送信元ポートで判定しますが、アプリの一時ポートは頻繁に変わるため、長期的な分流条件として使われることは多くありません。

rules:
  - DST-PORT,22,DIRECT
  - DST-PORT,853,PROXY
  - MATCH,FINAL

ポートルールで指定するのは対象サービスのポートであり、Clashの待受ポートではありません。設定の mixed-port: 7890 は、ローカルのプロキシ入口が7890番ポートで待ち受けることを示します。これはWebサイトへ接続する際の宛先ポート80や443とは別の概念です。mixed-portを経由するすべての通信を対象にしようとして DST-PORT,7890 と記述しないでください。

PROCESS-NAMEの対応はプラットフォームと取り込み方式に依存する

mihomoは一部のデスクトップ環境で、プロセス名やプロセスパスによる分流に対応しています。例として PROCESS-NAME,curl,DIRECT のように記述します。プロセスルールはOSが提供する接続情報とプロセス情報に依存するため、Android、iOS、コンテナ、権限制限のある環境では利用できない場合があります。実行ファイル名もOSによって異なり、Windowsでは .exe が付くことがあるため、設定を移行する際は再確認してください。

rules:
  - PROCESS-NAME,curl,DIRECT
  - PROCESS-NAME,backup-client.exe,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,FINAL

システムプロキシモードは、HTTPまたはSOCKSのプロキシ設定に従うアプリの通信を主に受け取ります。一方、TUNモードは仮想ネットワークインターフェースを通じて、より広いIP通信を取り込みます。2つのモードでルールの順序は変わりませんが、カーネルが取得できる対象情報は異なる場合があります。プロセスルールを調べる前に、その接続が確実にClashへ入っていることを確認し、接続詳細にプロセス名が表示されるか確認してください。

ルールが反映されないときの確認手順

ステップ1：編集したのが現在有効な設定か確認する

クライアントには、サブスクリプション設定、ローカル設定、オーバーライド設定が同時に保存されている場合があります。まず現在有効な項目の名前と更新日時を確認し、最終的に実行設定へルールが書き込まれているか確認してください。サブスクリプション更新時に元の設定を置き換えるクライアントもあるため、カスタム内容はクライアントが対応するオーバーライド、マージ設定、または独立したローカル設定に入れる必要があります。

現在の設定が直前に再読み込みされたか確認する。
設定の解析でYAMLのインデントやフィールドのエラーが出ていないか確認する。
対象のポリシーグループが存在し、名前と大文字・小文字が完全に一致していることを確認する。
サブスクリプション更新後、カスタムルールが最終設定に残っているか再確認する。

ステップ2：接続ログから実際にマッチした項目を読む

クライアントの「接続」または「ログ」画面を開き、もう一度リクエストを送信します。ブラウザーは既存のTCP、QUIC、HTTP/2接続を再利用することがあるため、ルール変更後にページを更新するだけでは新しい接続が作られない場合があります。該当タブを閉じて数秒待ってから再試行するか、接続一覧で古い接続を終了してください。

api.example.com を直接接続したいのに、ログで DOMAIN-SUFFIX,example.com にマッチしてプロキシグループへ入っている場合、より広いルールが前に置かれています。ログに MATCH とだけ表示される場合は、通常、ドメインの綴り、ルール形式、またはルールセットの読み込みに問題があります。

ステップ3：表示されているのがドメインかIPか確認する

アプリがIPアドレスへ直接アクセスしている場合、DOMAIN系ルールにマッチしないのは当然です。アプリが独自の暗号化DNS、内部キャッシュ、QUIC接続を使っている場合も、カーネルが見る情報はブラウザーのアドレスバーと異なることがあります。接続詳細のHost、宛先アドレス、ネットワークタイプ、プロセス情報のほうが、Webドメインから推測するより確実です。

設定でTUNを有効にしている場合は、システムプロキシモードとTUNモードの接続記録を一時的に比較できます。ただし、DNS、ルール、ノードを同時に何度も変更しないでください。一度に変更する変数は1つに絞り、まず通信がカーネルへ入っているか、次に対象情報、最後にルールの順序を確認します。

ステップ4：ルール名だけでなくポリシーグループを確認する

ルールが PROXY にマッチするのは、接続がそのポリシーグループへ渡されたことを示すだけです。PROXY で現在手動選択されている項目が DIRECT なら、実際の出口は直接接続になります。遅延テストグループが選択されている場合は、グループ内のテスト結果によって実際のノードが決まります。接続詳細には通常、「ルール → ポリシーグループ → ノード」のような完全な経路が表示されます。

ステップ5：最小構成のルールセットで再現する

大規模なサブスクリプションには数万件のルールが含まれることがあり、完全な設定内で項目を移動するだけでは競合を判断しにくくなります。一時的なローカル設定を作成し、必要なプロキシ、1つのポリシーグループ、2〜3件のテストルール、末尾のMATCHだけを残してください。テストに成功したら、具体的なルールを正式設定の該当するルールセットより前へ戻します。

rules:
  - DOMAIN,test.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

テスト時には、対象ドメイン、接続時刻、マッチしたルール、最終的なポリシーを記録します。毎回古い接続を終了してから、3回連続でテストしてください。3回とも結果が一致して初めて、ルールの順序が安定して反映されたと判断できます。1回目は古いポリシー、2回目と3回目は新しいポリシーになる場合、通常は接続の再利用やDNSキャッシュが原因であり、マッチングアルゴリズムがランダムに変化したわけではありません。

保守しやすい完全なルール例

以下の構成では、まずLANと明確な例外を処理し、次に広告、サービス分類、中国本土のドメインと中国本土のIPを処理し、最後に残りの接続をプロキシグループへ渡します。ここで示すのは並べ方の例です。ポリシーグループ名とルールセットのURLは、実際の設定に合わせて調整してください。

rules:
  # ローカルホストとLAN
  - 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,fc00::/7,DIRECT,no-resolve

  # 明確な例外
  - DOMAIN,updates.example.com,DIRECT
  - DOMAIN-SUFFIX,work.example,WORK
  - DOMAIN-SUFFIX,github.com,PROXY

  # 分類ルール
  - GEOSITE,category-ads-all,REJECT
  - RULE-SET,private,DIRECT
  - RULE-SET,streaming,MEDIA

  # 広範囲のルール
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve

  # フォールバック
  - MATCH,PROXY

保守時はルールグループごとにコメントを付け、手動で追加する例外を大規模なルールセットより前にまとめます。変更後は、具体的なドメイン、中国本土のサイト、プロキシ対象サイト、LAN内のアドレス（たとえばルーターの 192.168.1.1）を1つずつ確認してください。4種類の接続がすべて想定どおりになってから、ルールの範囲を広げます。

ルールと分流で重要なのは、項目を増やすことではありません。各ルールの対象範囲を説明でき、順序を検証でき、マッチ結果をログから再現できる状態にすることです。問題が起きたら、現在の設定、接続先、最初にマッチしたルール、ポリシーの経路、実際の出口という5つの箇所を順に確認すると、原因をすばやく特定できます。