v2rayNのルーティング設定ガイド：geosite・geoipによる振り分け

1. ルーティングの前提：通信がコアに届いて初めてルールが適用される

v2rayNは設定を管理し、Xrayコアはプロキシのインバウンドに届いた接続を処理します。ブラウザーがシステムプロキシを使う場合、対象のリクエストはローカルのプロキシポートに送られます。一方、システムプロキシを経由せずに直接通信するアプリには、Xrayのルーティング設定を変更しても通常影響しません。デスクトップのTUNは別の通信取り込み方式です。有効化の手順や必要な権限は、利用中のプラットフォームとクライアントの機能を確認してください。

この記事ではXrayのJSONフィールドを使用します。v2rayNでは複数のコアを管理できますが、コアごとのルール形式はそのまま流用できません。Android版のv2rayNGはXray、v2flyNGはV2Flyを使用します。概念が似ていても、画面上の設定場所、生成される設定、データファイルのバージョンは異なるため、デスクトップの設定をそのまま適用しないでください。

1. 使用中のコアを確認

   「設定」→「パラメータ設定」を開き、現在のプロトコルで選択されているコアを確認します。バージョンによっては「Coreタイプ」と表示されます。さらに起動ログのコア名を確認し、ノードのプロトコルだけで判断せず、実際にXrayが起動していることを確かめてください。

2. ルーティング設定をバックアップ

   「設定」→「ルーティング設定」を開き、選択中のルールセットとルールの順番を控えます。編集前に現在の設定をバックアップしてください。利用中のバージョンにエクスポート機能がある場合は、書き出してから変更すると、使用中のカスタムルールを上書きするリスクを減らせます。

3. プロキシの入口を確認

   「設定」→「パラメータ設定」でローカルの待ち受けポートを確認し、ブラウザーまたはシステムプロキシにも同じアドレスとポートが設定されているか確認します。リモートノードのポートをローカルのプロキシポートに設定しないでください。

4. 適用してログを確認

   保存後、メイン画面のルーティング設定で対象のルールセットを選び、利用中のバージョンの案内に従って設定を適用するか、コアを再起動します。メニューの場所はバージョンによって異なる場合があります。生成された設定と起動ログを基準に確認してください。

2. geosite・geoip・outboundTagの役割

geositeはドメインのセット、geoipはIPアドレス範囲のセットです。どちらもネットワークを検索するサービスではなく、コアが読み込むデータです。geosite:cnは、現在のデータファイルに含まれるcnドメインのセットを指します。特定のサフィックスで終わるすべてのドメインと同じ意味ではありません。geoip:cnは、現在のデータに含まれる中国本土のIPアドレス範囲に一致します。

outboundTagは既存のアウトバウンドを指定するもので、新しいアウトバウンドを作成するものではありません。この記事では、直結用アウトバウンドにdirect、設定済みのプロキシ用アウトバウンドにproxyを割り当てています。これらはXrayの予約名ではありません。生成された設定で別のタグが使われている場合は、ルール側も同じタグに変更してください。proxyを指定しても、同名のアウトバウンドがなければ有効なプロキシ経路にはなりません。

• 同じルール内のdomain配列に複数のドメイン条件がある場合、いずれか1つに一致すれば適用されます。
• 同じルール内のip配列に複数のIP条件がある場合も、いずれか1つに一致すれば適用されます。
• 同じルールでdomain、ip、portなど複数のフィールドを指定した場合、指定した条件をすべて満たす必要があります。いずれか1つを満たせばよいわけではありません。
• ルールは上から順に判定されます。先に一致したルールが適用されると、後続ルールでその接続のアウトバウンドが再選択されることはありません。

3. 基本設定：LANと中国本土は直結、それ以外はプロキシ

一般的な順番は「LAN向け例外 → カスタム例外 → 中国本土のドメイン → 中国本土のIP → 最後にプロキシ」です。まず、カスタム例外を含まない基本設定を示します。これはroutingを含む設定の一部であり、inbounds、outbounds、ノードの認証情報は含みません。クライアントの完全な設定として単独で起動できるものではありません。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "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"
      }
    ]
  }
}

