V2Ray カスタムルーティングルール構文解説：domain・ip・geosite の判定順

ルーティング処理の流れと最初の一致の原則

V2Ray と Xray のルーティングモジュールはノード接続を確立するものではありません。リクエストがコアに入ると、対象ドメイン、対象 IP、ポート、ネットワーク種別、インバウンドタグなどをもとにアウトバウンドを選択します。最終的な選択先は通常、proxy、direct、block など、定義済みアウトバウンドを指す outboundTag で決まります。

ルールは routing.rules 配列に格納され、コアは先頭から順に確認します。あるルールの条件をすべて満たすと走査は直ちに終了し、その後のルールは今回のリクエストには適用されません。そのため、「具体的なルールを前に、広いルールを後ろに」が安定した設定の基本です。

同じルール内の異なるフィールドは通常「かつ」の関係です。たとえば domain と port を同時に指定した場合、対象はドメイン条件とポート条件の両方を満たす必要があります。一方、1つのフィールド内に複数の項目を指定した場合は通常「または」の関係です。たとえば domain 配列に3つのドメインを並べると、そのいずれか1つに一致すればフィールドの条件を満たします。

domain：完全一致・サブドメイン・キーワードによるマッチング

domain フィールドは対象ホスト名を処理します。よく使うプレフィックスは full:、domain:、keyword:、regexp:、geosite: です。プレフィックスによって一致範囲が決まるため、選択を誤ると対象範囲が広すぎたり、まったく一致しなかったりします。

full:example.com は完全なホスト名 example.com だけに一致し、www.example.com は同じ対象として扱いません。一方、domain:example.com はそのドメインとサブドメインに一致するため、同じサイト群を同じアウトバウンドへ振り分けるのに適しています。

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

• full: ログイン API や更新 API など、ホスト名が明確な対象に適しています。一致範囲が最も狭い形式です。
• domain: メインドメインとすべてのサブドメインに適しており、日常的なルールでよく使われる形式です。
• keyword: 対象ドメインに指定文字列が含まれていれば一致する可能性があります。短いキーワードは無関係なドメインまで巻き込むおそれがあります。
• regexp: 構造は一定でも番号などが変化するドメインに適していますが、式が複雑になるほど保守コストが増えます。
• geosite: あらかじめ整理されたドメインカテゴリを参照し、サービス種別や地域単位でまとめて振り分けるのに適しています。

完全一致のドメインをカテゴリルールの例外にする場合は、完全一致のルールを前に置きます。たとえば先に full:download.example.com を直接接続へ向け、その後に domain:example.com をプロキシへ向けます。順序を逆にすると、ダウンロード用ドメインはサイト全体のルールに先に取り込まれます。

ip と geoip：アドレス範囲の一致とドメイン解決条件

ip フィールドには、単一アドレス、CIDR アドレス範囲、geoip: カテゴリを指定できます。単一の IPv4 アドレスは 198.51.100.20、ネットワーク範囲は 198.51.100.0/24 のように記述します。IPv6 のアドレス範囲も CIDR で表し、たとえば 2001:db8:1200::/48 のように指定します。

geoip:private は、LAN、ループバック、その他のパブリックネットワークではないアドレスの判定によく使われます。これらを直接接続ルールの前方に置くと、ローカルルーターの管理画面、LAN 上のファイルサービス、ローカルインターフェースがリモートプロキシへ送られるのを防げます。

{
  "type": "field",
  "ip": [
    "geoip:private",
    "192.0.2.0/24",
    "2001:db8:1200::/48"
  ],
  "outboundTag": "direct"
}

IP ルールで、もともとドメイン名で開始されたリクエストを処理できるかどうかは、domainStrategy にも左右されます。対象にドメイン名しかなく IP がない場合、コアはそのドメインを解決するかどうかを判断し、解決結果を ip ルールと照合します。

geosite と geoip の違い

geosite はドメインの集合で、geoip は IP アドレスの集合です。両者は異なる段階の情報分類を扱うため、相互に置き換えることはできません。サイトが動的アドレスや共有クラウドサービスを使っていたり、名前解決の結果を頻繁に変更したりする場合は、固定 IP 範囲よりもドメイン集合のほうがサービスの所属を表しやすいことがあります。

geosite:cn ルールは、対象ドメインが対応するカテゴリに含まれるかどうかで判定します。一方、geoip:cn ルールは、対象 IP が対応するアドレス集合に含まれるかどうかで判定します。ドメインとサーバーの所在地は必ずしも一致しないため、同じ接続に対して異なる分類結果になる場合があります。

