ルールモードと有効な設定を確認する

特定のドメインを常に直接接続するには、クライアントの動作モードを「ルール / Rule」に切り替え、カスタムルールを既存のrules:リストの先頭付近に追加します。保存して設定を再読み込みしたら、接続一覧を開き、そのドメインに適用されたルールと最終的な出力先を確認してください。グローバルモードでは全体のポリシーに従って転送され、直接接続モードではすべて直結するため、どちらもここで説明する振り分け順序の検証には適していません。

Clashはクライアントやコアのエコシステムで広く使われる名称です。Clash Metaは後にmihomoという名称になりました。この記事で扱うドメインルール、CIDRルール、順序による評価は一般的な設定機能ですが、ルールセットの形式や追加のルールタイプは実際に使用するコアによって異なります。クライアントの画面とコアは別のものです。トラブルシューティング時は「バージョン情報」やコア情報の画面で、実行中のコアを確認してください。

  1. 現在有効な設定を開き、まず元ファイルをバックアップするか、設定をエクスポートします。
  2. 既存のポリシーグループ名（例：代理選択）を確認します。大文字・小文字、スペース、文字表記も正確に合わせてください。
  3. クライアントに用意されているオーバーライド、マージ、カスタムルールの機能から、必要最小限のルールを追加します。
  4. 再読み込み後、有効な設定を開き、追加したルールがエディターに保存されているだけでなく、実際にrulesへ反映されていることを確認します。

基本構文：タイプ、マッチ対象、出力先

一般的なルールはタイプ,マッチ対象,出力先の形式です。出力先にはDIRECTやREJECTなどの組み込み値のほか、現在の設定にあるプロキシノードやポリシーグループを指定できます。MATCHにはマッチ対象が不要で、MATCH,出力先と記述し、通常は最後のフォールバックとして配置します。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,代理選択

これは既存のルールリストを置き換える、またはマージするための例です。デフォルト設定には代理選択というポリシーグループが定義されている前提です。既存のグループ名がProxyなら、実際の名前を指定してください。この例を単独で貼り付けても、ポリシーグループやプロキシノードは作成されません。例にある予約ドメインはマッチ範囲を示すためのものです。実際に設定する際は、制御したいドメインに置き換えてください。

タイプマッチ範囲用途
DOMAIN完全一致するドメイン特定のAPIやログイン先だけを振り分ける
DOMAIN-SUFFIXドメインとそのサブドメインドメイン全体をまとめて処理する
DOMAIN-KEYWORDドメインに指定した文字列を含む場合広めのマッチ範囲を許容できる場合
IP-CIDR指定したIPv4アドレス範囲LAN内のネットワークや固定サービスアドレス
RULE-SET定義済みのルールプロバイダーを参照する多数のドメインやネットワーク範囲をまとめて管理する
MATCH前のルールにマッチしなかった接続リスト末尾のデフォルト出力先

DOMAIN-SUFFIXは任意の文字列末尾に一致するルールではない

DOMAIN-SUFFIX,example.com,DIRECTはexample.comとimg.example.comにマッチしますが、notexample.comにはマッチしません。*.example.comと書く必要はありません。また、ドメイン欄にhttps://、ポート番号、パスを指定しないでください。ルールが照合するのは接続先の情報であり、ブラウザーのアドレスバーに表示される完全なURLではありません。

api.example.comだけを対象にするなら、DOMAINを使うと範囲を限定しやすくなります。一方、DOMAIN-KEYWORD,example,DIRECTでは、同じ文字列を含む別のドメインまでマッチする可能性があります。ログイン、決済、社内システムに関するルールは、まず完全一致で指定し、必要に応じて範囲を広げましょう。

マッチの優先順位：上から順に評価し、最初の一致で決定

通常のrulesリストは記述した順に評価され、一般に最初に一致したルールで出力先が決まります。すべての結果を集めてから「より具体的なルール」を自動選択するわけではありません。ドメインルールがIPルールより常に優先されるわけでも、完全一致のドメインルールが自動的にサフィックスルールより先に評価されるわけでもありません。優先させたい例外はリストの前に記述してください。

rules:
  - DOMAIN,api.example.com,代理選択
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,代理選択