1つ目のルールでは、既知のプライベート宛先アドレスを直結にします。ルーター、LAN内のファイルサーバー、内部ネットワーク機器へのアクセスに適しています。2つ目はドメインデータを使って優先的に判定します。3つ目はIPアドレスを直接指定した接続や、名前解決後のIPで判定する必要がある接続を処理します。最後のルールでは、残りのTCP・UDP通信を明示的に処理し、完全な設定における最初のアウトバウンドの既定動作に依存しないようにします。

ドメインを中心にした一般的な振り分けでは、geosite:cnを主な判断基準とし、geoip:cnでIP宛ての通信を補完できます。社内サービスが独自ドメインを使っている場合は、対象となるドメインサフィックスを直結ルールに明示的に追加してください。プライベートIPのルールがすべての社内ドメインで名前解決を引き起こすとは限りません。

4. ドメインの名前解決方針：AsIsとIPOnDemandの選び方

routing.domainStrategyは、ルーティング判定でIPアドレスが必要になるタイミングを決める設定です。DNSモジュールのサーバー一覧でも、直結アウトバウンドにある同名の設定でもありません。正しいアドレスを取得できるかは、DNS設定、ネットワーク環境、リクエストにドメイン名が保持されているかにも左右されます。設定を1つ変更するだけで、DNS汚染、DNSリクエストの経路、すべてのアプリの通信取り込みを同時に解決することはできません。

IPOnDemandに切り替え、特定のドメインを常にプロキシ経由にしたい場合は、そのドメインルールを広範囲のIPルールより前に置いてください。そうしないと、ドメインを先に名前解決した結果が直結条件に一致し、直結ルールが先に適用される場合があります。ルールの優先順位とDNSの結果をあわせて確認してください。

5. カスタムルール：ドメイン例外、ポート条件、ローカルセット

カスタムルールは、対象が明確な少数のドメインから始めてください。次の2つの例は、それぞれ「指定したホストをプロキシ経由にする」「例示ドメイン全体とサブドメインを直結する」設定です。例示用ドメインは、実際に管理するドメインに置き換えてください。ドメイン条件にはURLのhttps://、パス、クエリパラメーターを含めないでください。

[
  {
    "type": "field",
    "domain": ["full:api.example.com"],
    "outboundTag": "proxy"
  },
  {
    "type": "field",
    "domain": ["domain:example.com"],
    "outboundTag": "direct"
  }
]

この2つのルールは、適用範囲の広いルールより前に置き、より具体的なapi.example.comを先にしてください。順番を逆にすると、サブドメインがドメイン全体の直結ルールに先に一致し、後続の個別プロキシルールが適用されません。LAN内のアドレスも関係する場合は、セキュリティ上のアクセス境界とドメイン例外のどちらを優先するかを明確にし、機械的に同じ順番を適用しないでください。

ポート条件が指定するのは宛先ポートです。たとえば、ドメイン条件と"port": "443"を同じルールに指定すると、「そのドメインへの接続で、宛先ポートが443の場合」という意味になります。そのドメインへのすべての接続が対象になるわけではありません。ポート53だけを指定したプロキシルールでは、別の通信方式を使うDNS通信すべてを処理できず、DNSモジュールの設定の代わりにもなりません。

カスタムセットを管理する2つの方法

• 少数のドメイン：domain配列を直接編集し、各項目にfull:またはdomain:を使って範囲を明示します。外部のセットファイルが不要で、変更内容も確認しやすくなります。
• 多数のドメイン：コアのデータ形式に合ったセットファイルを用意します。たとえばext:custom.dat:officeは、カスタムデータファイルからofficeセットを読み込む指定です。任意のテキストファイル名にタグを付ける形式でも、任意のリモートルールURLでもありません。
• データを更新：現在のコアが使うリソースディレクトリ、ファイルの読み取り権限、実際のセット名を確認してください。既存のgeositeデータにないタグは、ルール名を書き換えるだけでは作成できません。

6. 全通信をプロキシ経由にする：LANを直結するか、すべてノードに送るか

