この記事は、ノード経由で通信でき、接続先ごとの振り分けを調整したい方向けです。まずドメインルールとIPルールの違いを確認し、「明示した例外を優先、中国国内は直接接続、それ以外はプロキシ経由」という基本形をルーティング設定で組み立てます。最後にDNS、クライアントが生成する設定、接続ログを使って意図しない振り分けを調べます。例はV2FlyとXrayでよく使われるJSON形式のルーティング構造に基づくもので、クライアント設定全体をそのまま置き換えるファイルではありません。
1. まずリクエストがコアに届いているか確認
ルーティングルールが処理するのは、コアに届いた接続だけです。v2rayNはデスクトップクライアント、v2rayNGはXrayコアを使用するAndroidクライアント、v2flyNGはV2Flyコアを使用するクライアントです。設定の管理はGUIが担いますが、実際の判定は動作中のコアが行います。VMessとVLESSはプロキシプロトコルであり、プロトコルを切り替えてもルール順の誤りは解消されません。
システムプロキシの設定が適用されるのは、通常、その設定に従うアプリだけです。アプリが独自に直接接続している場合、コアのログに該当する接続は記録されません。AndroidのVPNモードでは、アプリ単位でVPNを迂回する設定になっていることもあります。geositeの分類を追加する前に、対象アプリの接続が想定したインバウンドに届いているか確認しましょう。
10808はこの記事のテスト用に設定した値で、すべてのバージョンのデフォルト値ではありません。まずクライアントの現在のインバウンド設定で、待ち受けアドレスとポート、SOCKSが有効かどうかを確認してください。ポートはローカルの入口、443は通常リモートのWebサイト側のポートなので、混同しないようにしましょう。DNSも暗号化通信を使う場合があるため、すべての名前解決リクエストがUDP 53を使うとは限りません。
2. domain・ipとデータセットの照合対象
domainとipはルーティングルールのフィールドです。geosite:とgeoip:は、それぞれのフィールドでデータセットを参照する記法です。前者は「ドメインの所属国をリアルタイムで調べる」機能ではなく、後者もサイトの事業上の所在地を判定するものではありません。クライアントやコアに配置されたデータファイルをもとに照合するため、結果はデータの提供元や更新日に左右されます。
| ルールの記法 | 照合対象 | 適用範囲 |
|---|---|---|
full:example.com | 完全一致のドメイン | 指定したドメインだけに一致し、サブドメインは含まない |
domain:example.com | ドメインとサブドメイン | example.comとwww.example.comを含む |
geosite:cn | データセットに登録されたドメイン分類 | 中国国内のすべてのサービスドメインが含まれるとは限らない |
192.168.0.0/16 | IPv4アドレス範囲 | 照合対象となるIPアドレスが必要 |
geoip:cn | データセットに登録されたアドレス範囲 | 利用者の実際の所在地を特定するものではない |
ドメインの範囲を明確に指定したい場合は、full:またはdomain:を使いましょう。プレフィックスのない通常の文字列は部分一致として扱われることが多く、名前が似ているだけの無関係なドメインまで一致するおそれがあります。分類名が実際にインストール済みのデータファイルに存在するかも確認してください。他の環境から分類名をコピーしても、手元のデータファイルに含まれているとは限りません。
判断の目安：サービス単位の例外にはドメイン、アドレス範囲にはIP
特定のサイトの接続先を固定したい場合は、まず対象を明示したドメインルールを設定します。ローカルネットワークへの接続には、アドレス範囲のルールを使いましょう。CDNの単一の解決先IPを、サービス全体のドメインの代わりに使わないでください。
3. ルールは上から順に評価され、細かさでは並べ替えられない
一般的なfieldルールは上から順に評価され、最初に条件を満たしたルールのアウトバウンドが適用されます。下にあるルールのほうが具体的でも、コアが上の広いルールを自動で上書きすることはありません。そのため、手動で指定する例外を分類ルールより上に、分類ルールをデフォルトの動作より上に配置します。
- 明示した例外を最初に：たとえば、直結対象の分類にも含まれるテスト用ドメインを、必ずプロキシ経由にしたい場合です。
- 次にローカル・分類ルール：プライベートアドレス、中国国内のドメイン、中国国内のアドレス範囲などを指定します。
- 最後にデフォルトの接続先を設定：どのルールにも一致しない場合は、設定で指定したフォールバック経路を使います。
1つのルール内にあるdomain配列の複数項目は、いずれかに一致すれば条件を満たします。一方、異なる条件フィールドを同じルールに入れると、通常はすべての条件を満たす必要があります。たとえばdomainとportを指定した場合は、ドメインとポートの両方が条件に合う必要があり、「ドメインまたはポートのどちらか」ではありません。ドメイン分類とアドレス分類をそれぞれ独立した直結条件にする場合は、ルールを分けてください。
4. 中国国内は直結、それ以外はプロキシ経由にするルーティング例
以下に示すのはroutingオブジェクトのみです。既存の設定に、directというタグの直結アウトバウンドと、proxyというタグのプロキシアウトバウンドがあることを前提としています。また、未一致時のデフォルトアウトバウンドとしてproxyをoutbounds配列の先頭に置きます。タグは設定間の参照に使われるため、画面に「直結」と表示されているだけで、内部タグもdirectだとは限りません。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["full:example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
}
]
}
}example.comは例外ルールの優先順位を説明するための予約済みサンプルドメインであり、実際の利用を推奨するものではありません。この設定では、指定したドメインはプロキシ経由、認識可能なプライベート宛先は直接接続、中国国内のドメインまたはアドレス分類に一致する接続も直接接続、それ以外は先頭のプロキシアウトバウンドを使います。これは一つの方針例であり、すべてのネットワーク環境に適した固定設定ではありません。
- データファイル：対応する分類を含む利用可能なgeosite・geoipデータファイルが必要です。読み込みに失敗する場合は、まず起動時のエラーを解消してください。
- ローカルネットワークへの接続：
geoip:privateはデータセット内の特殊なアドレス分類です。直結を許可する前に、ローカルネットワークへのアクセスが自身の分離・隔離要件に合っているか確認してください。 - デフォルト設定：クライアントが生成する設定で先頭のアウトバウンドがproxyではない場合は、デフォルトの接続先設定を調整してください。そのままコピーしても、残りの接続が必ずプロキシ経由になるとは限りません。
- インポート形式：ルーティングエディターがrules配列だけを受け付ける場合があります。カスタム設定全体を読み込むには、インバウンドやアウトバウンドなども必要です。先にインポート形式を確認してください。
5. domainStrategyとDNSの関係
AsIsはルーティングのためにドメインを追加で名前解決しません。インバウンドからドメインが渡される場合、IPルールだけでは通常照合できません。IPIfNonMatchは、ドメインがルールに一致しない場合に名前解決を試み、そのIPを使って照合します。IPOnDemandは、IPが必要なルールに遭遇した時点で名前解決を行うことがあります。解決のタイミングが異なるため、先行するIPルールが評価に参加できるかどうかも変わります。
| 方式 | ルーティング時の名前解決タイミング | 設定時の注意点 |
|---|---|---|
AsIs | ルーティング用の追加の名前解決を行わない | 主にドメインルールまたは既知の接続先IPで照合 |
IPIfNonMatch | ドメインが一致しない場合に名前解決を試行 | 先行する広範なドメインルールにより、IPルールが評価されないことがある |
IPOnDemand | IPが必要な条件を照合するとき | 先行するIPルールと名前解決結果の影響に注意 |
上記の設定例では、ドメインルールに一致しなかったリクエストだけが、名前解決結果を使ってgeoip:cnに一致する可能性があります。rulesの末尾にすべてのドメインに一致するプロキシルールを追加すると、ドメインの段階で一致が確定するため、IPIfNonMatchは「まだ一致していない」場合のIPフォールバックを行いません。このフォールバックを残すには、全件一致ルールを安易に追加せず、デフォルトアウトバウンドを使ってください。
ルーティング用の名前解決方式と、最終アウトバウンドが接続先を解決する方法は別の設定です。ルーティングがAsIsでも、直結アウトバウンドでドメインの名前解決が必要になる場合があります。DNSが返すCDNの地域別アドレスや、IPv4のみ・IPv6を含む応答によって、アドレス分類の結果が変わることもあります。Webページが開くかどうかだけで判断せず、ドメイン、解決結果、アウトバウンドタグをそれぞれ記録してください。
手順：まずドメインルールを維持し、次にIPフォールバックを検証
まず明示的なドメインルールで、正しいアウトバウンドタグが使われることを確認します。その後、一時ルールを外してIPフォールバックをテストしてください。一度に変更する条件を一つに絞ると、ドメイン分類の不足、DNS応答の変化、ルール順の問題を切り分けやすくなります。
6. 決まった手順でルールの競合を調べる
v2rayNでは「設定」→「ルーティング設定」を開き、有効なルールセットを確認します。バージョンによってメニュー名が異なる場合があるため、実際の画面に従ってください。v2rayNGとv2flyNGでは、それぞれのルーティング設定と現在の実行設定を確認します。他のクライアントの画面項目名をそのまま当てはめないでください。異なるコア間で設定をコピーする場合は、フィールドとデータファイルの形式に互換性があるかも確認しましょう。
- 現在の状態を記録：コア名、ルーティングモード、ルールの順番、ローカルの待ち受けポートを保存します。まずプロキシノードに接続できることを確認してください。
- インバウンドを確認：デスクトップでは以下のコマンドを使い、ローカルのSOCKS入口を明示して、ドメインの処理をプロキシに任せます。ポートは実際の設定値に置き換えてください。
- アウトバウンドを確認：クライアントの接続ログまたはアクセスログで、テスト用ドメイン、接続先IP、アウトバウンドタグを探します。ログの形式はコアのバージョンによって異なります。
- ルールを切り分け：テスト用ドメインのfullルールを一時的に先頭へ移動し、directとproxyそれぞれに向けて試します。これに応じてアウトバウンドが変われば、ルーティングへの入口とタグはおおむね機能しています。
- 分類ルールを戻して確認：一時ルールを削除し、中国国内のサービスドメイン、その他のドメイン、ローカルアドレスをそれぞれテストして、分類とフォールバックの動作を確認します。
curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/ここでいう10秒は接続フェーズのタイムアウト、20秒はコマンド全体の制限時間であり、性能テストの結果ではありません。--socks5-hostnameを使う場合は、ローカルで名前解決してからIPを渡す方法とはテスト経路が異なるため、ドメインルールの検証に適しています。HTTPリクエストに成功しても、その経路が使えると確認できるだけです。UDP、すべてのアプリ、TUNによる通信の取り込みも正しく設定されているとは限りません。
7. geosite・geoipによる振り分けのよくある質問
geosite:cnを追加したのに、中国国内のサイトがプロキシ経由になるのはなぜ？
まず接続で実際に使われているドメインを確認してください。Webページ本体と別のドメインからリソースを読み込む場合があります。次に、分類データにそのドメインが含まれているか、現在のモードで該当ルールセットが有効かを確認します。対象ドメインをfullルールとして先頭に置いてテストし、継続的に直結させる必要があると確認できたら、適切な範囲のdomainルールに変更します。
geoip:cnが一致しないのはなぜ？
インバウンドから渡されるのがドメインかIPかを確認してください。AsIsでドメインしかない場合、IP条件を照合する材料がありません。IPIfNonMatchを使っている場合は、先行するドメインルールや全件一致ルールによって判定が先に終了していないか確認します。そのうえで、実際の解決先IPが対象のアドレスセットに含まれているか確認してください。
サブスクリプションを更新すると、カスタムの振り分け設定も変わりますか？
サブスクリプションでは通常ノード一覧が更新され、ルーティングルールや地域別データは別の画面で管理されることが多いものの、実際の動作はクライアントとサブスクリプション形式によって異なります。更新後は現在のノード、有効なルーティングセット、生成された設定を確認してください。手動ルールを残す必要がある場合は、設定をエクスポートしてバックアップします。サブスクリプションURLだけを保存するのは避けてください。
スニッフィングを有効にすれば、すべてのIP接続をドメインで振り分けられますか？
そのようには考えないでください。スニッフィングでドメインを取得できるのは、対応していて識別可能な通信に限られ、結果はプロトコルとコアの設定によって異なります。まずはドメインを渡せるプロキシ入口にアプリから接続してください。スニッフィングが必要な場合は、対象範囲や「ルーティングのみに使用」といったオプションが、利用中のバージョンでサポートされているか確認しましょう。
安定した振り分け設定に必要なのはルールの数ではなく、各ルールの適用範囲が明確で、ログから結果を説明できることです。少数の例外ルール、分類ルール、デフォルトの接続先から始め、実際に誤振り分けが起きた箇所だけを修正しましょう。重複するルールを一度に大量に読み込むより、変更の追跡が容易です。クライアントとコアの役割分担については、プロトコル解説と用語のクイックリファレンスもご覧ください。