V2Rayのルーティング設定｜geosite・geoipで中国本土と海外を振り分ける方法

この記事の概要

この記事は、v2rayNでサーバーに接続でき、ルーティングを調整したいMacユーザー向けです。ドメインリストとIPアドレスデータの違いを確認し、「プライベートアドレスは直結、中国本土のドメインとIPも直結、それ以外はプロキシへ」というルールを設定します。読みやすいroutingの設定例を示し、デフォルトのアウトバウンド、DNS、ルール順序が実際の通信経路に与える影響も説明します。

geositeとgeoip：照合対象の違い

ルーティングは、ウェブページの言語や端末の所在地で経路を判断する仕組みではありません。リクエストを受け取ったV2Rayコアは、利用可能な宛先ドメイン、宛先IP、ポートなどの情報を読み取り、routing.rulesを上から順に照合します。ルールに一致すると、そのルールで指定されたoutboundTagに通信が渡されます。このタグは、outboundsに実在するtagと一致させてください。

記述方法	照合対象	主な制約
`geosite:cn`	ドメイン分類リスト	使用するgeositeデータファイルに依存し、中国本土のすべてのウェブサイトを網羅するわけではありません
`geoip:cn`	データベースで中国に分類されたIPアドレス範囲	ウェブサイトの運営会社やコンテンツの言語を示すものではありません
`geoip:private`	プライベートアドレスおよび特殊用途アドレスの範囲	具体的な範囲は使用するデータファイルで確認してください
`domain:example.com`	指定したドメインとそのサブドメイン	名前が似ている別のドメインは対象外です
`full:example.com`	完全一致するドメイン	サブドメインは含みません

geosite:cnは分類項目であり、ドメインの末尾から所在地を推測するものではありません。.comのドメインがリストに含まれる場合もあります。反対に、海外のCDNを利用するウェブサイトでは、ドメインの分類とIPの所在が異なることがあります。ドメイン情報がある場合は、通常、解決後のアドレスだけを見るよりドメインで振り分けるほうが管理しやすくなります。

v2rayNのルーティング設定：変更前にバックアップ

v2rayNは設定と接続を管理するクライアントで、ルールを実行するのは選択したコアです。Project V、V2Fly、Xrayの各エコシステムでは共通の設定項目もありますが、それぞれ独自の拡張もあります。この記事では一般的なfieldルールのみを使い、あるコア固有の拡張パラメーターを別のコアへそのまま流用しません。

現在の設定を記録

メイン画面で現在のサーバー、ルーティングモード、システムプロキシの状態を記録します。「設定」→「パラメーター設定」を開き、使用中のコアとローカル待ち受けポートも控えてください。画面上の項目はバージョンによって異なるため、実際の表示を確認します。設定例に合わせるためだけに、現在のノードが対応していないコアへ切り替えないでください。
ルーティングルールをバックアップ

「設定」→「ルーティング設定」を開き、既存ルールをバックアップしてから、テスト用のルーティング設定を新規作成または編集します。メイン画面でその設定が実際に選択されていることを確認してください。グローバルプロキシやグローバル直結モードのままになっていないかも確認します。
アウトバウンドタグを確認

コアが実際に読み込んだ設定を確認し、プロキシと直結のアウトバウンドに指定されたtagを照合します。この記事ではproxyとdirectを例として使っています。実際のタグが異なる場合は、ルール内のoutboundTagも合わせて変更してください。
設定を適用してログを確認

ルールを保存したら、クライアントにコアの設定を再読み込みさせ、起動結果をログで確認します。存在しないアウトバウンド、データファイルの読み込み失敗、JSON解析エラーが発生した場合は、ルールを追加し続けず、まずバックアップを復元してください。

クライアントは通常、実行時の設定を再生成します。一時ファイルのconfig.jsonを直接編集すると、サーバーの切り替えや再起動後に上書きされることがあります。通常の利用ではルーティング設定からルールを保存してください。手動で設定を管理する場合は、以下の断片を自身の設定ソースで管理します。

routing設定例：中国本土は直結、それ以外はプロキシ

以下は独立したルーティング設定の断片であり、クライアント設定全体ではありません。使用前に、利用可能なプロキシアウトバウンドと、protocolがfreedomの直結アウトバウンドを用意してください。それぞれのタグはproxyとdirectです。また、コアが対象の分類を含むgeositeおよびgeoipデータファイルを読み込めることも確認してください。

