V2Rayのカスタムルーティング設定｜domain・ip・geositeの書き方と優先順位

ルーティングの優先順位：最初にマッチしたルールが適用される

V2RayとXrayの通常のルーティングルールは、routing.rules配列の先頭から順に確認されます。ルールにマッチすると指定されたアウトバウンドが使われ、それ以降のルールは確認されません。つまり、より具体的なドメインを広範な分類ルールの後に書いても、自動的に優先されるわけではありません。例外ルールは前に配置してください。

同じルール内のdomain配列に複数の項目がある場合、通常はいずれか1つにマッチすれば条件を満たします。一方、異なる条件フィールドは通常「かつ」の関係です。domainとportを指定すると、ドメインと接続先ポートの両方が一致する必要があります。ドメインとIPを同じルールに書いても、「どちらか一方に一致すれば適用」という意味にはなりません。

以下は「指定したホストの443番ポートだけをプロキシ経由にする」コアのルールです。ここでのproxyはアウトバウンドのタグであり、組み込みキーワードではありません。設定全体に同じタグのアウトバウンドが必要です。また、ノードの表示名でもないため、サブスクリプションにあるノード名へ確認せず置き換えないでください。

{
  "type": "field",
  "domain": ["full:portal.example.com"],
  "port": "443",
  "outboundTag": "proxy"
}

domain・full・regexp：ドメインの書き方とマッチ範囲

domainはルールのフィールド名で、domain:はフィールド値に使うマッチ用プレフィックスです。両者は異なる階層にあります。正しいフィールド表記は"domain": ["domain:example.com"]です。fullやregexpを、domainと並ぶルールフィールドとして扱わないでください。

特定サイトだけに例外を設定するならfull:、ルートドメインとすべてのサブドメインを同じ経路にするならdomain:を使います。正規表現は、ホスト名に明確な規則性がある場合に限って使用してください。ドメイン項目にはhttps://、パス、クエリパラメーターを含めないでください。ルーティングが判定するのは接続先のホスト名であり、ブラウザーのアドレスバーに表示される完全なURLではありません。

{
  "type": "field",
  "domain": [
    "full:portal.example.com",
    "domain:static.example.net",
    "regexp:^api[0-9]+\\.example\\.com$"
  ],
  "outboundTag": "proxy"
}

この配列の3項目は、それぞれ代替条件です。api12.example.comへのアクセスは正規表現で、img.static.example.netへのアクセスはドメインのサフィックスでマッチします。JSON内の\\.は、解析後に正規表現の\.になります。エスケープが1段足りないと、設定を読み込めないことがあります。

ip・geoip・geosite：IP範囲と分類データを使い分ける

ip配列には接続先IPの条件を指定し、単一アドレス、CIDR範囲、geoip:分類を記述できます。geosite:はドメイン条件なので、domain配列に記述します。この2種類の分類プレフィックスを入れ替えても、ドメインとアドレスの両方を使った想定どおりのルーティングにはなりません。

{
  "type": "field",
  "ip": [
    "192.168.10.0/24",
    "10.0.0.8/32",
    "geoip:private"
  ],
  "outboundTag": "direct"
}

• 単一デバイス：10.0.0.8/32はこのIPv4アドレスだけにマッチします。単一のIPv6アドレスには/128を指定できます。
• ネットワーク全体：192.168.10.0/24はこのIPv4アドレス範囲にマッチします。対象が明確なローカルネットワークに適しています。
• IPアドレスの分類：geoip:cnはIPアドレスデータベースを参照します。特定サイトの運営地域と一致するとは限りません。
• ドメインの分類：geosite:cnはドメインデータベースを参照します。新しいドメインが未登録の場合、サイトが中国語に対応していても自動的にマッチするわけではありません。

ウェブサイトが複数のコンテンツ配信ネットワークを使っていたり、同じドメインでもネットワーク環境によって異なる地域のIPに名前解決されたりすることがあります。ドメイン分類とIP分類で異なる経路が選ばれても、必ずしもルールの不具合とは限りません。「このサイトへの接続を常にプロキシ経由にする」のか、「このIP範囲を直接接続にする」のかを確認し、条件を選んでください。

domainStrategy：ルーティング時にドメインを名前解決するタイミング

routing.domainStrategyは、ルーティング時にドメインとIPのルールをどのように扱うかを指定します。DNSサーバーのアドレスでも、アウトバウンド接続時のアドレス選択方式でもありません。以下の3つはV2Ray/Xrayで一般的なルーティング設定の値です。具体的な動作は、実行中のコアのバージョンで確認してください。

