V2Rayのルーティングルール設定実践：中国本土は直結、日本国外はプロキシに分ける方法

振り分けの核心：リクエストごとに出力先を選ぶ

V2Rayのルーティングは別のプロキシプロトコルではなく、コアがリクエストを処理する際に使う判定条件の集合です。アプリのリクエストがローカルのSOCKS、HTTP、または透過プロキシの入口に入ると、コアは宛先ドメイン、宛先IP、ポート、ネットワーク種別を読み取り、routing.rulesの先頭から順番に照合します。最初に一致したルールが、どのoutboundTagを使うかを決め、後続のルールは実行されません。

一般的な設定では、3つの出力先タグを用意します。proxyはサブスクリプションのノードへ接続し、directは宛先へ直接アクセスし、blockは接続を拒否します。ルーティングルール自体はノードアドレスを保持せず、VMessやVLESSなどのノードパラメータも変更しません。既存の出力先へトラフィックを振り分けるだけです。そのため、クライアントから設定をエクスポートしたら、実際のタグ名を確認してからルールをコピーしてください。

「中国本土は直結、それ以外はプロキシ」という構成は、通常3段階の条件で実現します。プライベートアドレスを直結し、中国本土のドメインとIPを直結し、残りのTCP・UDPリクエストをプロキシへ渡します。最後のルールはフォールバックなので、必ずルール一覧の末尾に置きます。フォールバックのプロキシを先頭に置くと、すべてのリクエストが即座に一致し、後続の中国本土向け直結ルールは実行されません。

routing設定：geosite、geoip、フォールバックルール

geositeはドメインの分類データ、geoipはIPアドレス範囲の分類データです。ドメインリクエストはまずgeosite:cnで判定できます。ドメインルールに一致しない場合、domainStrategyをIPIfNonMatchにすると宛先アドレスを解決し、IPルールで判定します。ドメインでアクセスするアプリと、IPへ直接接続するアプリの両方に対応できる方法です。

以下の断片にはroutingオブジェクトだけが含まれています。既存の完全な設定に統合して使い、単独の設定ファイルとして起動しないでください。広告カテゴリのルールはblock出力先に依存します。現在の設定にその出力先がない場合は、最初のルールを削除し、直結とプロキシの振り分けだけを残してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainMatcher: hybridはドメインルールの照合に使います。一部の古いコアがこの項目を認識しない場合は、この行を削除してデフォルトのマッチャーを使えます。分類データもコアのバージョンに対応している必要があります。ログにデータセットが存在しないと表示され、設定の記述が正しい場合は、ノードの障害と決めつけず、クライアントが使用するコアとルールデータを更新してください。

v2rayNで適用する：サブスクリプションからカスタムルーティングまで

v2rayNはサブスクリプションを保存し、使用するノードを選択してコア設定を生成します。グラフィカルインターフェースでルーティングを管理すると、クライアントがコアの起動前にノードの出力先とルールセットを組み合わせるため、都度生成されるconfig.jsonを繰り返し編集するより安定します。一時ファイルはノードの切り替え、サブスクリプションの更新、クライアントの再起動後に再生成されることがあります。

1. ノードの接続を確認する。サブスクリプションを更新してノードを選択し、まず「サーバーへの実接続遅延をテスト」を使って接続を確立できることを確認します。ルーティングはトラフィックの振り分けを行うだけで、ノードのアドレス、ポート、認証パラメータを修正するものではありません。
2. ルーティング設定を開く。v2rayN 7.12.7で「設定」→「ルーティング設定」を開き、新しいルールセットを作成して、現在使用するルーティング設定に指定します。マイナーバージョンによってボタンの位置が変わる場合がありますが、ルーティング設定の入口名は変わりません。
3. 個別ルールを追加する。広告ブロック、プライベートIP直結、中国本土のドメイン直結、中国本土のIP直結の順にルールを作成します。出力先タグには、クライアントに存在するblock、direct、proxyを選び、ノードの表示名は入力しないでください。
4. 最終プロキシルールを追加する。ネットワーク種別をTCPとUDPに設定し、出力先をproxyにして、このルールを最下部へ移動します。最終フォールバックがない場合、一致しなかったリクエストはコアのデフォルト動作で処理されるため、結果を把握しにくくなります。
5. 保存してコアを再起動する。ルールを保存したらサービスを一度再起動し、ログウィンドウで設定の読み込みに成功したことを確認します。設定画面を閉じるだけで再起動しない場合、実行中のコアが古い設定を使い続けることがあります。

