ルーティングルール分岐の実践：geositeとgeoipで直通接続とプロキシを正確に振り分ける

まずルーティングの振り分けを3つの判定対象に分ける

v2rayNのルーティングルールは、最終的にXrayコアが実行します。各接続がコアに入ると、ルーティングモジュールは宛先ドメイン、宛先IP、ポート、ネットワーク種別、インバウンドタグなどの属性を読み取り、ルールを上から順に確認します。最初に条件を満たしたルールによって、接続に使用するアウトバウンドが決まります。一般的なアウトバウンドにはプロキシ、直通、ブロックなどがありますが、この記事ではプロキシと直通接続の正確な振り分けだけを扱います。

中国本土の日常的なネットワーク環境では、保守しやすいルールを3つの論理層に分けられます。第1層では、LANとローカルのプライベートアドレスを処理し、ルーター、ストレージ機器、ローカルサービスへのアクセスがプロキシ経路に入らないようにします。第2層では、中国本土のサイトまたはアドレス範囲に明確に該当する宛先を処理し、直通接続にします。第3層ではドメイン種別を列挙せず、残りの通信をプロキシのアウトバウンドへ渡します。

プライベートアドレス層：geoip:privateに一致させ、直通のアウトバウンドを使用します。
中国本土の宛先層：geosite:cnとgeoip:cnをそれぞれ判定し、直通のアウトバウンドを使用します。
デフォルト処理層：残りのTCPおよびUDP接続に一致させ、プロキシのアウトバウンドを使用します。

ここでいう「層」はポリシー構造を指し、各層に1つのルールオブジェクトしか書けないという意味ではありません。ドメイン条件とIP条件は、できるだけ別のルールに分けるのが適切です。1つのルール内では異なるフィールドが通常すべて満たされる必要があり、同じフィールド内の複数の値だけがいずれかに一致する関係になるためです。domainとipを区別せず1つのルールに詰め込むと、実際の一致範囲が想定より狭くなる場合があります。

geositeとgeoipはそれぞれ何を判定するのか

geositeはドメインのカテゴリで判定する

geositeのデータは、ドメインの特徴に基づいてカテゴリ分けされています。geosite:cnは、中国本土カテゴリに分類されたドメインとの一致に使用します。アプリが宛先へ接続する際、コアが元のドメインを取得できれば、宛先接続を確立する前にドメインルールで判定できます。宛先がどのIP範囲に属するかを先に確認する必要はありません。

ドメインカテゴリは、コンテンツ配信ネットワーク、動的アドレス、多数のアドレスによる振り分けを利用するサイトの処理に適しています。サイトの名前解決結果は事業者、地域、時間帯によって変わることがありますが、ドメインの所属カテゴリは通常より安定しています。このようなドメインを直通のアウトバウンドに振り分ければ、アドレスの変化によるルールのずれを減らせます。

注意点として、geosite:cnはデータファイル内のドメイン分類を示すもので、「現在の名前解決結果が必ず中国本土にある」という意味ではありません。サイトが地域をまたぐノードを使用する場合もあり、企業がホスティング場所を変更することもあります。そのため、geositeはドメインに基づくポリシーの表現に適しており、リアルタイムのネットワーク測定の代わりにはなりません。

geoipは宛先アドレスで判定する

geoipのデータは、IPアドレス範囲を用途や地域ごとに分類します。geoip:privateはLANなどの非公開ネットワーク宛先を対象とし、ローカルネットワーク、家庭用ルーターの管理アドレス、LANプリンター、内部ストレージ機器への直通接続によく使われます。プライベートアドレスはリモートプロキシに渡すのに適した宛先カテゴリではないため、通常の地域ルールより前に配置してください。

geoip:cnは、中国本土のアドレス範囲に分類された宛先との一致に使用します。アプリが特定のIPへ直接接続する場合や、ドメインが既存のgeositeルールに一致しないまま名前解決された場合に、IPルールで補足的に判定できます。これはgeosite:cnの代替ではなく、「ドメインで識別する経路」と「アドレスで識別する経路」をそれぞれカバーするものです。