この順序では、api.example.comは代理選択を使い、www.example.comは直接接続します。先頭の2つのルールを入れ替えると、APIドメインが先にサフィックスルールに一致し、後ろの完全一致ルールは評価されません。設定の読み込みには成功したのに通信経路が変わらない場合によくある原因です。

カスタムルールを配置する位置

  • 個別の例外は汎用ルールより前に：特定ドメインだけ出力先を変えるルールは、ドメイン全体を対象にするルールより前に配置します。
  • カスタムの修正ルールは関連するサブスクリプションルールより前に：サブスクリプションのルールセットが対象ドメインをすでに処理している場合、後ろに追加しても通常は結果を変えられません。
  • フォールバックルールは末尾に：MATCHで処理された接続は、その後にある通常のルールでは評価されません。
  • 安全性を明確に保つ：先頭に置いた直接接続ルールが、サブスクリプション内のブロックルールを回避することもあります。許可が必要だと確認できたドメインだけ例外にしてください。

つまり、「カスタムルールをサブスクリプションのルールより前に置く」とは、ルールの適用順を調整する方法であり、すべてのカスタムルールを無条件にリストの最上部へ置くという意味ではありません。先に適用すべきブロックルールやローカルネットワークのルールがある場合は、実際の要件に合わせて並べます。追加した数行だけでなく、有効なルールリスト全体を確認してください。

IP-CIDRとno-resolve：ルール評価時の名前解決を制御

IP-CIDR,192.168.50.0/24,DIRECT,no-resolveは、指定したIPv4ネットワークをマッチ条件にして直接接続するルールです。/24はネットワークプレフィックス長を表します。単一のIPv4アドレスには/32、単一のIPv6アドレスには/128を指定できます。ここに指定するのは接続先アドレスであり、自分の端末の送信元アドレスではありません。

接続先がまだドメイン名の場合、コアは宛先IPを必要とするルールの評価時に、一致するか確認するためDNS名前解決を行うことがあります。no-resolveは、このIPルールの評価だけを目的とした名前解決を抑止します。「DNSを無効にする」という意味ではなく、この接続を必ず直接接続にするものでもありません。後続ルールの評価や、実際の接続確立に必要な名前解決も妨げません。

  • 接続先がすでにIPアドレスの場合や、コアが実際の宛先IPを取得済みの場合は、そのアドレスに対してネットワーク範囲のマッチ判定を行えます。
  • 接続先がドメイン名で、まだ利用可能なIPアドレスがない場合、no-resolve付きのIPルールは、通常マッチ判定のために名前解決を行いません。その接続は後続のルールへ進みます。
  • LAN内のアドレスや、明示的にIPアドレスを直接接続したい場合にこのパラメーターが役立ちます。ドメインの名前解決結果をもとにネットワーク範囲を判定したい場合は、パラメーターを外したときのDNS動作も確認してください。

社内ネットワークのサービスを例にすると、アプリが192.168.50.10へ直接アクセスする場合、上記のネットワークルールで簡単に確認できます。該当IPに解決される社内ドメインへアクセスする場合は、まずそのドメインを直接接続するルールを追加し、社内ドメインをDNSで解決できることを確認してください。経路の選択とDNSの到達性は別の問題です。DIRECTを指定しただけでは、誤ったDNSサーバーは修正されません。

RULE-SETの書き方：プロバイダーの定義とルールの参照

ルールが多い場合は、rule-providersでルールプロバイダーを定義し、RULE-SET,プロバイダー名,出力先で参照できます。プロキシノードを提供するproxy-providersとは用途が異なります。ここではmihomoのローカルYAMLドメインルールセットを例に、ファイルを準備してからメイン設定に追加します。

手順1：ローカルのドメインルールファイルを作成する

コアが読み込める設定ディレクトリ内にrules/local-direct.yamlを作成します。プロバイダーの定義がbehavior: domainなので、ファイルにはpayloadを使います。ここにはドメインのマッチ条件だけを記述し、DOMAIN-SUFFIXのタイプや出力先は指定しません。

payload:
  - 'example.com'
  - '+.example.org'

ここでのexample.comはドメインの完全一致、+.example.orgはドメイン本体とそのサブドメインを表します。ルールセットのドメイン表記と、メイン設定のDOMAIN-SUFFIX構文は異なる階層の記述です。同じ形式をそのまま混在させないでください。

