この記事では、ノードをインポート済みで、ドメインやIPアドレスに応じて通信を振り分けたい方向けに設定方法を解説します。まずドメインリスト、IPアドレスリスト、デフォルトの出力先を整理し、ルールの順序を設定例で確認します。最後にv2rayNで適用し、ログで動作を検証します。例ではXray/V2Flyで一般的なfield形式のルーティング設定を使用します。サブスクリプションのノード情報、クライアントのメニュー、コアの設定を混同しないようにしましょう。
1. geositeとgeoipで判定できる対象
ルーティングによる通信の振り分けは、ノードのプロトコルを変更するものではありません。コアに入った各接続の出力先を選択する設定です。VMessやVLESSなどはプロキシ接続の確立方法を決め、ルールは接続先をプロキシ、直接接続、または別の定義済み出力先のどれに渡すかを決めます。サブスクリプションに利用可能なノードがあっても、適切な振り分け設定があるとは限りません。
geosite:cnはドメインデータファイル内のcnカテゴリを参照し、geoip:cnはIPデータファイル内の中国のIPアドレス範囲を参照します。前者はドメインがリストに含まれるか、後者は接続先IPが該当するアドレス範囲に含まれるかを判定します。サイトの言語を検出する機能ではなく、中国本土のすべてのサービスや国際サイト、CDNのアドレスが想定どおりに分類される保証もありません。
ドメインルール
- 項目
domain- リストの例
geosite:cn- 完全一致ドメイン
full:example.com- ドメインとサブドメイン
domain:example.com
コアがドメイン名を取得している必要があります。接続先がIPアドレスだけの場合、ドメインリストでは判定できません。
IPアドレスルール
- 項目
ip- リストの例
geoip:cn- プライベートIPアドレス
geoip:private- アドレス範囲の例
192.168.0.0/16
IPアドレスを直接指定する接続や、ルーティング時にドメインを解決してIPアドレスを判定する場合に適しています。
ドメインを指定する場合は、full:またはdomain:を明示するのがおすすめです。通常の文字列による部分一致では、名前が似ているだけで無関係なサイトまで一致することがあります。domain:example.comは該当ドメインとそのサブドメインに一致し、notexample.comはサブドメインとして扱いません。本文のexample.comは構文の説明用であり、接続テスト用のサービスではありません。
2. ルールの順序：独自の例外をリストより先に設定
一般的なfieldルールは配列の順に評価され、最初に一致したルールの出力先が適用されます。「より具体的な」ルールが自動で選ばれるわけではありません。同じルールにdomainとportを設定した場合、通常は両方の条件を満たす必要があります。同じdomain配列内の複数項目は、いずれかに一致すれば適用されます。「このドメインまたはこのIP」のように条件を分けたい場合は、ルールを2つに分けてください。
- まず必要な例外を設定：プロキシ経由が必要な業務用ドメインなどを先に指定し、後続の直接接続リストに先取りされないようにします。
- 次にドメインリストを設定：判定済みの中国本土のドメインを直接接続に振り分け、ルーティング時に追加の名前解決が発生する可能性を抑えます。
- 続いてIPアドレスを判定：プライベートIPアドレスと中国本土のIPアドレスを直接接続に振り分け、IPアドレスで接続する対象もカバーします。
- 最後に一致しない接続を処理：この例では、条件なしのルールを追加せず、先頭の出力先をデフォルトとして使用します。
「中国本土は直接接続、それ以外はプロキシ」という設定で、企業やサービスの所在地を正確に判定できるわけではありません。実際にはリストによる判定とデフォルトの出力先を組み合わせています。中国本土のリストにない接続がデフォルトでプロキシ経由になるだけで、接続先がすべて海外にあると確認されたわけではありません。複数地域に分散したサービス、社内ドメイン、固定の出口が必要なサービスには、明示的な例外ルールを設定してください。
3. domainStrategyの3つの値の選び方
routing.domainStrategyは、ルーティング判定でDNSの名前解決結果をどのように使用するかを指定します。ブラウザーが使用するDNSサーバーを直接決める設定ではなく、直接接続の出力先におけるドメイン解決の設定とも異なります。設定を確認する際は、どの設定オブジェクトを変更したかを先に特定してください。項目名が同じだからといって、同じ働きをするとは限りません。
| 値 | ルーティング時の動作 | 選択の目安 |
|---|---|---|
AsIs | ルーティングのための追加の名前解決は行いません。接続先が最初からIPアドレスの場合は、IPルールで判定できます。 | ドメインルールを中心に使い、IPアドレスによる判定のためにドメインを解決する必要がない場合。 |
IPIfNonMatch | 最初の判定で一致するルールがなかった場合に、ドメインを解決してルーティングを再判定します。 | まずドメインで分類し、一致しない場合に中国本土のIPリストで補完したい場合。 |
IPOnDemand | 接続先IPが必要なルールを確認した時点で、必要に応じてドメインを解決します。 | IPアドレスの判定を早い段階で行い、DNSへの依存を許容できる場合。 |
この例ではIPIfNonMatchを選択します。geosite:cnに一致したドメインは直接接続になります。未知のドメインは、最初の判定で一致しなかった場合に限り、名前解決結果を使ってgeoip:cnに一致する可能性があります。DNSクエリの失敗、解決されたアドレスが対象リストに含まれない場合、先行するルールがすでに一致している場合などは、結果が異なります。
IPOnDemandを有効にする場合は、ルールの順序に特に注意してください。先行するIPルールが名前解決結果を使って一致すると、その後のドメイン例外は評価されません。独自のドメイン例外を先頭に置くほうが、後からIPアドレス範囲を追加し続けるより管理しやすいでしょう。
4. ルーティング設定例：中国本土は直接接続、それ以外はデフォルトでプロキシ
以下はトップレベルのroutingオブジェクトのみを示したもので、そのまま完全なクライアント設定として実行することはできません。同じ完全な設定のoutboundsに、タグがproxyのプロキシ出力先と、タグがdirectの直接接続出力先が定義され、先頭の出力先がproxyである必要があります。ノードのアドレスや認証情報、インバウンド設定は既存のクライアント設定を使用します。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": [
"full:example.com",
"domain:example.net"
],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"geoip:private",
"geoip:cn"
],
"outboundTag": "direct"
}
]
}
}- ルール1：完全一致ドメインとドメインのサフィックスに対する例外は、優先してプロキシ経由にします。実際に使う際は、用途に応じて例示項目を削除または変更してください。
- ルール2：中国本土のドメインリストに一致した接続を直接接続にします。
- ルール3：接続先がプライベートIPアドレスまたは中国本土のIPリストに含まれる場合、直接接続にします。
- デフォルトの出力先：どのルールにも一致しない接続は先頭の出力先に渡されるため、最終的に生成された設定で出力先の順序を確認してください。
この従来形式のデータを使う場合、コアが対応するgeosite.datとgeoip.datを読み込める必要があります。ファイルの欠落やパスの誤り、存在しないカテゴリ名があると、設定の読み込み時にエラーが発生することがあります。ルールデータを更新した後はコアを再読み込みしてください。データの取得元を変更する場合は、使用中のカテゴリが引き続き存在するかも確認しましょう。
5. v2rayNで適用して動作を確認
v2rayNの通常のノードモードでは、コア設定が自動生成されることが多く、一時生成されたJSONを直接編集しても、次回の再起動で上書きされる可能性があります。ルールはルーティング設定から管理してください。設定を完全にカスタマイズする場合は、専用のカスタム設定画面を使用します。デスクトップ版の画面によってボタンの位置は異なります。以下では「設定」→「ルーティング設定」から開く画面を例に説明します。
-
現在のルールをバックアップ
「設定」→「ルーティング設定」を開き、既存ルールのコピーを保存して、現在選択されているルーティングプロファイルを記録します。テストに失敗した場合に戻せるよう、元のプロファイルは削除しないでください。
-
ルールの順序を整理
ルーティング設定でテスト用のプロファイルを編集し、ドメインの例外、中国本土のドメイン、IPアドレスのルールを順番に追加します。画面のルール編集欄には各項目を個別に入力してください。トップレベルのJSON全体をドメイン入力欄に貼り付けないでください。
-
名前解決の設定を確認
プロファイルのドメイン戦略を
IPIfNonMatchに設定し、各ルールの出力先を確認します。画面から項目を変更できない場合は、生成された設定を確認してください。プロファイル名だけを見て実際の値を推測しないようにしましょう。 -
プロファイルを選択して再読み込み
編集内容を保存し、変更したルーティングプロファイルを選択してからコアを再読み込みします。編集画面で保存しただけでは、使用中のプロファイルが切り替わらない場合があります。実際に読み込まれた設定とログで確認してください。
-
出力先を個別にテスト
直接接続されるはずの接続、プロキシ経由になるはずの接続、LAN内の接続をそれぞれ確認し、ログに記録された接続先と出力先タグを記録します。テスト前に既存の接続を切断してください。ルールを変更しても、確立済みの長時間接続の出力先は自動で切り替わりません。
検証前に、通信が実際にコアへ届いていることも確認してください。アプリがシステムプロキシを使わない場合、ルーティングを設定してもその通信は制御できません。以下の数値はテスト設定の例であり、すべての環境で初期値として使えるわけではありません。現在のクライアントで待ち受けポートを確認してからコマンドを実行してください。
curl --proxy socks5h://127.0.0.1:10808 --head https://example.com/ここでのsocks5hは、接続先のドメイン名をプロキシ側で解決する指定です。ドメインルールのテストに役立ちます。ローカル側で先に名前解決する方法に変更すると、コアにIPアドレスしか届かない場合があり、結果をそのまま比較できません。このコマンドのドメインは例の1つ目のルールに一致します。ページが開けるかどうかではなく、プロキシの出力先タグを確認してください。
6. システムプロキシとTUN：通信の取り込み方に応じて確認
同じルーティング設定でも、通信を取り込む方式によって動作が異なることがあります。違いを生むのはノードではなく、コアが受け取る接続先情報です。システムプロキシでは、アプリからドメイン名が直接渡される場合があります。TUNでは通常、IPパケットとして接続が届くため、ドメイン名を復元できるかどうかはDNSの取り込みやスニッフィングなどの設定にも左右されます。
接続先情報に応じた検証方法
システムプロキシの場合
- ブラウザーやアプリがプロキシ設定を読み込んでいることを確認します。
- システム設定の影響を抑えるため、SOCKSプロキシを明示してテストします。
- まずドメインルールを確認し、一致しない接続についてIPアドレスの判定を確認します。
TUNで通信を取り込む場合
- 実際に通信を取り込んでいるコアと設定形式を確認します。
- ログにドメイン名とIPアドレスのどちらが記録されているか確認します。
- ルールを変更する前に、DNSの取り込みとLANへの接続を確認します。
まず通信がどのコアに届いているか確認し、そのコアに対応するルール形式を選んでください。この記事のJSONをすべてのTUN設定にそのまま適用することはできません。
デスクトップ版v2rayN、Android版v2rayNG、v2flyNGでは、同じ通信振り分けの目的に沿って設定できますが、メニューやタグ、インポート形式がすべて共通とは限りません。v2rayNGはXrayコアを、v2flyNGはV2Flyコアを中心に使用します。設定を移行する際は、使用中のコアが対応する項目やデータ形式を確認してください。ノードのサブスクリプションにクライアントのルーティング設定が含まれるとも限りません。
7. よくある設定ミス：ログを見て原因を絞り込む
geosite:cnを設定したのに、中国本土のサイトがプロキシ経由になるのはなぜ？
まずログの接続先がドメイン名か確認し、そのドメインが現在のデータファイルのcnカテゴリに本当に含まれているか調べます。接続先がIPアドレスだけの場合は、geoip:cnと名前解決の設定を確認してください。対象のドメインがリストにない場合は、domain:を使った明示的な直接接続ルールを追加します。未知の接続先をすべて直接接続に変更するのは避けてください。
IPIfNonMatchを設定したのにgeoipが機能しないのはなぜ？
port: "0-65535"のようなワイルドカードルールが先に一致していないか確認します。テスト用プロファイルからフォールバックルールを外し、先頭の出力先がプロキシであることを確認してから、ドメインルールに一致しない接続先でテストしてください。ルーティングに使うDNSが正常にIPアドレスを返しているかも確認が必要です。
ルールを保存したらすべての接続が失敗する場合は？
まずバックアップしたプロファイルに戻し、その後コアの起動ログを確認します。データファイルを読み込めないエラーが出た場合は、ファイルパスを修正するか該当データを更新してください。出力先タグのエラーが出た場合は、outboundTagの値が完全一致しているか確認します。設定の読み込みに失敗しているときは、先にサブスクリプションやノードを変更しないでください。
同じサイトで直接接続になったりプロキシ経由になったりする場合は？
メインドメイン、静的コンテンツのドメイン、接続先IPアドレスをそれぞれ記録し、異なるアドレスファミリーやCDNのアドレスが使われていないか確認します。既存の接続を切断してから再テストしてください。ドメイン名とIPアドレスで結果が異なる場合は、まずテスト方法を統一し、必要であればドメイン例外を追加します。
原因を調べる際は、一度に変更する項目を1つに絞ります。通信の取り込み、設定の読み込み、ルールへの一致、DNSと実際の接続の順に確認してください。一時的にログの詳細度を上げると原因を特定しやすくなりますが、ログを共有する前にサブスクリプションURLや認証情報などの機密情報を削除してください。設定項目の詳細は設定ガイドを、接続時の問題はよくある質問を参照し、順番に確認してください。