ルール項目	判定基準	主な用途	推奨アウトバウンド
`geoip:private`	宛先IPがプライベートアドレス範囲に属する	LAN、ローカルネットワーク、内部サービス	直通
`geosite:cn`	宛先ドメインが該当カテゴリに属する	ドメインで中国本土のサイトを識別	直通
`geoip:cn`	宛先IPが該当アドレス範囲に属する	IPへの直接接続、または名前解決後の補足判定	直通
`network: tcp,udp`	接続がTCPまたはUDPである	前のルールに一致しなかった通常の通信を受ける	プロキシ

domainStrategyはドメインをIPに名前解決するタイミングを決める

geositeとgeoipを記述するだけでは不十分です。ドメインリクエストがIP判定へ進むかどうかは、ルーティング設定のdomainStrategyによって決まります。このパラメーターはルーティング段階の名前解決動作に影響し、単純な「DNSのオン・オフ」ではありません。これを理解すると、「ドメインルールは正常なのに、IPルールが引き継がない」という現象の原因も説明できます。

AsIs：元の宛先形式を維持

AsIsは、ルーティング段階で接続が保持する元の宛先を優先して判定します。宛先がドメインの場合は主にドメイン関連ルールを使用し、ルーティングモジュールがgeoipルールを試すためにドメインを自動でIPへ名前解決することはありません。宛先自体がIPの場合は、geoipルールも通常どおり一致します。

このモードは名前解決の処理が少なく、経路も分かりやすい一方、「geositeに収録されていないドメインを、名前解決後のアドレスでも判定したい」ケースには不向きです。たとえば中国本土のドメインがgeosite:cnに一致しない場合、geoip:cnのアドレス範囲へ解決されても、最後のプロキシルールに入る可能性があります。

IPIfNonMatch：ドメインルールに一致しなければ名前解決する

IPIfNonMatchは、この記事の3段階の振り分けに適しています。コアはまずドメイン情報でルールを試し、ドメインルールで判定できなかった場合に宛先ドメインを名前解決し、得られたIPでアドレスルールを試します。これにより、まずgeosite:cnの分類機能を活用し、その後geoip:privateとgeoip:cnで補足的に判定できます。

この方式は、判定精度と追加の名前解決処理のバランスに優れています。ドメイン接続のたびに直ちにIP判定を要求するのではなく、ドメイン分類で不足する場合だけ第2の一致経路を使います。「中国本土のドメインは直通、中国本土のアドレスも直通、それ以外はプロキシ」という一般的なデスクトップ設定では、通常AsIsより期待どおりに動作します。

IPOnDemand：IP条件がある場合に先行して名前解決する

IPOnDemandは、ルーティング判定でIP情報が必要になると、より積極的にドメインを名前解決します。設定に一致判定へ利用できるIPルールがある場合、名前解決が早い段階で実行されることがあります。宛先アドレスに基づく細かな制御が必要な設定には適していますが、DNS経路、キャッシュ状態、名前解決結果がルーティング処理へより直接的に影響する点に注意が必要です。

ルールの目的が一般的な中国本土向け直通と、それ以外のプロキシだけであれば、「より徹底しているように見える」という理由だけで積極的な名前解決方式を選ぶ必要はありません。まずIPIfNonMatchを使用し、ログで一致しなかった具体的な宛先を確認して調整するほうが、問題を特定しやすいケースが多いです。

ルーティングの名前解決とDNSのアウトバウンドは併せて確認する domainStrategyはルーティング段階でIP情報が必要かどうかを決めますが、名前解決リクエストがどの経路を通るかは、DNS設定、アウトバウンドタグ、ルーティングルールの影響も受けます。名前解決のタイムアウト、異常な結果、リクエストループが発生した場合は、DNS設定とルーティングログを同時に確認してください。

そのまま調整できる3段階ルーティングテンプレート

以下の断片はrouting部分だけを示しています。完全な既存設定に、タグがdirectの直通アウトバウンドと、タグがproxyのプロキシアウトバウンドがすでに存在することを前提とします。現在の設定で別のタグを使用している場合は、テンプレートのoutboundTagを実際の値に変更してください。タグは大文字・小文字を含めて完全に一致させる必要があります。

{
  "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"
      }
    ]
  }
}

ポリシー上は、これも3段階です。第1条はプライベートアドレス層に対応します。第2条と第3条は中国本土の宛先層を構成しますが、異なるフィールドが同時に満たされる関係を避けるため分けています。第4条はプロキシのフォールバック層です。

