ノードを追加済みで、通信の振り分けを調整したいデスクトップユーザー向けの記事です。まずドメインルールとIPルールの違いを確認し、具体的な例外を汎用ルールより前に配置して、最後にログで出口を検証します。例ではXray/V2Flyのルーティング設定の仕様を扱います。v2rayNのGUIは設定を生成するためのもので、カーネル用のJSON全体を単一ドメインの入力欄に貼り付けることはできません。
1. ルーティングルールは評価順が重要
システムプロキシはアプリのリクエストをv2rayNに渡すかどうかを決め、ルーティングルールはカーネルが受け取ったリクエストの出口を決めます。この2つは別の設定です。アプリがシステムプロキシを使わず直接通信している場合、ドメインルールを変更しても影響しません。TUNで通信を取り込む場合も、トラフィックが実際にカーネルへ届いているか確認してください。
Xray/V2Flyの通常のルーティングルールは、配列の先頭から順に評価され、最初に条件を満たしたルールで出口が決まります。「より具体的なルールが優先される」わけではなく、full:が自動的にdomain:より優先されることもありません。先頭のルールでdomain:example.comをプロキシに送る設定にすると、後続のfull:files.example.comによる直接接続の例外は適用されません。
| 配置位置 | ルールの目的 | 出口の例 |
|---|---|---|
| 先頭 | 特定ドメインへの例外やブロック対象 | direct / block |
| 中間 | サービスのドメイン、プライベートIP、地域別セット | proxy / direct |
| 末尾 | 残りのTCP・UDP通信に適用するフォールバック | proxyまたは用途に応じて直接接続 |
同じルール内のdomain配列に複数の項目を指定した場合、通常はいずれかに一致すれば条件を満たします。ip配列も同様です。一方、異なる条件フィールド同士はAND条件です。たとえば、ドメイン・宛先ポート・ネットワーク種別を同じルールに指定すると、3つすべての条件を満たした場合に一致します。どれか1つを満たせばよいという意味ではありません。
2. domain・full・regexpの書き方
ドメインルールにはホスト名を指定します。プロトコル、パス、クエリパラメーターは含めません。たとえばhttps://api.example.com:443/v1/statusにアクセスする場合、ドメイン条件にはapi.example.comを指定します。ポート443は別の条件で、パス/v1/statusはこの種のルーティングルールの対象外です。
| 書式 | マッチする範囲 | 間違えやすい点 |
|---|---|---|
domain:example.com | ルートドメインとそのサブドメインに一致 | api.example.comには一致しますが、notexample.comには一致しません |
full:api.example.com | 指定した完全なホスト名だけに一致 | v2.api.example.comには一致しません |
regexp:^api[0-9]+\.example\.com$ | 正規表現でマッチ | ドットはエスケープし、アンカーでドメイン全体を指定 |
example | タイププレフィックスがない場合は、通常の文字列として部分一致 | ドメインのサフィックス一致より範囲が広く、意図しない一致に注意 |
domain:はワイルドカード式ではありません。ドメイン全体を対象にする場合はdomain:example.comと指定し、domain:*.example.comとは書きません。特定のホスト名だけを別の出口にするならfull:を使い、規則的な番号付きホスト名をまとめて対象にする場合に正規表現を検討してください。
{
"type": "field",
"domain": [
"full:files.example.com",
"regexp:^api[0-9]+\\.example\\.com$"
],
"outboundTag": "direct"
}上の例はカーネル用JSONの一部なので、バックスラッシュは\\と記述しています。v2rayNの通常のドメイン入力欄では、バックスラッシュを1つにしてregexp:^api[0-9]+\.example\.com$と入力するのが一般的です。JSON用のエスケープをそのまま通常の入力欄に貼ると、正規表現の意味が変わることがあります。入力先がJSONエディターかルール欄か、先に確認してください。
まずfullで試し、必要に応じて範囲を広げる
サービス向けの例外を追加するときは、まず1つのホストにfull:を指定して出口を確認します。一致することを確認してからdomain:に変更し、パターンでのマッチが本当に必要な場合に限ってregexp:を使うと、振り分けミスの原因を特定しやすくなります。
3. ip・CIDR・geoipの使い分け
IP条件はipフィールドに指定します。単一アドレス、CIDR形式のネットワーク、geoip:セットが一般的です。ここで判定するのは宛先IPです。送信元デバイスのプライベートIPを宛先ルールに誤って指定しないでください。送信元による振り分けには別の条件を使い、宛先IPフィールドで代用することはできません。
{
"type": "field",
"ip": [
"192.168.50.0/24",
"203.0.113.10/32",
"2001:db8::10/128",
"geoip:private"
],
"outboundTag": "direct"
}192.168.50.0/24は、このIPv4サブネット全体を対象にします。203.0.113.10と2001:db8::10はドキュメント用の例示アドレスで、接続可能なノードではありません。実際の設定では、振り分けたい宛先ネットワークに置き換えてください。LANへの直接接続ルールには明示的なネットワークを指定し、必要に応じてgeoip:privateを追加します。
geoip:cnは読み込まれたIPデータセットに基づいて判定し、geoip:privateはそのデータセットで定義されたプライベートまたはローカルアドレス範囲に使用します。データセットの内容はデータファイルの更新に伴って変わるため、個々のセットを常に正確な地域判定として扱わないでください。特にCDN、複数地域で提供されるサービス、新たに割り当てられたネットワークでは、個別の例外が必要になる場合があります。
- 宛先がドメインの場合、IPルールが適用されるかどうかは、カーネルが宛先アドレスを取得できるか、またルーティングの名前解決ポリシーに左右されます。
- 宛先がすでにIPアドレスなら、IPルールに一致させるためだけにドメインを名前解決する必要はありません。
- 同じサービスがIPv4とIPv6の両方を使うことがあります。IPv4ルールだけでは、IPv6接続をカバーできません。
- プライベートな宛先をすべて直接接続にする前に、利用するネットワークの要件を確認してください。直接接続にしても、端末のファイアウォールを回避するわけではありません。
4. geositeデータセットとDNSポリシー
geosite:cnはドメインのセット、geoip:cnはIPアドレスのセットで、互いに置き換えることはできません。前者は「名前解決したIPが中国国内にある」ことを示すものではなく、後者も「そのドメインが中国国内のサービスに属する」ことを示すものではありません。サービスの分類にはドメインセットを、アドレスの分類にはIPセットを使い分けると、判断の混乱を減らせます。
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
}従来のXray/V2Fly設定でこれらのセットを参照するには、カーネルが該当するデータファイルを読み込める必要があります。一般的なファイル名はgeosite.datとgeoip.datです。セット名は実際に読み込んだデータの内容に従います。記事に記載された名前だけを根拠に、端末にその分類が存在すると判断しないでください。データがない場合やタグが存在しない場合、設定の読み込みに失敗することがあります。
| domainStrategy | ルーティング時の名前解決動作 | 確認ポイント |
|---|---|---|
AsIs | ルーティング段階では、IPルールへの一致判定のためにドメインを自動で名前解決しない | ドメインのリクエストがIPセットに一致しなくても、ルールの書式が間違っているとは限らない |
IPIfNonMatch | ドメインルールで一致しなかった場合、名前解決してから再度判定する | 先に一致した汎用ルールによって、追加の判定が行われないことがある |
IPOnDemand | 判定に宛先IPが必要な場合、ドメインを名前解決する | DNSが利用可能か、名前解決の結果が想定どおりか確認する |
特にIPIfNonMatchとフォールバックルールの関係に注意してください。最初にドメインを評価した際、末尾のnetwork: tcp,udpがすでにプロキシ出口に一致すると、先にあるgeoip:cnに一致しなかったことを理由に自動で再試行されることはありません。IPセットによる振り分けを使う場合は、名前解決ポリシーとデフォルト出口も含めて設計してください。IPルールを追加するだけでは不十分です。
5. プロキシ・直接接続・ブロックの設定例
次の例では、最初に特定のホストをブロックし、続いてファイル配信用ホストを直接接続にします。同じドメイン配下の他のリクエストはプロキシに送ります。LAN宛ては直接接続にし、残りのTCP・UDP通信はプロキシに送ります。ドメイン宛ての通信もIP条件で判定できるよう、例ではIPOnDemandを指定しています。使用前に、カーネルのDNS設定が利用できることを確認してください。
{
"routing": {
"domainStrategy": "IPOnDemand",
"rules": [
{
"type": "field",
"domain": ["full:telemetry.example.com"],
"outboundTag": "block"
},
{
"type": "field",
"domain": ["full:files.example.com"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"ip": ["192.168.50.0/24", "geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}これはrouting設定の一部であり、ノード設定全体ではありません。proxy、direct、blockは、実際のoutbounds内にあるtagと対応させる必要があります。タグは名前にすぎず、それ自体で出口が作られるわけではありません。直接接続には通常freedomアウトバウンド、ブロックには通常blackholeアウトバウンドを使い、プロキシ出口には既存のノードを指定します。
具体的な例外を優先
おすすめ単一ホストや明確なネットワークを汎用分類より前に置くと、変更範囲を確認しやすくなります。例外を追加したら、上位に先に一致するルールがないかだけ確認してください。
おすすめのケース：普段使いの振り分け設定があり、少数の例外を追加したい
プロキシをフォールバックにする
直接接続またはブロックのルールに一致しないリクエストをプロキシに送ります。対象範囲は明確ですが、プロキシノードがより多くの通信を処理するため、LAN宛ては事前に除外してください。
おすすめのケース：外部サービスの多くでプロキシが必要で、直接接続先のリストを管理できる
直接接続をフォールバックにする
明示したサービスだけをプロキシに送り、それ以外は直接接続にします。新しいサービスや指定漏れのドメインは自動でプロキシに送られないため、リストを継続的に更新する必要があります。
おすすめのケース：プロキシ対象が少数で安定しており、ほかの通信は直接接続が中心
どのルーティングルールにも一致しない場合、Xray/V2Flyは通常、アウトバウンド一覧の先頭にある出口を使用します。この動作を「必ず直接接続される」と考えないでください。v2rayNが設定を生成する際にアウトバウンドの順序を変更することがあるため、実際の設定を確認するか、現在の名前解決ポリシーに合った明示的なフォールバックルールで意図を示してください。
6. v2rayNでルールを追加して動作確認する
作業を始める前に、現在のルーティング設定をバックアップしてください。以下では「設定」→「ルーティング設定」から開くv2rayNデスクトップ画面を例にします。マルチプラットフォーム版やクラシック版では、ボタンの位置が異なることがあります。ルーティング設定を編集したうえで、メイン画面から対象のルート設定を有効にしてください。ルールを保存しただけで設定を選択していないことは、「反映されない」原因としてよくあります。
-
設定をバックアップ
「設定」→「ルーティング設定」を開き、まず現在の設定とルールの順序をエクスポートするか、記録してください。元の設定は残し、テスト用に新しい設定を作成すると、日常の振り分け全体を一度に壊すリスクを避けられます。
-
ルールを開く
「ルーティング設定」で変更する設定を選び、ルール編集画面を開きます。ルールを追加する際は先に出口を選択し、ドメイン欄に
full:files.example.comを入力します。JSON全体を貼り付けないでください。 -
ルールの順序を調整
特定ホスト向けの例外を、
domain:example.comなどの広範囲なルールより前に移動します。ドメインとIPは別々のルールにしてください。複数の値は画面に表示される区切り方法に従って入力し、カンマで分割されると決めつけないでください。 -
設定を有効化
保存したらメイン画面のルート選択から、編集した設定を選びます。カーネルが設定を再読み込みしたことを確認してください。ログに設定エラーが表示された場合は、ルールを追加し続けず、まずバックアップに戻してください。
-
出口を確認
例のドメインを、テストする権限のある実際のホスト名に置き換え、新しい接続を開始してからカーネルログを確認します。アクセスログを有効にしている場合は、宛先とアウトバウンドタグを確認してください。Webページが開けたことだけを根拠に、直接接続されたと判断しないでください。
ルーティングは通常、接続時に決まります。ブラウザーの既存の持続接続では、変更前の出口が使われ続けることがあります。ルールを保存したら、テスト対象サイトの接続を閉じるかテスト用アプリを再起動し、もう一度アクセスしてください。古いページを一度更新しただけでルールの失敗と判断しないでください。ログに今回のリクエストがない場合は、正規表現を書き直す前に、システムプロキシ、アプリ側のプロキシ設定、TUNによる通信の取り込みを確認してください。
- まず構文を確認：プレフィックスの綴り、正規表現のエスケープ、セット名、出口タグを確認し、カーネルが正常に起動することを確かめます。
- 次に宛先を確認：実際のリクエストで使われるホスト名を特定します。Webサイトのメインドメイン、ログイン用ドメイン、ダウンロード用ドメインがそれぞれ異なる場合があります。
- 最後に順序を確認：ルールの先頭から、最初に一致する可能性のあるものを探します。特に汎用ドメインセットとフォールバックルールを確認してください。
7. カスタムルーティングのよくある質問
fullを指定してもプロキシ経由になるのはなぜ？
まず「設定」→「ルーティング設定」で、現在有効な設定を確認します。次に、この完全一致ルールを汎用ドメインルールより前に移動してください。既存の接続を閉じて再テストし、リクエストが別のダウンロード用またはログイン用ホスト名に送られていないかも確認します。
geosite:cnとgeoip:cnは両方設定する必要がありますか？
機械的に両方を追加する必要はありません。両方の判定が必要な場合は、ドメインセットとIPセットを別々のルールに指定してください。また、ルーティングの名前解決ポリシーも確認しましょう。ドメイン宛てのリクエストがIPセットの判定対象にならない場合があります。
特定のHTTPSパスだけを直接接続にできますか？
ここで紹介しているドメインルールでは、暗号化されたリクエストのURLパスに基づく振り分けはできません。ホスト名全体で振り分けるか、必要な場合は宛先ポート443を条件に追加してください。ただし、ポート条件を使っても同じホスト上の異なるパスは区別できません。
geositeを追加したらカーネルが起動しなくなったのはなぜ？
まず起動ログに、データファイルの欠落やセットの不存在を示すメッセージがないか確認します。クライアントのルーティングデータ更新機能を使ってデータを更新し、現在のカーネルのデータ参照先も確認してください。一時的にfull:ルールへ置き換えて設定を検証し、セット名を適当に変更しないでください。
サブスクリプションの更新でカスタムルールは変わりますか？
ノードのサブスクリプションとルーティング設定は別の設定ですが、ノード、カーネル、ルーティングプリセットを切り替えると生成される設定が変わる場合があります。更新後は現在のルーティング設定と出口タグを確認してください。ノードのサブスクリプションURLをドメインルール欄に貼り付けないでください。
振り分けの問題は、「リクエストがカーネルに届く → 宛先情報を取得できる → 最初に一致するルールを確認 → 対応する出口が存在する」の順で調べます。ドメインの書式は宛先を指定し、名前解決ポリシーはIP情報を補い、ルールの順序が優先度を決めます。一度に変更するのは1か所にし、元に戻せる設定を残しておくと、プリセット全体を何度も切り替えるより原因を特定しやすくなります。