V2Rayのルーティング設定方法：domain・ip・geositeのマッチ構文と優先順位

1. ルーティングルール：通信の出口を決める

サブスクリプションにはノードへの接続情報が含まれ、ルーティングはどの通信にそのノードを使うかを決めます。VMessやVLESSなどはノードの接続方式であり、ルーティングのマッチ用プレフィックスではありません。ノードをVLESSに変更しても、特定サイトの直接接続・プロキシ接続が自動で切り替わるわけではありません。

V2RayやXrayの一般的なルーティング設定では、routing.rules は順序付きの配列です。各ルールは宛先ドメイン、宛先IP、ポート、受信タグなどの条件を確認し、一致すると outboundTag で定義済みの出力を指定します。タグは設定内で付けた名前にすぎず、proxy や direct が自動的に用意されるわけではありません。

• ドメイン名がある場合：コアが www.example.com を取得できれば、ドメインルールを直接照合できます。
• IPアドレスしかない場合：宛先アドレスしかコアに渡されないと、ドメインルールに照合できる情報がないことがあります。ドメイン名を取得できるかどうかは、受信設定、スニッフィング、DNS設定によって異なります。
• 出力先の参照：ルールの outboundTag は、outbounds 内にあるいずれかの tag と一致させる必要があります。大文字・小文字も揃えてください。

2. domain・full・regexp：マッチ範囲に合わせて選ぶ

domain はルール内のフィールド名であると同時に、フィールド値に使うマッチプレフィックスでもあります。以下の文字列はすべて "domain": [...] 配列に指定します。URLのスキーム、パス、クエリパラメーターは含めないでください。ルーティングのドメイン判定は、ブラウザーのアドレス欄を照合するものではありません。

特定のホストだけをプロキシ経由にするなら full: を使います。サイト全体とサブドメインをまとめて扱うなら domain: を使います。プレフィックスなしの文字列は、部分一致が必要な場合に限って使い、完全なドメイン名の省略記法として使わないでください。また、domain:*.example.com のようには書けません。ここではワイルドカード構文は使えません。

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

上記3つの配列要素はOR条件です。いずれかのドメイン条件に一致すれば対象になります。正規表現では、ドットを文字として扱うために [.] を使うと、JSONのバックスラッシュエスケープによる混乱を避けられます。正規表現の \. を使う場合、JSON文字列では \\. と記述する必要があります。先頭の ^ と末尾の $ は、文字列全体をマッチ対象にするための記号です。

3. ip・geoip・geosite：IPアドレスとドメインの集合を使い分ける

ip フィールドにはIPアドレス、CIDR形式のネットワーク、geoip: の集合を指定します。domain フィールドにはドメインのマッチ条件と geosite: の集合を指定します。この2種類の集合は互換ではありません。geoip:cn はIPアドレスの地域分類を示し、中国語のWebサイトすべてを指すものではありません。geosite:cn はドメイン一覧であり、各ドメインが常に同じ地域のIPアドレスに解決されるとは限りません。

{
  "type": "field",
  "ip": [
    "192.168.0.0/16",
    "10.0.0.0/8",
    "geoip:private"
  ],
  "outboundTag": "direct"
}

この設定例はプライベートネットワーク宛ての通信を直接接続にします。先頭の2つのネットワークは geoip:private と重複する可能性があるため、通常は具体的なネットワークか集合のどちらかを選べば十分です。中国国内のドメインとIPアドレスの両方を直接接続にする場合は、ルールを2つに分け、片方に domain、もう片方に ip を指定してください。1つのルールに両フィールドを入れても、OR条件にはなりません。

• 同じフィールド内は通常OR条件：ip 配列には複数のネットワークを指定でき、そのうち1つに一致すれば対象になります。
• 同じルール内の異なる条件フィールドは通常AND条件：たとえば domain と port を組み合わせると、ドメインと宛先ポートの両方が条件を満たす必要があります。
• 集合の利用にはローカルリソースが必要：一般的な設定では geosite.dat と geoip.dat を読み込みます。指定したタグが存在しない、リソースのパスが違う、ファイルがないといった場合、コアの起動に失敗することがあります。
• 集合の内容は変わる：リソースを更新すると、ドメインやアドレスの分類が変わる場合があります。問題を調べる際はリソースの更新日も記録し、クライアントのバージョンだけで判断しないでください。

4. 先に一致したルールが適用：例外を先に、広いルールを後に

ルールは配列の順に評価され、最初に一致したルールで経路が決まります。条件がより具体的だからといって、自動的に優先されるわけではありません。先に domain:example.com を直接接続にし、その後に full:api.example.com をプロキシにすると、後者は前者に上書きされます。

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

この設定例では、まず特定ホストだけをプロキシにする例外を設定し、次にドメイン全体を直接接続にし、最後に残りのTCP・UDP通信をプロキシに送ります。ここに示すのは routing のみです。利用するには、proxy と direct という名前の出力先が必要です。どのルールにも一致しない場合、一般的には最初の出力先が使われます。タグ名だけからデフォルトの経路を判断しないでください。