宛先がLANのIPの場合は、第1ルールに直接一致します。宛先がgeosite:cnカテゴリのドメインなら、第2ルールに一致します。中国本土のIPを直接入力した場合、またはドメインカテゴリに一致せずIPIfNonMatchの段階で中国本土のアドレスへ名前解決された場合は、第3ルールが処理します。それ以外の通常のTCP・UDP通信は、最後のプロキシアウトバウンドへ進みます。

完全な設定に、特定ドメインのブロック、特定サービスのプロキシ固定、特定プロセスの専用アウトバウンド指定などのルールがある場合は、より具体的なルールをフォールバックより前に置いてください。中国本土向け直通ルールより前に置くかどうかは優先順位によって決まります。たとえばgeosite:cnに分類されるドメインでもプロキシを通す必要がある場合、そのドメイン専用のプロキシルールをgeosite:cnより前に配置します。

v2rayNで適用する前に確認したい4つのポイント

1. ルールで使用するアウトバウンドタグを確認する

テンプレートのdirectとproxyは、よく使われるタグにすぎません。実際の実行設定では、現在のサーバー、ルーティングモード、コア設定に基づいてv2rayNが生成している場合があります。カスタム設定や高度なルーティングを変更する前に、現在のアウトバウンドタグを確認し、ルールが参照する宛先が実際に存在することを確かめてください。存在しないタグを参照すると、ルールが意図どおり転送できず、通常はコアのログに該当するエラーが記録されます。

2. geositeとgeoipのデータを現在のコアが読み込めることを確認する

geosite:cnとgeoip:cnはデータファイルに依存します。コアプログラムはルールを実行し、分類内容は付属のデータから提供されます。カテゴリを読み込めない、ファイルが存在しない、項目が不明といったログが出る場合は、ルールの順序を何度も変えるのではなく、まずコアとデータファイルの対応状態を確認してください。

データを更新した後は、関連するコアプロセスを再起動し、新しいプロセスにリソースを読み込ませてください。設定画面を閉じただけでは、実行中のコアが再読み込みされたとは限りません。テスト前にv2rayNで接続を停止してから再起動し、新しく生成されたログを確認するとよいでしょう。

3. システム通信が実際にv2rayNへ入っていることを確認する

ルーティングルールが処理できるのは、すでにコアへ入った接続だけです。システムプロキシを使用する場合、アプリがシステムプロキシ設定に従う必要があります。TUNモードの場合は、TUNが起動しているか、ルートが確立されているか、DNSが想定どおり引き継がれているかを確認してください。アプリが現在の入口を完全に迂回している場合、geositeやgeoipのルールを変更しても通信経路は変わりません。

トラブル対応では、まずウェブページの表示速度から振り分け結果を推測しないでください。対象へアクセスした際に接続ログが生成されたか、どのアウトバウンドタグに一致したか、ログ上の宛先がドメインかIPかを確認するほうが確実です。該当する記録がまったくない場合は、ルーティング条件を追加する前に通信の入口を確認してください。

4. サブスクリプション更新でカスタムルーティングが上書きされないことを確認する

サブスクリプションはサーバーノードと接続関連パラメーターを提供し、ルーティングルールはクライアント側のローカルポリシーです。サブスクリプションを更新するとノード一覧は変わりますが、カスタムルーティングが保持されるかどうかは、ルールの保存場所と現在の設定方式によって決まります。長期間使うルールは、v2rayNのルーティング設定または明確に管理しているカスタム設定へ保存し、都度生成される一時的な実行ファイルだけを変更しないでください。

ルールの順序を誤ると起きる典型的な現象

プロキシのフォールバックを先頭に置く

network: tcp,udpのプロキシルールがリストの先頭にあると、ほとんどの通常接続がすぐに一致し、後続のgeoip:private、geosite:cn、geoip:cnは実行されません。通常、中国本土のサイトもLANの宛先もプロキシへ入ります。対処法は除外項目を追加することではなく、広範なフォールバックを末尾へ移動することです。

個別の例外をgeosite:cnの後ろに置く

中国本土カテゴリに含まれる特定の業務ドメインをテストのためプロキシ経由にしたいとします。その専用ルールがgeosite:cnの後ろにあると、接続は先に中国本土向け直通ルールで処理されます。具体的なドメインルールをカテゴリルールより前に移動してください。ルーティングリストの前方には、範囲が狭く意図が明確な例外を置くのが適しています。