アプリが先にドメインを名前解決し、IPアドレスだけをプロキシに渡すと、コアから元のドメインが見えない場合があります。一部のプロトコルではトラフィックのスニッフィングでドメイン情報を補えることがありますが、すべての接続で有効とは限りません。有効にする場合も、「ルーティングにのみ使う」設定と「接続先を書き換える」設定の違いを確認してください。スニッフィングを有効にすればドメインルールが必ず適用される、とは考えないでください。

ルーティング設定の全体例：特定ドメインの例外を分類ルールより前に置く

以下は、完全な設定に組み込むrouting部分のみを示した例で、単独で起動できる設定ファイルではありません。directとproxyの2つのアウトバウンドタグが設定済みであることを前提とします。ルールは、ローカルネットワークのアドレス、特定ドメインの例外、ドメイン分類、IP分類、最後にTCP/UDPのフォールバックの順です。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:portal.example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

この例で見落としやすいのは、最後のnetworkルールが通常のTCP/UDP接続を処理する点です。IPIfNonMatchでは、ドメインの接続がこのルールにマッチすると、それ以前のIP分類にマッチしなかったとしても、「どのルールにもマッチしなければ名前解決する」処理には進みません。したがって、この例のgeoip:cnが主に処理するのは、接続先IPがすでに指定されている通信です。残りすべてのドメインをIP分類する設定と捉えないでください。

• 明示的なフォールバックを残したい場合：ドメイン接続は主にドメインルール、IP接続は主にIPルールで振り分けられます。
• ドメインがマッチしない場合にIP分類を行いたい場合：すべての接続を先回りして処理するルールを削除し、デフォルトのアウトバウンドを確認してください。通常は、最初のアウトバウンドがデフォルトになります。
• IP条件に達した時点で名前解決したい場合：IPOnDemandを検討できますが、前方のIPルールと特定ドメインの例外との優先関係を必ず再テストしてください。

デフォルトのアウトバウンドは、クライアント画面で「現在選択中のノード」を見るだけで判断せず、設定全体で確認してください。v2rayNは実行用設定を生成するため、一時生成ファイルを手動編集しても、ノードの切り替えや再起動で上書きされることがあります。長期間使うルールはクライアントのルーティング設定に保存してください。

v2rayNのカスタムルーティング：ルールを1つずつ検証する

v2rayNはデスクトップクライアントで、実際の通信処理は選択中のコアが行います。以下の手順は「設定」→「ルーティング設定」の項目があるデスクトップ画面を対象としています。バージョンによってボタンの位置や項目名が異なる場合があります。編集前に現在のルーティング設定名を記録し、既存ルールを残しておくと、サブスクリプションのノードとルーティングの問題を切り分けやすくなります。

1. ルーティング設定を開く

   「設定」→「ルーティング設定」を開き、現在使用中の設定を記録します。例外ルールを追加する前に、既存のルールをエクスポートするかコピーして保存してください。

2. ドメイン条件を入力する

   ルール編集画面のドメイン条件にfull:portal.example.comを入力します。GUIの入力欄には通常、個々のルール項目を入力します。routingのJSON全体を貼り付けないでください。

3. 適用するアウトバウンドを選ぶ

   要件に合わせてプロキシまたは直接接続を選びます。コアのJSONを編集する場合は、outboundTagとoutbounds内のタグが一字一句一致していることを確認してください。

4. ルールを上へ移動して有効にする

   例外ルールをドメイン分類や広範なフォールバックより上に移動します。保存後、メイン画面のルーティング選択でこの設定を有効にしてください。保存しただけで、以前の設定を使い続けないように注意します。

5. テスト接続を作り直す

   テスト中のページを閉じ、既存の接続を切ってから新しいリクエストを送ります。コアのログで接続先ホスト、ポート、アウトバウンドタグを確認し、一度に変更する条件は1つだけにしてください。

検証では、実際のテスト対象ホストをfull:の例外として指定し、マッチを確認してからdomain:や分類へ広げると確実です。ブラウザーが接続を再利用すると、古い接続では以前の経路が使われるため、ページを再読み込みするだけでは新しい接続が作られないことがあります。コマンドラインツールで試す場合も、クライアント画面に表示されたローカルプロキシポートを明示してください。環境ごとにポートが同じとは限りません。

ルーティングルールが適用されないときの原因と確認方法

最後に、接続がコアに届いているか、コアが認識しているのはドメインかIPか、最初にマッチしたルールがどのアウトバウンドを指定しているかを確認しましょう。この3点を先に調べると、DNSの変更、コアの切り替え、サブスクリプションの再設定を同時に行うより、原因を特定しやすくなります。各フィールドの説明はプロトコルとコアのリファレンスを、用語の確認には用語集をご覧ください。