1. 例外を明示する。ログイン用API、内部サービス、または特定の出口を使う必要があるドメインなどを指定します。
2. 集合ルールを追加する。内容を確認したうえで、geosite や geoip の分類を追加します。
3. フォールバックを決める。最後の汎用ルールまたは先頭の出力先を確認し、ルールから漏れた通信が意図せず直接接続されないようにします。
4. 生成後の順序を確認する。クライアントは既定ルールとカスタムルールをあわせて生成することがあります。画面上の一覧が、最終的な配列全体と同じとは限りません。

ポート条件もマッチ範囲に影響します。たとえばドメインルールに "port": "443" を加えると、宛先ポートが443の通信だけが対象になり、同じドメインへの80番ポートの接続には一致しません。サイト全体を同じ経路にしたい場合は、意図せずポート制限を加えないようにしてください。

5. domainStrategy：ドメインをいつIPアドレスに解決するか

ドメインルールが正しくても、IPルールに一致しないことがあります。原因の多くは名前解決のタイミングです。routing.domainStrategy はルーティングの照合時にドメインをアドレスへ解決するかを制御しますが、DNS問い合わせが必ずプロキシ経由になることを保証する設定ではありません。コアのDNS、出力先での名前解決、クライアントのDNS設定も個別に確認してください。

もう1つよく使われる値は IPOnDemand です。IPが必要なルールの照合時に、宛先ドメインの名前解決が行われることがあります。そのため、IPルールを前方に置くと、意図せずDNS問い合わせが発生する可能性があります。設定を選ぶ前に、ドメイン分類とアドレス分類のどちらを優先するか決めてからルールの順序を調整してください。strategyの切り替えだけで解決しようとしないことが大切です。

• ドメインを優先：full:、domain:、geosite: で要件を指定します。
• アドレス条件を追加：解決後のアドレスで判定する必要がある場合は、名前解決が許可されているか、DNSがどの結果を返したかを確認します。
• フォールバックに注意：IPIfNonMatch と最後の全件一致ルールを併用すると、ドメイン宛ての通信がフォールバックに直接一致し、IPで再照合されない場合があります。

6. v2rayNで検証：生成された設定と接続ログを確認

現在のルーティング設定をバックアップしてから、v2rayNのルーティング設定を開いてルールを編集します。デスクトップ版ではバージョンによって画面の項目名が異なる場合があるため、現在の画面に表示される「ルーティング設定」とルール編集画面を確認してください。この記事のJSONはV2Ray/Xrayコアの設定項目を示すもので、ドメイン一覧だけを受け付ける入力欄にそのまま貼り付けることはできません。

これらはポートの用途を示す数値であり、速度測定の結果ではありません。ポート443がすべてのWeb通信を意味するわけではなく、ポート53も暗号化DNS全般を含むものではありません。ポートで通信を振り分ける際は、実際の通信方式も考慮してください。ポート番号だけでアプリの用途を判断することはできません。

1. 入力形式を確認する。JSONでは半角の二重引用符を使い、コメントや末尾のカンマは入れません。コアのフィールド名は変更しないでください。
2. 使用中のコアを確認する。想定したコアが選択されていることと、クライアントが最終的に生成したルールの構文を確認します。別形式の設定項目を混在させないでください。
3. タグとリソースを確認する。outboundTag の参照先が存在するか、集合タグを読み込めるかを確認します。まずコアの起動エラーを解消してから、ルーティングをテストしてください。
4. 接続し直す。ルーティングを保存して適用したら、テスト対象アプリの既存接続を閉じ、新しいリクエストを送信します。接続が継続中の場合、ルール一覧を変更しても接続先は自動で切り替わりません。
5. アクセスログを確認する。確認できるログの詳細で、宛先ドメインまたはIP、宛先ポート、受信タグ、出力タグを確認します。必要に応じて一時的にログレベルを上げ、テスト後に元へ戻してください。

ドメインルールの検証では、少なくとも3種類の宛先を用意します。完全一致の例外 api.example.com、同じドメインの別ホスト www.example.com、そのドメインに属さない宛先です。前の2つで full: と domain: の違いを確認し、3つ目でフォールバックを検証します。例示用ドメインは境界の説明だけに使っています。接続テストには、利用権限があり、実際にサービスを提供しているドメインを使用してください。

7. よくある問題：ルールの上書き、宛先情報、集合のエラーを確認

安定して調整するには、まず特定ドメイン1つで出力先を検証し、次にサブドメインや集合へ対象を広げ、最後にIP条件とフォールバックを追加します。1回に変更する条件は1種類にし、元に戻せるルーティング設定を残してください。基本用語は用語クイックガイド、DNSとルーティングの連携をさらに調べる場合は応用設定をご覧ください。