「全通信をプロキシ経由にする」場合は、まず対象範囲を決めてください。v2rayNのルーティング設定が制御するのは、すでにコアに届いている通信です。システム上のすべてのプロセスが自動的に取り込まれるわけではありません。システムプロキシを使わないアプリは、独自にネットワークへ接続する場合があります。UDPが使えるかどうかは、インバウンド方式、ノードのプロトコル、サーバー側の対応状況にも左右されます。

特定のサイトを一時的に調べるだけなら、すべての振り分けルールをすぐ削除する必要はありません。まず、対象サイトに一致するドメインルールを追加し、それを適用範囲の広いルールより前に置いて、メインドメインとAPI用ドメインを確認します。1つのWebページからログイン、静的ファイル、ダウンロード用の複数ドメインへアクセスする場合があるため、アドレスバーに表示されたホスト名だけを変更しても、すべての通信をカバーできるとは限りません。

ノードのプロトコルを変更しても、ルーティングの問題は解決しません。VMessとVLESSはプロキシ接続方式を示すものです。outboundTagは、現在の接続を設定済みのどのアウトバウンドに渡すかを決めます。ノード自体が使えるのであれば、まずルールの条件と順番を確認し、プロトコルの設定項目を何度も変更するのは避けてください。

7. 動作確認：通信の取り込み、ルール一致、出口を順に確認

出口のIPアドレスから分かるのは、あるテストリクエストの経路だけです。すべてのアプリが同じルールで動作している証明にはなりません。対象を固定して、設定を1項目変更するたびに新しい接続で確認してください。ブラウザーの既存接続が以前のアウトバウンドを再利用することがあります。必要に応じて対象ページを閉じ、古い接続を終了するか、テスト用アプリを再起動してください。

1. 通信が取り込まれているか確認

   対象ページを開き、クライアントのログに対応する接続が記録されるか確認します。記録がない場合は、geositeの調整を急がず、システムプロキシ、ローカルの待ち受けポート、アプリ独自のプロキシ設定を確認してください。

2. LANへの接続を確認

   実際に使っているルーターやファイルサーバーのIPでテストします。たとえば、利用可能な192.168.1.1などを確認してください。このアドレスは一般的な例にすぎないため、実際のLAN環境に合わせてテストし、対応するLAN内ドメインも個別に確認します。

3. ドメイン例外を確認

   追加した個別ドメインに対して新しいリクエストを発行し、ログに記録された宛先アドレスとアウトバウンドタグを確認します。ログの形式はコアの設定によって異なります。ルール番号が表示されない場合は、接続に成功したというログだけで、どのルールに一致したかを判断しないでください。

4. フォールバック経路を確認

   カスタム例外に含まれないインターネット上の宛先を選び、プロキシ用アウトバウンドが使われるか確認します。ログレベルの一時的な変更は調査中に限り、終了後は元に戻してください。ログを共有する前に、サブスクリプションURLとノードの認証情報を削除します。

よくある症状と対処方法

• ドメインは想定どおり直結するが、IPアドレスを直接入力するとプロキシ経由になる：IPアドレスが対象のセットに含まれているか、geoipファイルが正しく読み込まれているか確認してください。ドメインの分類とサーバーアドレスの地域判定は別のものです。
• ルールを追加しても以前の経路が使われる：対象のルールセットが選択されているか、コアに設定が適用されているか、前方に広範囲のルールがないか確認します。その後、既存の接続を閉じて再テストしてください。
• 起動時にセットが見つからないと表示される：データファイル、セット名、リソースディレクトリを確認してください。まず明示的なfull:ルールでルーティング経路を確認してから、セットの読み込み問題を調べます。
• ログではプロキシが選択されているのにページが開かない：ノードへの接続、DNSの結果、サーバー側のアクセス制限を続けて確認してください。ルールに一致したことが示すのはアウトバウンドが選ばれたことだけで、その後の接続完了までは保証しません。

安定した振り分け設定では、各ルールの目的を説明できることが大切です。どのアドレスを直結するのか、どのドメインを明示的にプロキシ経由にするのか、どの条件が名前解決に依存するのか、最後にどのルールが残りを処理するのかを整理します。まず少数の検証可能なルールで基準を作り、その後セットを拡張すると、重複したルールを一度に大量に追加するより管理しやすくなります。