v2rayNGとv2flyNGにもルーティング設定がありますが、使用するコアの系統が異なります。v2rayNGは通常Xrayコア、v2flyNGはV2Flyコアと組み合わせて使います。基本的なfield、domain、ip、network、outboundTagのロジックは共通していますが、利用できる拡張項目は異なる場合があります。クライアント間で移行するときは、まず基本ルールを残し、コア固有の機能を一つずつ検証してください。

ルールの優先順位：具体的な条件を前に、広い条件を後ろに

ルーティングルールは上から順に照合し、最初に一致したルールを採用します。複数のルールを統合して最適な結果を計算する仕組みではありません。あるドメインがカスタムプロキシリストとgeosite:cnの両方に該当する場合、どちらへ送られるかは先に並んでいるルールで決まります。順序は「手動の例外、特殊カテゴリ、プライベートアドレス、地域分類、最終フォールバック」とすると整理しやすくなります。

特定のドメインを常にプロキシ経由にする場合は、カスタムルールをgeosite:cnより前に置きます。ドメインの照合形式にも違いがあります。full:は完全なホスト名だけに一致し、domain:はそのドメインとサブドメインに一致し、regexp:は正規表現を使います。通常の振り分けではfullまたはdomainを優先し、パターン判定が本当に必要な場合だけ正規表現を使ってください。

{
  "type": "field",
  "domain": [
    "full:status.example.net",
    "domain:service.example.net"
  ],
  "outboundTag": "proxy"
}

逆に、特定のダウンロードサイトを常に直結したい場合も、専用のdirectルールを作り、最終プロキシルールより前に置きます。一つの例外のためにgeositeやgeoipのルール全体を削除しないでください。局所的な問題が、全体の振り分け変更に広がってしまいます。

DNSとドメイン識別：ルールが正しいのに誤った出口へ進む理由

ドメインでルーティングできるかどうかは、コアが元の宛先ドメインを取得できるかに左右されます。ブラウザーがローカルのSOCKS5経由でドメインを渡す場合、コアは直接geositeと照合できます。上流からすでに解決済みのIPだけが渡される場合は、ドメインルールを使えず、geoipに頼ることになります。透過プロキシでは、トラフィックのスニッフィングによってHTTPホスト名やTLS Server Nameを復元できる場合もあります。

• AsIs：リクエストの元の形式で照合します。宛先がドメインならドメインルールを確認し、宛先がIPだけの場合はルーティングのためにドメインを自動解決しません。
• IPIfNonMatch：まずドメインルールを試し、一致しなければIPを解決してIPルールを確認します。この記事の地域振り分け構成に適しています。
• IPOnDemand：IP判定が必要なルールに達すると、早い段階で解決することがあります。ルール数が多い場合やDNS経路が複雑な場合は、まずテスト環境で動作を確認してください。
• トラフィックのスニッフィング：入口のsniffingによって、HTTPまたはTLSトラフィックから宛先ドメインを識別できます。設定に必要な対象の上書きタイプだけを有効にし、コアのログで識別に成功しているか確認してください。

DNSクエリ自体がどの出口を通るかも、別に考える必要があります。システムDNSで中国本土のドメインを正常に解決でき、プロキシノードがその他の宛先への接続を担当するなら、基本的な振り分けで十分です。名前解決の汚染、国内外で異なる結果、UDPクエリのタイムアウトが発生する場合は、コアのDNSを追加設定し、DNSサーバーのアドレス、問い合わせるドメイン範囲、クエリトラフィックの出力先を明確にしてください。

IPIfNonMatchだからといって、すべてのドメインを先に解決するわけではありません。geosite:cnやカスタムドメインルールに一致したリクエストは、そのまま出力先を選択できます。ドメイン条件で結果が出ず、その後にIPルールが存在する場合にだけ、解決して判定を続けます。これが、無条件にIP判定へ依存するより通常の設定に適している理由です。

ログでのトラブル対処：設定の読み込みからルール一致まで

振り分けに失敗したら、まず「コアが起動していない」のか「コアは起動しているが誤った出力先へ進む」のかを切り分けます。前者は起動後数秒以内にerrorやfailedとして現れることが多く、JSONのカンマミス、項目の階層違い、存在しない出力先タグ、ルールデータファイルの不足などが主な原因です。後者ではログレベルを上げ、宛先アドレスと最終出力先を確認します。