データファイルは、コアのバージョンと設定で利用できる機能に適合している必要があります。「failed to load geosite」やカテゴリ名を認識できないエラーが出た場合は、まずデータファイルがコアの実際の読み込み先にあるか確認し、次にカテゴリ名が存在するか確認します。ルールの順番を変えるだけでは、データファイルの欠落は直りません。

outboundTag と完全なルール構成

outboundTag の値は、outbounds 配列内にあるいずれかのアウトバウンドの tag と完全に一致している必要があります。大文字・小文字の違いも別名として扱われます。ルールを "outboundTag": "direct" と記述する場合、設定内に direct というタグのアウトバウンドが存在しなければなりません。

典型的な順序は、プライベートアドレスの直接接続、具体的な例外、カテゴリによる振り分け、フォールバック処理の4層に分けられます。特定のドメインやポートに関わるブロックルールは、それを覆う可能性のある広範なプロキシルールより前に置きます。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:updates.example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

1. 1つ目は LAN とローカルアドレスを処理し、内部サービスがプロキシ経路へ入るのを防ぎます。
2. 2つ目は明確な例外を定義し、指定した更新用ドメインを常に直接接続にします。
3. 3つ目はドメイン集合を使って分類済みサイトを処理し、IP の分類を待つ必要をなくします。
4. 4つ目はドメインルールで対象外だった場合に、解決後のアドレス集合で補足判定します。
5. 一致しなかったリクエストは設定のデフォルト経路を使い続け、実際の出口は完全なアウトバウンド構成によって決まります。

設定でロードバランサーを使う場合、ルールは単一のアウトバウンドを直接指定せず、balancerTag でロードバランサーを参照することがあります。通常のカスタム振り分けでは outboundTag を優先し、セレクターとロードバランサーを実際に設定している場合だけ balancerTag を導入すると、不要な切り分け階層を増やさずに済みます。

v2rayN の設定場所と検証手順

v2rayN 7.x では、まず「設定」→「ルーティング設定」を開き、現在のルーティング設定とプリセットルールを確認します。小さなバージョン違いでボタンの位置が変わる場合はありますが、確認すべき点は同じです。現在有効なルーティング設定、ルールの並び順、最終的に生成されたコア設定が一致しているかを確認してください。

変更後は、ブラウザーでウェブページを開けるかだけを見ないでください。ブラウザーキャッシュ、DNS キャッシュ、既存接続の再利用が結果を隠すことがあります。コアを再起動し、新しい対象への接続を使い、ログレベルを一時的に info または debug にしてルーティング記録を確認します。

1. 「設定」→「ルーティング設定」で現在選択されているルールセットを確認し、想定される一致ルールの位置を記録します。
2. ルールの outboundTag を確認し、生成された設定の outbounds[].tag と一字ずつ照合します。
3. 「設定」→「パラメータ設定」でローカルリスニングとログ関連の項目を確認します。よく使われる SOCKS ポートは 10808、HTTP ポートは 10809 です。
4. 設定を保存してコアを再起動し、既存のブラウザー接続を閉じるか、新しいテストドメインを使用します。
5. ログに記録された対象ドメイン、対象アドレス、アウトバウンドタグを確認し、どのルールでリクエストの走査が止まったかを判断します。
6. 一度に移動または変更するルールは1つだけにし、再テストしてから次の箇所を扱います。複数の変更が互いに影響するのを防げます。

チェックリスト
1. 対象はドメインか IP か
2. domainStrategy は名前解決を実行するか
3. 完全一致ルールはカテゴリルールより前にあるか
4. outboundTag は存在し、大文字・小文字も一致しているか
5. geosite と geoip のデータは正常に読み込まれているか
6. テスト接続は変更後に作成した新しい接続か

ルールが効かないときのよくある切り分け Q&A

ルーティングの問題は、単純な構文エラーではなく、対象形式、名前解決の方針、並び順、アウトバウンドタグが組み合わさって起きることが多いです。まずログに実際に現れている対象を確認し、その後ルール条件と照合するほうが、いきなり一致範囲を広げるより確実です。

最終的な設定では、各ルールの目的を読み取れる状態に保ちます。1つのルールで1つの明確な意図を処理し、タグ名は出口の用途を表し、例外ルールは対象の直前に置きます。ルールが増えた後も、明確な順序と最小限の条件のほうが、キーワードを積み重ねるより長期的に保守しやすくなります。