Clashのカスタムルール設定方法：DOMAIN-SUFFIX・IP-CIDRと優先順位

ルールの構成：タイプ・マッチ条件・出力先

Clashのカスタムルールは、設定ファイルの rules リストに記述します。FlClashでmihomoコアを使用している場合、リクエスト情報をもとにルールを上から順に判定し、一致したリクエストを指定のポリシーに振り分けます。まず、編集する設定がクライアントで選択されていることと、モードが「ルール」になっていることを確認してください。グローバルモードとダイレクトモードでは、通常このルールリストによる振り分けは行われません。

多くのルールは、ルールタイプ,マッチ条件,出力先の3要素で構成されます。各要素は半角カンマで区切り、YAMLのリスト項目はハイフンと半角スペースで始めます。以下は、既存の設定に追加できるルール例です。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

DOMAIN はタイプで、完全一致するドメインを指定します。login.example.com は条件、DIRECT は直接接続を表します。
REJECT は接続を拒否するポリシーです。2行目はブロックの例です。実際に設定する前に、対象となるドメインの範囲を確認してください。
no-resolve は4つ目に指定する任意のパラメーターで、関連するIPルールで使用します。ポリシー名ではありません。
MATCH は最終的なフォールバックルールです。マッチ条件がないため、要素は2つだけです。

DOMAINとDOMAIN-SUFFIX：完全一致とドメインの末尾一致

ログインページやAPI、ダウンロード用ドメインなど、特定のホストだけを振り分ける場合は DOMAIN を使います。メインドメインとすべてのサブドメインを対象にする場合は DOMAIN-SUFFIX を指定します。どちらも照合するのはホスト名であり、ブラウザーのアドレスバーに表示される完全なURLではありません。

ルール	一致するホスト名	対象範囲
`DOMAIN,api.example.com,DIRECT`	`api.example.com`	配下のサブドメインは含まない
`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com`、`api.example.com`	メインドメインと配下のサブドメイン
`DOMAIN-KEYWORD,example,DIRECT`	ホスト名に example を含むドメイン	範囲が広く、無関係なサービスにも影響する可能性あり

ドメインルールにはプロトコル・パス・ポートを指定しない

https://api.example.com:8443/v1/status にアクセスする場合も、ドメインルールのマッチ条件はURL全体ではなく api.example.com です。サフィックスを指定するために *.example.com と書く必要はありません。DOMAIN-SUFFIX,example.com,DIRECT を使用します。

特定のポートだけを対象にする場合は、DST-PORT を検討してください。たとえば DST-PORT,8443,DIRECT は、ドメインにかかわらず宛先ポートが8443のリクエストに一致します。ドメインとポートの両方を条件にする場合は、使用中のmihomoのバージョンでサポートされる論理ルールの構文を確認してください。通常の3要素ルールに条件をそのまま連結することはできません。

ドメインを識別できるかどうかでルールの適用可否が決まる

HTTPプロキシやSOCKS経由でドメイン名が渡される場合、コアは通常ホスト名を取得できます。一方、TUNで処理する接続は宛先IPとして認識されることがあり、ドメイン名を復元できるかどうかはDNSモード、マッピング情報、スニッフィング設定などにも左右されます。接続詳細にIPアドレスしか表示されない場合、ドメインルールを追加してもすぐには適用されない可能性があります。まず、クライアントが実際にどの宛先情報を認識しているか確認してください。

IP-CIDRとno-resolve：アドレス範囲とDNS解決のタイミング

IP-CIDR はIPv4アドレス範囲、IP-CIDR6 はIPv6アドレス範囲に使用します。CIDRのスラッシュ以降の数字はプレフィックス長です。192.168.50.0/24 は192.168.50.0から192.168.50.255まで、192.168.50.10/32 は単一のIPv4アドレスに一致します。ポート範囲を表すものではありません。

rules:
  - IP-CIDR,192.168.50.10/32,DIRECT,no-resolve
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,DIRECT

上記のIPv6ルールは fd00::/8 を対象とします。これはローカルで割り当てられることの多いULAアドレスです。ここでは特定のネットワーク範囲のみを例示しており、プライベートネットワーク全体を網羅するリストではありません。LAN、VPN、リモートワーク用ネットワークに合わせて調整し、プロキシや専用トンネル経由でアクセスすべきアドレスまで一律に直接接続へ振り分けないようにしてください。