geosite:cnだけを記述し、geoip:cnを設定しない

この設定ではドメインを使用するアクセスの多くを処理できますが、中国本土のIPへ直接接続するケースや、名前解決結果で未収録ドメインを補足するケースはカバーできません。ログ上の宛先がIPとして表示されることが多い場合は、ドメイン一覧を増やし続けるより、独立したgeoip:cnルールを追加するほうが効果的です。

geoip:cnだけを記述し、geosite:cnを設定しない

アドレス判定だけに依存すると、名前解決により多くの処理を任せることになり、配信ノードやアドレス振り分けの影響も受けます。中国本土の業務ドメインが、想定したカテゴリに属さないアドレスへ解決されてプロキシに入ることもあります。ドメインに基づく方針が明確な場合は、まずgeosite:cnで意図を表し、geoip:cnで補足する構成が適しています。

複数の条件をいずれかに一致すると誤解する

1つのルールにdomain、ip、port、networkを同時に記述すると、通常は接続がこれらすべてのフィールドを同時に満たす必要があります。ルールに一致しない場合は、ドメインがリストにあるかだけでなく、各フィールドを個別に確認してください。保守を容易にするには、異なる判定軸を意図ごとに単一のルールへ分けるとよいでしょう。

感覚ではなくログで検証する

振り分けルールを完成させたら、少なくとも4種類の宛先をテストします。LANアドレス、中国本土カテゴリのドメイン、中国本土の直接接続IP、そしてプロキシへ送る想定の一般的な外部ドメインです。毎回1つの宛先だけをテストし、宛先形式、名前解決結果、最終的なアウトバウンドタグを記録してください。

ルーターまたはLANサービスへアクセスし、接続がdirectを使用することを確認します。
安定した中国本土のドメインへアクセスし、geosite:cnに対応する直通経路が有効になることを確認します。
明確に中国本土に属するIPへ接続し、geoip:cnが単独で一致することを確認します。
前述のカテゴリに属さない宛先へアクセスし、最終的にproxyへフォールバックすることを確認します。

コアのログレベルが低く、十分なルーティング情報を確認できない場合は、トラブル対応中だけログの詳細度を上げ、完了後に通常設定へ戻してください。ログでは宛先アドレス、ドメインの名前解決、ルールエラー、アウトバウンドタグを重点的に確認します。テスト中は、ブラウザーキャッシュ、既存の長時間接続、バックグラウンドリクエストが判定に混ざらないようにしてください。対象ページを閉じてから接続を再確立すると、結果を識別しやすくなります。

基本テンプレートを拡張するときも「具体的なルールを前、広範なルールを後」にする

3段階テンプレートは出発点として適していますが、検証していないカテゴリを無制限に積み重ねるものではありません。拡張する際は、まず業務上の意図を明確にし、そのうえでドメイン、IP、ポート、インバウンドタグのどれを使うか決めます。特定のドメインを必ずプロキシ経由にするなら、具体的なドメイン用プロキシルールを追加します。内部ネットワークを必ず直通にするなら、該当するIP範囲の直通ルールを追加します。特定のUDP通信に専用アウトバウンドが必要なら、ネットワークとポートの条件を分けて追加します。

ルールを1つ追加するたびに、3つの質問に答えられるようにしてください。どの宛先を対象にするのか、どのルールより前に置く必要があるのか、一致しなかった場合はどこへ進むのか。答えられない場合は、ルールの範囲または優先順位がまだ明確ではありません。大量のルールより、順序が明確でフィールドが単純、ログで検証できる短いルールセットのほうが長期的に保守しやすくなります。

この記事のケースにおける最終原則は、次の一文にまとめられます。まずプライベートネットワークを保護し、次に明確な中国本土のドメインとアドレスを識別し、最後に残りの接続をプロキシへ渡します。geosite:cnはドメイン層のポリシーを担当し、geoip:privateとgeoip:cnはアドレス層を補足し、IPIfNonMatchが2つの判定経路をつなぎます。アウトバウンドタグが正確で、データファイルを読み込め、通信が確実にコアへ入っていれば、この構成によって直通接続とプロキシを説明可能かつトラブル対応しやすい形で分離できます。