1. JSONの構造を確認する。routingはinboundsやoutboundsと同じ設定ルート階層に置きます。断片をコピーするときは、余分なカンマや重複した波括弧が頻発するミスです。
2. タグの綴りを確認する。outboundTagは大文字・小文字を含む文字列を区別し、outbounds配列内のtagと完全に一致させる必要があります。proxyノードの表示名で出力先タグを代用することはできません。
3. ルールデータを確認する。ログにgeositeまたはgeoipの項目を読み込めないと表示されたら、データファイルが存在し、現在のコアがその分類名に対応していることを確認します。
4. 一時的にログレベルを上げる。loglevelをwarningからinfoに変更し、コアを再起動してから、中国本土のドメインとプロキシが必要なドメインに一つずつアクセスし、接続記録を確認します。トラブル対処が終わったらwarningに戻し、通常時のログ量を減らせます。
5. ルールを絞り込む。まずprivate、cn、最終proxyの3つの基本ルールだけを残します。基本の振り分けが正常になってから、広告カテゴリ、カスタムドメイン、ポートルールを一つずつ戻してください。

{
  "log": {
    "loglevel": "info"
  }
}

中国本土のドメインがまだプロキシ経由になる場合は、まず最終proxyルールがgeositeルールより前にないかを確認し、次にリクエストがIPだけを保持していないか確認します。IPだけの場合は、geoip:cnが正常に読み込まれているか確認してください。特定の国外サービスがdirectになった場合は、カスタム直結ルールや地域データに誤って一致していないかを調べ、ログで実際の宛先ドメインを確認します。

UDPリクエストに異常がある場合は、使用中のノードプロトコルとトランスポート設定がUDPを許可しているか確認し、最終フォールバックルールのnetworkにudpが含まれているかも確認します。tcpだけを指定するとウェブ閲覧はほぼ正常に見えても、UDPに依存するDNS、リアルタイム通信、一部のネットワーク検査でタイムアウトが発生します。ルーティングでUDPを許可しても、ノード側が必ず受け付けるとは限りません。両端の対応が必要です。

検証結果：固定した対象群で回帰テストを行う

ルールを保存した後、ウェブページを1つだけテストして終わらせないでください。ブラウザーキャッシュ、接続の再利用、DNSキャッシュが古い結果を保持することがあります。コアを再起動して既存の接続を閉じ、LANアドレス、中国本土のドメイン、直接IP、国外ドメイン、TCP、UDPを含む固定のテスト項目を順番に確認するのがおすすめです。ルールを変更するたびに同じ項目を繰り返すと、結果を比較できます。

• ルーターの管理アドレスまたはローカルサービスへアクセスし、geoip:privateがdirectに一致して、LAN接続がプロキシに入らないことを確認します。
• よく使う中国本土のドメインを5つ選び、接続を消去して一つずつアクセスし、ログの出力先がdirectになっていることを確認します。
• プロキシが必要なドメインを5つ選び、広すぎる直結ルールに先に捕捉されず、最終的にproxyへ一致することを確認します。
• 設定済みのSOCKSポート10808とHTTPポート10809からそれぞれテストを実行し、アプリが古いポートへ接続していないことを確認します。
• UDPリクエストを1つテストし、ノード側が対応する転送をサポートしているか確認します。失敗した場合はUDPの結果を個別に記録し、TCPによるウェブアクセスと同じ問題として扱わないでください。
• サブスクリプションのノードを一度切り替えてコアを再起動し、カスタムルーティングが引き続き選択され、ルールが一時設定の更新で失われていないことを確認します。

保守しやすい基本構成は通常、少数のルールだけで成り立ちます。プライベートアドレスの直結、中国本土のドメイン直結、中国本土のIP直結、明確な例外、最終プロキシです。ルールが増えるほど、分類の重複や順序の衝突を調べにくくなります。ルールを追加する前に、どの具体的な目的を解決するのかを明確にし、既存のどのルールより前に置くべきか記録してください。

geositeとgeoipのデータはネットワークリソースの変化に応じて更新されるため、地域分類ですべてのドメインやアドレス範囲を永久にカバーすることはできません。少数の誤振り分けが発生した場合は、まず正確な例外を追加して地域ルールの上に保ちます。多数の対象で同時に異常が起きた場合に限り、ルールデータのバージョン、コアの互換性、DNS経路を確認してください。