{
  "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つ目のルールはプライベートアドレスを処理します：192.168.1.1や10.0.0.1などのローカルネットワーク宛ての通信は、ルーターや内部サービスへのアクセスに遠隔プロキシを経由させないようにします。
2つ目のルールは中国本土のドメインを処理します：geosite:cnに一致したら直結し、後続のIP条件は確認しません。
3つ目のルールは中国本土のIPを処理します：宛先がもともとIPアドレスの場合や、ルーティング方針に応じて名前解決された結果が中国本土のアドレスだった場合に適用されます。
4つ目のルールで明示的にフォールバックします：残りのTCPおよびUDPリクエストをproxyへ渡すため、アウトバウンド配列のデフォルト順序に依存しません。

どのルールにも一致しない場合、コアは通常、outboundsの先頭にあるアウトバウンドを使用します。そのため、「それ以外はプロキシへ」という動作は、明示的なルールで設定する方法と、プロキシをデフォルトアウトバウンドにする方法があります。どちらを選ぶかによってIPIfNonMatchへの影響が異なるため、アウトバウンドの順序を確認せずにrulesだけをコピーしないでください。

domainStrategy：ルーティングで名前解決するタイミング

routing.domainStrategyは、ルーティングの照合中にドメインをIPアドレスへ変換するかどうかを決めます。システムDNSの設定スイッチではなく、直結アウトバウンド側のドメイン処理方針とも異なります。この項目を変更しても、DNSリクエストの取り込みや暗号化、上流DNSの選択が自動で行われるわけではありません。

IPIfNonMatch

推奨

まず取得済みの宛先情報で照合し、ドメインがどのルールにも一致しない場合に名前解決を試み、その結果で再照合します。最初の設定として適していますが、最後にすべてのリクエストに一致するルールがないか確認してください。名前解決による追加判定が必要な場合は、プロキシをデフォルトアウトバウンドにすると動作が明確になります。

適した設定：ドメインルールを優先し、デフォルトアウトバウンドを明示的に管理する場合

AsIs

ルーティング段階では、照合のための名前解決を積極的に行いません。ドメイン宛てのリクエストは主にdomainルールで判定し、宛先がもともとIPの場合はipルールに一致させられます。ただし、接続全体でDNS問い合わせが一切発生しないことを保証するものではありません。

適した設定：ドメインリストが十分に整っており、ルーティング時の名前解決への依存を減らしたい場合

IPOnDemand

ドメイン宛てのリクエストがIP情報を必要とするルールに一致した場合、名前解決を試みてから判定します。最初のルールがgeoip:privateの場合、早い段階で名前解決が行われる可能性があり、DNSの利用可否や応答アドレスがルーティングに直接影響します。

適した設定：解決後のアドレスで判定する必要があり、DNS経路を検証済みの場合

結論：先にフォールバックを決め、その後で名前解決の方針を選ぶ

「ドメインリストにない宛先もIPで追加判定」したい場合は、まずプロキシを先頭のアウトバウンドに設定し、最後の全一致ルールを削除してから、IPIfNonMatchで動作を検証します。明示的なフォールバックを残す場合は、未知のドメインを直接プロキシへ送ることを理解したうえで設定するか、IPOnDemandの名前解決結果を個別にテストしてください。

同じドメインでも複数のIPv4・IPv6アドレスが返ることがあり、DNSの上流によってCDNの接続先が変わる場合もあります。ある時点でgeoip:cnに一致しても、以後の接続すべてで一致するとは限りません。出口を安定させる必要がある場合は、偶然使われたCDNアドレスをルールに固定せず、対象ドメイン専用のルールを設定してください。

ルールの順序：最初に一致したルールが適用される

ルールは上から順に確認され、一致すると対応するアウトバウンドが使われます。コアが複数のルールを比較して「より具体的な方」を選ぶことはありません。個別の例外を広い分類より前に置き、すべてに一致するフォールバックを最後に置くのが、ルール管理の基本です。

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

たとえば、ドメインデータでは直結に分類されていても、実際の用途ではプロキシ経由にしたいドメインがある場合、専用ルールをgeosite:cnより前に置きます。example.comは記述方法を示すための例なので、実際の対象に置き換えてください。ルートドメインだけを対象にしてサブドメインを含めない場合は、full:を使います。

同じフィールド内の条件は通常「OR」です：domain配列に2つのドメインを書いた場合、どちらか一方に一致すればそのフィールドの条件を満たします。
同じルール内の異なる条件は通常「AND」です：domainとportを同時に指定すると、宛先ドメインとポートの両方が一致する必要があります。domainとipを同じルールに入れて、どちらか一方に一致すればよいという意味だと誤解しないでください。
ポート条件では実際のプロトコルも考慮します：TCPのみを照合するルールはUDPを対象にしません。ブラウザーのHTTP/3ではUDP 443が使われることが多いため、TCP 443で一致しただけでは、すべてのウェブ接続を確認したことにはなりません。
ルールが処理するのはコアに届いた接続だけです：システムプロキシの除外リストにあるローカルアドレスは、アプリから直接アクセスされる場合があります。その場合、コアのログに記録されないのは正常です。

検証とトラブルシューティング：宛先・ルール・アウトバウンドを確認

ウェブページが開けても、今回のリクエストが完了したことしか確認できず、想定した出口を通った証拠にはなりません。まずコアが正常に起動していることを確認し、決まったリクエストを送って、アクセスログに記録された宛先とアウトバウンドタグを調べます。ログ形式はコアによって異なり、インバウンドからアウトバウンドへの対応関係が表示される形式もあります。ログレベルが低い場合は、テスト中だけ記録レベルを上げ、完了後に元へ戻してください。

curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://www.baidu.com/
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/

ここで使う10809は説明用のHTTPプロキシポートであり、現在のv2rayNのデフォルト値を示すものではありません。「設定」→「パラメーター設定」で実際に有効になっているHTTPまたは混合待ち受けポートに置き換えてください。コマンドでローカルプロキシを明示すると、ターミナルがシステムプロキシに従うかどうかを検証要因から外せます。以下の2つのリクエストで確認できるのは主にTCP経路であり、ブラウザーのUDP通信ではありません。

中国本土のウェブサイトなのにプロキシ経由になるのはなぜ？

まずログで宛先がドメインかIPかを確認し、そのドメインが現在のgeositeデータに含まれているかを調べます。IPIfNonMatchを使っていて、最後にすべてに一致するプロキシルールがある場合、ドメインは名前解決による追加判定に進みません。まず完全一致のドメインを直結するルールを追加してテストし、いきなりIP範囲全体を直結にしないでください。

geoip:cnを追加したら、一部のウェブサイトが開かなくなった場合

DNSの応答アドレスとログに記録された実際の出口を確認します。宛先IPが中国本土と判定されても、現在のネットワークからそのサービスへ直接接続できない場合は、そのサービスのドメインにプロキシ例外を追加し、中国本土向けの直結ルールより前に置いてください。変更は一度に1ルールだけにし、失敗時の宛先記録を比較用に残します。

geositeの分類が見つからないとログに表示された場合

ルール内の分類名、コアが実際に読み込んでいるデータファイルのパス、起動ログを確認します。配布元によってデータの内容が異なる場合があり、サブスクリプションの更新もルールデータベースの更新とは別です。クライアントに用意されたデータ更新機能を使ってからコアを再起動してください。それでも解決しない場合は、存在を確認済みの分類に戻します。

ルールを変更しても反映されない場合、再インストールは必要？

まず新しいルーティング設定に切り替わっていることを確認し、コアを再読み込みします。テスト対象のアプリで既存の接続を閉じてから、再度リクエストしてください。確立済みの長時間接続は、ルールを変更しても自動で出口が切り替わりません。クライアントに上書きされる実行時ファイルではなく、設定ソースを編集していることも確認してください。

最後に、使用したコア、ルーティングルールの内容、テストリクエストに対応するアウトバウンドタグの3項目を記録します。ログを公開する前に、サブスクリプションURL、ノードの認証情報、個人のアクセス履歴を削除してください。ルーティング設定の検証では、1回の速度測定で全ルールの正しさを判断するのではなく、「指定したリクエストが安定して指定のアウトバウンドに送られること」を確認します。