ノードをインポート済みで、直結とプロキシの振り分けを調整したい方に向けた記事です。ドメインとIPのマッチングを区別し、設定例を使ってルール順序、名前解決の方針、デフォルトのアウトバウンドを解説します。特に、キーワードマッチングは通常その文字列を直接指定します。説明上のkeywordを汎用的なJSONプレフィックスとして使わないでください。例では接続可能なプロキシノードではなく、サンプルドメインを使用しています。
1. ルーティングは接続先の振り分けを決める。ノードは作成しない
V2Rayのルーティングは、接続の宛先アドレス、ポート、ネットワーク種別などを参照し、接続をいずれかのアウトバウンドに振り分けます。サブスクリプションをノードに変換する機能はなく、outboundTag: "proxy"と書いてもプロキシサーバーが自動生成されるわけではありません。タグは参照用の名前です。現在の設定のoutboundsに、対応するtagが必要です。
ドメインルールが機能するかどうかは、コアがドメイン名を取得できているかにも左右されます。アプリがSOCKS経由でドメイン名を渡す場合、コアはそのまま照合できます。一方、アプリが先に名前解決してIPアドレスを渡すと、ドメイン情報が失われていることがあります。トラフィックのスニッフィングで一部のプロトコルからホスト名を識別できる場合はありますが、暗号化された通信のすべてでドメイン名を復元できるわけではありません。DNSの代わりとして扱うこともできません。
routing.rules：配列の順番に評価されるルール一覧。type: "field"：この記事で使うフィールド照合ルールのタイプ。outboundTag：マッチ後に選択するアウトバウンドタグ。大文字と小文字は区別されます。domainStrategy：ルーティング時にドメインへIP情報を補完するタイミング。DNSサーバーのアドレスとは別の設定です。
2. domainの4つの書き方：完全一致、サブドメイン、キーワード、正規表現
domainは文字列の配列です。同じ配列内の項目はOR条件で、どれか1つに一致すればマッチします。境界の違いを示すため、以下ではexample.comを例にします。ドメイン項目に完全なURLやパス、クエリパラメーターを入れないでください。ルーティングで照合するのは、ブラウザーのアドレスバーに表示されるURL全体ではありません。
| 書き方 | マッチする範囲 | 境界の説明 |
|---|---|---|
full:example.com | example.comのみ | www.example.comは含まない |
domain:example.com | ルートドメインとそのサブドメイン | notexample.comにはマッチしない |
example | ドメイン名にexampleを含む文字列 | notexample.netにもマッチする場合がある |
regexp:^api[0-9]+\.example\.com$ | apiの後に数字が続く特定のサブドメイン | JSONではバックスラッシュをエスケープする |
{
"type": "field",
"domain": [
"full:login.example.com",
"domain:static.example.com",
"regexp:^api[0-9]+\\.example\\.com$"
],
"outboundTag": "proxy"
}上の正規表現はJSON文字列なので、正規表現内のバックスラッシュ1つをJSONでは2つ書きます。^と$で文字列の先頭と末尾を指定し、ドメインの一部分だけにマッチするのを防ぎます。サイト全体の振り分けだけが必要なら、範囲の広いキーワードや複雑な正規表現より、domain:を使うほうが確認しやすくなります。
3. geositeとgeoip：分類データから自動判定されるわけではない
geositeはドメイン分類を参照し、domain配列に指定します。geoipはIP分類を参照し、ip配列に指定します。どちらも、コアが読み込めるデータファイルと、ファイルに実際に含まれる分類に依存します。分類名を書くだけでオンライン検索されたり、不足しているデータが自動ダウンロードされたりすることはありません。
ドメイン分類ルール
- ルールのフィールド
domain- 項目の例
geosite:cn- よく使われるデータファイル
geosite.dat- 照合基準
- データセットに登録されたドメインルール
分類の内容はデータファイルによって決まり、サーバーの所在地を示すものではありません。
IP分類ルール
- ルールのフィールド
ip- 項目の例
geoip:private- よく使われるデータファイル
geoip.dat- 照合基準
- データセットに登録されたIPアドレス範囲
例に使う分類が現在のデータファイルに存在するか確認してください。読み込みエラーが出た場合は、まずファイルと分類名を確認します。
ドメインがある分類に属していても、そのすべてのCDNアドレスが同じ地域のIPになるとは限りません。逆に、あるIPが地域分類に登録されていても、そのIPを使うすべてのドメインを直結にすべきとは限りません。明示的に制御したいサービスのドメインは、個別ルールにして広範な分類ルールより前に配置してください。
- コアの起動時に「ファイルが見つかりません」と表示される：実際の実行ディレクトリ、リソースパス、クライアントのデータファイル設定を確認します。
- 分類が見つからないと表示される：現在のデータファイルに含まれるタグを確認してください。別のデータパッケージの説明から分類名を推測しないでください。
- 更新後に結果が変わった：まず分類の内容を比較し、その後でルール順序が変わったかを確認します。
4. ip・CIDR・ポート：同じフィールドはOR、異なるフィールドはAND
ipには、単一アドレス、CIDR範囲、対応するデータセット参照を指定できます。CIDRのスラッシュ以降の数字はプレフィックス長であり、ポート番号ではありません。以下の3つの数値は入力形式の境界を確認するためのもので、ネットワーク速度の測定結果ではありません。
{
"type": "field",
"ip": [
"192.168.0.0/16",
"10.0.0.0/8",
"fc00::/7"
],
"port": "443",
"network": "tcp",
"outboundTag": "direct"
}このルールで直結になるのは、「宛先IPが3つの範囲のいずれかに含まれる」「宛先ポートが443」「ネットワーク種別がTCP」のすべてを満たす接続だけです。プライベートネットワーク宛ての通信をすべて直結にする設定ではありません。ポート80へのアクセスやUDPサービスは、後続のルールで引き続き照合されます。
同じルールにdomainを加えても、「ドメインまたはIPのどちらかに一致すればよい」というOR条件にはなりません。同時に満たす必要がある条件が1つ増えます。特に、宛先が最初はドメイン名で、まだ名前解決されていない場合、この組み合わせは想定と異なる結果になりやすいです。「指定したドメインを直結、または指定したIPを直結」としたい場合は、ルールを2つに分けてください。
ポイント：条件をまとめる前に、ルールを分ける
ドメインの例外とIP範囲の例外をそれぞれ独立したルールにし、個別にマッチすることを確認してから、ポートやネットワーク種別を組み合わせる必要が本当にあるか検討してください。
5. ルールは上から順に評価される。「具体的なルールほど優先」ではない
1回のルール評価では、先にマッチしたルールがアウトバウンドを決定し、後続のルールが判定を上書きすることはありません。コアがfull:をgeosite:より前に自動で移動したり、ドメイン名が長いルールを優先したりすることもありません。個別の例外、サービスごとのルール、広範な分類、最後のフォールバックの順序は、設定する側が明示的に決める必要があります。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["full:login.example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}以下は統合して使うためのrouting部分で、クライアント設定全体ではありません。proxyとdirectのアウトバウンドがすでにあり、通常directにはfreedomプロトコルが使われていることを前提としています。1つ目のルールではログイン用ドメインをプロキシに通し、2つ目ではそれ以外のルートドメインとサブドメインを直結します。2つのルールを入れ替えると、ログイン用ドメインは先に2つ目のルールにマッチします。
- まずドメインを評価し、マッチしない場合にIPルールを試すには、
IPIfNonMatchを使い、すべての通信に先にマッチするフォールバックルールを避けてください。 - IPルールまで評価された時点で名前解決を試みるには、
IPOnDemandを検討し、DNSリクエストの増加や待ち時間も考慮してください。 - すべてにマッチするフォールバックを設定しない場合：
outboundsの先頭項目を確認します。どのルールにもマッチしない通信は、最初のアウトバウンドが使われます。タグ名自体に特別なデフォルト動作はありません。
6. domainStrategyとDNS：まず宛先の種類を確認する
同じルールでも、ブラウザーでは問題なく動作する一方、別のプログラムでは挙動が異なることがあります。原因はルールが無視されていることではなく、2つのプログラムが異なる宛先を渡していることかもしれません。一方はドメイン名、もう一方は名前解決済みのIPアドレスを渡しているケースです。ルーティングの名前解決方針が制御するのは、ルーティング判定に必要な名前解決の動作だけです。アプリ、OS、コアが同じDNSを使うことを保証するものではありません。
| 方針 | 名前解決のタイミング | 確認ポイント |
|---|---|---|
AsIs | ルーティング時にドメインのIPを自動補完しない | 元の宛先がドメイン名の場合、IP分類による振り分けに依存できない |
IPIfNonMatch | ドメインが最初のルール評価でマッチしなかった場合に名前解決し、再度照合する | 先にすべてにマッチするルールがあると、2回目の評価に進まない |
IPOnDemand | ドメイン宛ての通信がIP判定を必要とするルールに到達したときに名前解決する | IPルールの位置とDNSへの接続可否のどちらも結果に影響する |
ルーティングを変更しても、既存の長時間接続では通常アウトバウンドが再選択されません。テスト対象のアプリで既存の接続を閉じてから、新しいリクエストを送ってください。必要に応じてコアを再起動します。DNS、スニッフィング、ルール順序を同時に変更すると、どの変更が結果に影響したか判断しにくくなります。1回に変更するのは1項目にし、元に戻せる設定のコピーを保管してください。
7. クライアントへの設定と、ルールが反映されない場合の確認
v2rayNはデスクトップクライアントです。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。この記事の設定例では、どちらのコアでもよく使われる標準ルーティング項目を扱いますが、すべての拡張構文、データファイル、画面からのインポート形式が完全に共通とは限りません。クライアントに保存されるルール項目と、最終的に生成されるコア用JSONのファイル形式も異なる場合があります。
- 現在の設定をバックアップする。v2rayNの「設定」→「ルーティング設定」で、現在有効なルーティング設定を確認します。バージョンによってメニュー名や場所が多少異なる場合があります。まず設定を複製してから、明確な
full:の例外ルールを1つ追加してください。 - 生成された設定を確認する。実際に実行されている設定で、
routing.rulesの順序、outboundsのタグ、グローバルプロキシやグローバル直結モードによって設定が置き換えられていないかを確認します。 - ルール入力欄と完全な設定を区別する。v2rayNGの「設定」→「ルーティング設定」では、よく使うドメインやIPの振り分け項目を確認できます。ただし、これらの入力欄は標準JSONエディターではありません。順序が重要な複雑なルールには、現在のバージョンが明確にサポートしているカスタム設定方法を使ってください。
- 接続をやり直す。設定を適用してサービスを再起動し、実行ログを確認します。ページを再読み込みするだけでは、古い接続が使われ続けることがあります。ログレベルが低く、ルーティングの詳細が表示されない場合は、テスト中だけ一時的に上げ、完了後に戻してください。
ドメインを設定したのに、なぜプロキシ経由になる？
まず、そのルールがプロキシのフォールバックより前にあることを確認し、一時的に単一のfull:ルールにしてテストします。コアが受け取った宛先がドメイン名かIPアドレスかも確認してください。IPアドレスしか届いていない場合、ドメイン情報の欠落はドメイン項目を追加しても解決できません。
geositeを追加したらサービスが起動しない場合は？
まず直前の設定に戻し、ログで問題の分類名とファイルパスを特定します。データファイルが読み込めることと、分類が存在することを確認してからルールを追加してください。分類名を次々に入れ替えて試すのは避けましょう。
ルールは保存されたのに、何も変わらないのはなぜ？
編集中のルーティング設定が現在有効になっているか、グローバルモードに上書きされていないかを確認します。コアを再起動して新しい接続を確立し、入力欄の表示だけでなく、実際の設定に記載されたアウトバウンドタグを確認してください。
すべての条件を1つのルールにまとめてもいい？
すべての条件を同時に満たす必要がある場合に限り、まとめて指定します。ドメイン、IP、ポート、ネットワーク種別を同時に設定するとAND条件になります。個別の例外を複数表したい場合はルールを分け、明示的な例外を先に評価する順序で並べてください。
最後に、新しい接続を3つ使って設定を検証します。完全一致する例外ドメイン、通常のサブドメイン、既知のプライベートIPをそれぞれ確認し、宛先の形式、マッチしたルール、アウトバウンドタグを記録してください。これにより、「構文を読み込める」「ルールが実際にマッチする」「アウトバウンド自体が接続できる」を分けて確認でき、ノードの障害をルーティングの不具合と誤認しにくくなります。用語は用語集、設定の詳細は高度な設定をご覧ください。