no-resolveの正確な意味

リクエストにドメイン名が含まれていても宛先IPがまだ取得されていない場合、IPルールの判定に必要なアドレスを確認するため、DNS解決が行われることがあります。no-resolve を付けると、そのIPルールの照合のためにDNS解決を開始しません。リクエストに宛先IPがすでに含まれている場合は、引き続き照合できます。

DNSを無効にする設定でも、接続中にドメインが一切解決されなくなる設定でもありません。
前のルールですでにDNS解決が行われていたり、DNSマッピングや受信接続から宛先IPが取得できたりする場合があります。
ドメインの解決結果を使ってIP範囲に一致させたい場合、このパラメーターを付けると、後続のルールに進むことがあります。

そのため、LAN内アドレスのルールには no-resolve を併用し、ネットワーク範囲を判定するためだけに外部ドメインを追加で解決する機会を減らすことがよくあります。DNS解決結果をもとに分類するルールでは、このパラメーターが本当に必要か事前に確認してください。

ルールは上から順に判定し、最初に一致した時点で終了

Clashのルールは、ドメインの長さやネットワーク範囲の大小に応じて自動で並べ替えられません。通常は設定リストの上から順に判定され、最初に一致したルールでポリシーが決まります。より具体的なルールを後ろに置くと、前にある広範なルールに先に一致してしまいます。

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

このリストでは、login.example.com は最初のルールに一致して直接接続され、cdn.example.com は2番目のルールに一致して拒否されます。それ以外のリクエストは、最後の直接接続ルールに振り分けられます。最初の2つのルールを入れ替えると、ログイン用ドメインもサフィックスルールで拒否されます。

例外・分類・フォールバックの順に整理する

個別の例外：単一のドメインやホストアドレスなど、特別な扱いが必要なものは、該当する広範なルールより前に配置します。
用途別の分類：ドメインサフィックス、ルールセット、地域やネットワークの分類を、意図した優先順位に沿って並べます。
最終フォールバック：MATCH をリストの末尾に置き、残りのトラフィックの出力先を明示します。

サブスクリプションにすでにルール一式が含まれている場合、追加ルールをファイルの末尾にそのまま追記しないでください。MATCH より後ろのルールは判定されません。クライアントに「先頭に追加」「末尾に追加」やオーバーライド機能がある場合は、編集画面に保存された行数だけでなく、最終的に結合された位置を確認してください。

RULE-SET：ルール内容と出力先を分けて管理

ドメインが増えてきたら、mihomoの rule-providers でルールセットを管理し、RULE-SET から参照できます。ルールセットにマッチ条件をまとめ、該当時の出力先はメイン設定で指定します。以下はローカルファイルを使う例です。まず構成を確認してから、リモート更新元を追加できます。

メイン設定：プロバイダーを定義してルールリストに追加

rule-providers:
  local-work:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-work.yaml

rules:
  - RULE-SET,local-work,DIRECT
  - MATCH,DIRECT

local-work はルールプロバイダー名です。参照時も同じ名前を指定してください。相対パスはコアの作業ディレクトリを基準とするため、ダウンロードフォルダーが基準とは限りません。モバイルOS版のFlClashでは、アプリのファイルアクセス権限にも制限されます。任意の場所にファイルを置くだけでコアから読み込めるとは限りません。

ルールセットファイル：マッチ条件のみを記述

payload:
  - DOMAIN,portal.example.com
  - DOMAIN-SUFFIX,example.net
  - IP-CIDR,192.168.50.0/24,no-resolve

これは behavior: classical と format: yaml に対応するファイル内容です。各項目に DIRECT やプロキシグループ名は記述しません。出力先はメイン設定の RULE-SET,local-work,DIRECT でまとめて指定します。通常の3要素ルールをそのままファイルにコピーしないでください。

behavior: domain はドメインの集合に使用します。内容の形式は、上記のclassicalの例とは異なります。
behavior: ipcidr はIPネットワーク範囲の集合に使用します。通常のドメインルールを混在させないでください。
HTTPタイプのプロバイダーを使う場合は、アクセス可能な url を設定します。また、interval: 86400 とすると、86400秒（24時間）ごとに更新できます。