手順2：プロバイダーを定義して参照する

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,代理選択

local-directは、定義と参照で完全に同じ名前にする必要があります。相対パスはコアの作業ディレクトリを基準に解釈され、編集中のサブスクリプションファイルと同じ場所とは限りません。読み込みに失敗した場合は、コアのログで実際のパスとアクセス権を確認してください。type: fileはローカルファイルを読み込む設定であり、ネットワークから自動的にダウンロードするものではありません。

behavior: classicalを使う場合、ルールセットの各項目にDOMAIN-SUFFIX,example.orgのようなルールタイプを付けます。ただし、出力先は記述せず、外側のRULE-SETで指定します。ルールセット内の各条件は、メインリストで参照した位置にまとめて評価され、特別な優先順位が付くわけではありません。参照をMATCHの後に置いても、振り分けには使えません。

動作確認とトラブルシューティング：マッチしたルールと出力経路を確認

一度に追加するルールは1～3件にとどめ、まず設定の構文を検証してから再読み込みします。YAMLのインデントにはスペースを使い、タブは避けてください。すでにrules:がある場合は、リストに直接追加し、ファイル末尾に同じトップレベルキーをもう一度書かないでください。キーの重複によって前の内容が上書きされたり、解析エラーになったりすることがあります。

  1. 通信がコアに届いているか確認する。ブラウザーがシステムプロキシを使っているか、アプリにプロキシが明示的に設定されているか、またはTUNで対象の通信が取り込まれている必要があります。コアに届かない接続には、これらのルールは適用されません。
  2. テストするポートを確認する。有効な設定のmixed-portが7890なら、次のコマンドでローカルHTTPプロキシを明示的に経由できます。実際のポートが異なる場合は、コマンドも同じ値に変更してください。
  3. 新しい接続を確認する。接続一覧で対象ドメインを検索し、詳細を開いてルールタイプ、マッチした内容、出力経路を確認します。すでに確立している長時間接続は以前の経路を使い続けることがあるため、該当する接続を閉じてから再試行してください。
  4. ポリシーグループと最終ノードを区別する。代理選択にマッチしたことは、そのグループに振り分けられたことを示すだけです。グループ内で現在DIRECTが選ばれていれば、最終的には直接接続されます。
curl --proxy http://127.0.0.1:7890 --head https://example.com

このコマンドは、ローカルプロキシを明示的に経由するテストリクエストを送るためのものです。HTTPステータスコードだけで振り分けの成功を判断することはできません。クライアントでマッチしたルールも確認してください。ドメインがリダイレクトを返す場合や、ブラウザーのページが複数の異なるドメインへリクエストする場合は、制御したい接続を個別に調べる必要があります。

よくある3種類のトラブル：確認する順番

  • 設定を読み込めない：インデント、カンマ、ポリシーグループ名、RULE-SETが参照するプロバイダーの定義を確認します。まずログの最初のエラーを確認してください。
  • 読み込みに成功したがルールにマッチしない：動作モード、ルールの順序、実際のリクエスト先ドメイン、有効な設定を確認します。接続情報にIPアドレスしかない場合、ドメインルールがマッチするかどうかは、コアがドメイン情報を保持しているかにも左右されます。
  • ルールにマッチするが接続できない：DNS、選択中のノード、接続先サービス、ローカルのルーティングを確認します。ルールにマッチしたことが示すのは経路が選択されたことだけで、その経路で実際に通信できるとは限りません。

TUNを使用している場合、一部のシステム通信、LANアクセス、設定で除外されたルートは、想定した経路に入らないことがあります。また、アプリ内蔵のプロキシが通信の入口を変えることもあります。まずプロキシを明示するコマンドでルール自体を確認し、その後ブラウザーや対象アプリで通信の取り込み範囲を検証すれば、「ルールの記述ミス」と「通信がコアに届いていない状態」を切り分けられます。

検証が完了したら、サブスクリプションをもう一度更新し、ルールが保持されていることを確認します。安定した運用には、ローカルオーバーライドで例外を保持し、サブスクリプションで汎用ルールを管理し、末尾に明確なフォールバックを置く方法が有効です。変更のたびに接続記録で結果を確認してください。設定項目や通信の取り込み方法については、詳細設定またはヘルプセンターもご覧ください。