ルールセットの更新とサブスクリプションの更新は別の処理です。サブスクリプション更新ではメイン設定を取得し、ルールプロバイダーの更新では対応するルールデータを取得します。ルールセットが読み込まれない場合は、まずプロバイダーのエラーログとファイル形式を確認してください。形式に問題のあるルールファイルは、サブスクリプションを何度更新しても修正されません。

FlClashで設定を確認・テストする：有効な設定と新しい接続を確認

カスタムルールが機能しているかどうかは、コアが実際に読み込んだ設定と接続記録で確認します。編集・オーバーライドの項目名はクライアントのバージョンによって異なる場合があります。まずFlClashの「設定」ページを開いて現在選択中の設定を確認し、その操作メニューで利用できる編集機能を調べてください。実際に表示される編集機能だけを使い、サブスクリプション更新後も変更を保持する方法は別途確認してください。

元の設定を保存：現在の設定をエクスポートまたはコピーし、元の出力モードとプロキシグループの選択状態を記録します。リモートサブスクリプションの更新で、直接編集した内容が上書きされることがあります。
少しずつルールを追加：まずドメインを正確に指定したルールを1つ追加し、関連する広範なルールと MATCH より前に配置します。既存の rules がある場合はリストに統合し、同じトップレベルキーを重複して作らないでください。
設定を適用してログを確認：保存後、クライアントの機能に従って設定を再読み込みします。解析エラー、存在しないポリシー、ファイル読み込みエラーが発生した場合は、アクセスをテストする前にエラーを解消してください。
新しい接続でテスト：開いているページや関連する接続を閉じてから、リクエストを再実行します。HTTP/2、HTTP/3、アプリの接続プールでは既存の接続が再利用されることがあり、ルールを追加しても既存接続の出力先は自動で切り替わりません。
接続詳細を確認：「接続」ページで、宛先ホスト、宛先IP、一致したルール、出力経路を確認します。表示される項目はバージョンによって異なるため、ログも参照してルールタイプとポリシー名を照合してください。

TUNはより多くのアプリ通信をコアに取り込み、ルールはコアに届いたリクエストを分類します。TUNを有効にしても、特定のルールの優先順位が上がるわけではありません。接続リストに対象のリクエストが表示されない場合は、ルーティングを変更する前に、通信の取り込み、アプリ独自のプロキシ設定、ルーティングを確認してください。

よくある記述ミス：症状から原因を特定

症状	よくある原因	対処方法
保存後に設定を読み込めない	全角カンマ、Tabによるインデント、存在しないポリシー名	半角の句読点とスペースによるインデントを使い、ログに示された行を確認する
ルールはあるのに一致しない	MATCHまたはより広範なルールの後ろに配置されている	個別の例外を関連ルールより前に移動する
メインページは直接接続されるが、リソースは別のポリシーを通る	ページが別のドメインを呼び出している	接続記録で画像、API、リソースのホスト名を確認する
ドメイン宛てのリクエストにIPルールが適用されない	宛先IPがまだ取得できず、no-resolveが設定されている	DNS解決の状態を確認するか、ドメインを正確に指定したルールを使う
サブスクリプション更新後にカスタム設定が消える	リモート設定によって編集内容が上書きされている	現在のバージョンが対応する永続化オーバーライドを使うか、設定を別途管理する
ルールセットの読み込みに失敗する	behavior、formatと実際の内容が一致していない	payloadの構造、ファイルパス、プロバイダーのログを確認する

ルールには一致するが、アクセスできない

ルールに一致したことは、振り分け判定が完了したことを示すだけで、対象サービスへの接続を保証するものではありません。直接接続はローカルネットワークとDNSに依存し、プロキシポリシーは選択したノードに依存します。また、REJECT は接続を明示的に拒否します。接続詳細に想定どおりのポリシーが表示されている場合は、同じルールを重ねるのではなく、出力経路を調べてください。

ルールを管理する際は、その例外が必要な理由をYAMLコメントに残し、定期的に不要になった項目を削除してください。正確なドメイン、小さなネットワーク範囲、明確なフォールバックルールを優先しましょう。クライアントの操作手順ははじめての設定を、ルール・プロキシグループ・TUNの仕組みはプロトコル解説をご覧ください。