サブスクリプションを追加済みで、v2rayNのルールを調整したい方向けです。まずドメインとIPのマッチ条件を整理し、「個別の例外、カテゴリ別ルール、最終的なフォールバック」の順に設定します。例ではV2Ray/Xrayのfield形式を使い、編集可能なJSONを紹介します。適用前に使用中のコア、outboundのタグ、ルールデータベースを確認してください。ここにある断片は完全なクライアント設定ではなく、そのまま実行できません。
1. ルーティングルールの基本
ルーティングはサブスクリプションのノード一覧とは別の機能です。サブスクリプションにはサーバーへの接続情報が含まれ、ルーティングは接続をどのoutboundに渡すかを決めます。VMessやVLESSのノードを変更しても、誤ったドメイン条件が直るわけではありません。ここではタグをdirect、proxy、blockとし、それぞれ直接接続、プロキシ、ブロックを表します。これらのタグは、実際の設定にあるoutboundと一致させてください。
最もシンプルなルールでは、「何にマッチさせるか」と「どこへ渡すか」を指定します。次のオブジェクトはexample.comとそのサブドメインをプロキシoutboundに渡します。これはrouting.rules配列の要素の1つであり、完全な設定ではありません。本文中のexample.comは構文説明用です。実際に使う際は対象のドメインに置き換えてください。
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "proxy"
}type: "field"：接続の属性に基づいてマッチします。domain：ドメイン条件の配列です。ipにはIPアドレス、CIDR、IPカテゴリを指定します。outboundTag：既存のoutboundタグを指定します。新しいoutboundは作成されません。- 同じフィールド内の複数項目は通常「OR」、1つのルール内にある異なる条件フィールドは「AND」で評価されます。
たとえば、domainとport: "443"を同じオブジェクトに指定すると、ドメインが一致し、かつ接続先ポートが443の場合にマッチします。どちらか一方でマッチするわけではありません。「ドメインまたはIP」の条件にしたい場合は、2つのルールに分けるのが一般的です。
2. domain・full・regexpの使い分け
domainはJSONのフィールド名であると同時に、フィールド内で使うマッチング接頭辞の1つでもあります。混同しないようにしましょう。フィールドに通常の文字列を指定すると部分一致となり、想定以上に広くマッチすることがあります。特定のサイトとそのサブドメインを指定する場合は、domain:を使うのがおすすめです。
| 記法 | マッチ範囲 | 注意点 |
|---|---|---|
full:api.example.com | 指定した完全一致のドメインのみ | サブドメインは対象外 |
domain:example.com | ルートドメインとそのサブドメイン | notexample.comにはマッチしません |
example.com | ドメインにこの文字列を含むもの | マッチ範囲が広くなる場合があります |
regexp:... | 正規表現に一致するドメイン | アンカーとJSONのエスケープに注意 |
geosite:cn | ドメインデータベースのcnカテゴリ | 読み込んだデータベースの内容に依存します |
ドメインフィールドでは、Webページのパスを指定できません。https://api.example.com/v1/itemsにマッチさせる場合は、full:api.example.comと指定します。プロトコルやスラッシュ、パスを含めないでください。通常のルーティングでは、このフィールドを使って同じHTTPSサイト内のページごとに振り分けることもできません。
{
"type": "field",
"domain": [
"full:api.example.com",
"domain:static.example.com",
"regexp:^edge[0-9]+\\.example\\.net$"
],
"outboundTag": "proxy"
}ここに示す3つの条件は「OR」です。いずれか1つにマッチすればプロキシが選択されます。正規表現は、edge1.example.netやedge23.example.netのような番号付きドメインに使います。JSON内の\\.は、読み込み後に正規表現の\.になります。バックスラッシュを1つ省くと、構文エラーや意図しないマッチにつながることがあります。
3. ip・geoip・geositeの違い
geositeはドメインを分類し、geoipはIPを分類します。参照するデータが異なるため、互いに置き換えることはできません。geosite:cnは「名前解決したIPが中国本土にあるすべてのドメイン」を意味するわけではありません。また、geoip:cnも、サーバーのコンテンツが必ず中国本土のWebサイトであることを示すものではありません。CDNや共有IPアドレス、データベースの更新によって結果が変わる場合があります。
ドメインカテゴリのルール
- 項目
domain- 例
geosite:cn- データソース
- 読み込まれたgeositeドメインデータベース
- マッチ対象
- 接続で利用できる宛先ドメイン
カテゴリが存在することを確認してから、対象のドメインが登録されているか確認してください。カテゴリが自動でリアルタイム判定されるわけではありません。
IPカテゴリのルール
- 項目
ip- 例
geoip:cn- データソース
- 読み込まれたgeoipアドレスデータベース
- マッチ対象
- 宛先IP、またはルーティング時の名前解決で得られたアドレス
ドメイン接続の名前解決が行われるかは、domainStrategyなどの設定によって異なります。
明確なLAN用ネットワーク範囲はCIDRで直接指定し、サイトカテゴリだけにローカル機器への接続を任せないようにしましょう。次の例では、一般的なIPv4プライベートネットワーク3つを直接接続にします。すべての特殊用途アドレスやIPv6のローカルアドレスを網羅しているわけではありません。より広い範囲を指定する場合は、データベースのgeoip:privateを使い、実際の登録内容を確認してください。
{
"type": "field",
"ip": [
"10.0.0.0/8",
"172.16.0.0/12",
"192.168.0.0/16"
],
"outboundTag": "direct"
}これらはアドレスとプロトコルに関する基本情報であり、通信速度の測定結果ではありません。ポート条件は接続先のポートに適用されます。たとえば"port": "443"は、v2rayNのローカル待ち受けポートではありません。443だけで振り分けると多くのWebサイトに影響するため、通常はドメインなどの条件と組み合わせて使います。
4. 優先順位：最初にマッチしたルールを適用
ルールは配列の上から順に評価され、1つにマッチすると対応するoutboundが選択されます。後続に「より正確な」ルールがあっても評価は続きません。完全一致のドメインが先行するカテゴリルールより自動的に優先されることも、長いネットワーク範囲が短い範囲より先に評価されることもありません。個別の例外は、広い範囲のルールより前に配置してください。
- 個別の例外を先に配置：特定のドメインをブロックしたり、特定のサービスを必ずプロキシ経由にしたりします。
- ローカル接続を配置：プライベートアドレスを直接接続にし、LAN機器へのアクセスに影響が出ないようにします。
- カテゴリ別の振り分けを配置：geositeやgeoipなどのカテゴリで、多くの接続を処理します。
- 最後にフォールバックを配置：残りのTCP・UDP接続の経路を明示します。
次はroutingの設定例です。既存のinboundやoutboundなどの設定と統合して使ってください。例では、まずテレメトリ用のドメインをブロックし、続いてLANとcnカテゴリを直接接続にして、残りの通信をプロキシに渡します。不要なルールを削除する際は、JSONのカンマ位置も確認してください。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["full:telemetry.example.com"],
"outboundTag": "block"
},
{
"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"
}
]
}
}どのルールにもマッチしない場合、通常はoutbound一覧の先頭が使われます。proxyという名前のoutboundが必ず選ばれるわけではありません。フォールバックを明示すると設定は読みやすくなりますが、マッチ動作も変わります。フォールバックを削除する場合も、outboundの順序を必ず確認してください。プロキシ接続に失敗したときの自動切り替えには別の仕組みが必要です。通常のルーティングルールは、次のルールで自動的に再試行しません。
5. domainStrategyで名前解決のタイミングを決める
ドメインルールはドメインを、IPルールはアドレスを対象にします。アプリがプロキシプロトコル経由でドメインを送信した場合、コアが宛先IPを取得しているとは限りません。routing.domainStrategyは、ルーティング時にマッチングのための名前解決を行うかどうかを決めます。DNSサーバーの選択と同じものではなく、outbound側にある同名のオプションとも区別してください。
| 方針 | 名前解決のタイミング | 注意点 |
|---|---|---|
AsIs | ルーティング時に、マッチングのための名前解決を行わない | 宛先がドメイン名だけの場合、名前解決後の結果を使ったIPルールにはマッチしません |
IPIfNonMatch | ドメインがどのルールにもマッチしない場合に名前解決し、再度マッチングする | 先にマッチしたフォールバックが追加の名前解決を妨げます |
IPOnDemand | IPが必要なルールの評価時に名前解決を試みる | 前方にあるIPルールによってDNS問い合わせが増え、早い段階で振り分けられる場合があります |
特定のサービスのドメインを必ずプロキシ経由にする場合は、そのfull:またはdomain:ルールをgeoip:cnより前に配置してください。IPOnDemandでは、IPカテゴリを先に置くと、ドメインの名前解決後にcnアドレスと判定されて直接接続に振り分けられ、後続のドメイン例外が評価されない場合があります。
- ドメインカテゴリを優先するのか、名前解決したアドレスを優先するのかを決めてから、ルールの順序を設定しましょう。
- コアのDNS設定で、名前解決サーバーと振り分け方を確認してください。方針を変更しても、DNSリゾルバーは自動で切り替わりません。
- アプリが独自に名前解決してIPだけを送信する場合、ドメインルールにマッチしない可能性があります。スニッフィングで一部のドメイン情報を復元できることはありますが、すべての通信で機能するとは限りません。
- UDP、暗号化DNS、共有CDNアドレスを使う場合は、それぞれ個別に確認してください。ブラウザーでWebページを1つ開いただけで、すべて正しいと判断することはできません。
6. v2rayNで適用・検証する
v2rayNはデスクトップクライアントで、ルールは選択中のコアが実行します。この記事はV2Ray/XrayのJSON構造を対象としています。ルールを編集する前に、v2rayNのバージョンと使用中のコアを確認してください。バージョンによって編集画面や項目名が異なる場合があります。コア用のJSONオブジェクトを、ドメイン一覧だけを受け付ける入力欄に貼り付けないでください。
- 現在の設定をバックアップする。使用中のルーティング設定とデフォルトoutboundを保存します。デスクトップ版では「設定」→「ルーティング設定」から開ける場合が一般的です。使用中のバージョンで場所が異なる場合は、ルーティング設定の管理画面を探してください。振り分けを試すためにサブスクリプションURLを変更しないでください。
- タグを確認する。設定エディターまたは生成されたコア設定で、
outboundsのtagを確認します。例にあるdirect、proxy、blockを、実際のタグに対応させてください。 - 例外を1つだけ追加する。まず完全一致のドメインを1つ使ってテストし、カテゴリルールより前に配置します。保存後、このルーティング設定を選択して、クライアントに設定を再生成させ、コアを再起動します。
- 起動ログを確認する。JSONの解析エラー、カテゴリの欠落、outboundタグが見つからないなどのエラーがないことを確認してから、接続をテストします。
- 新しい接続で検証する。既存のページ接続を終了し、リクエストを新しく送信します。アクセスログに記録された接続先とoutboundタグを確認してください。ログに表示されない場合は、一時的にログの詳細度を上げます。
- 段階的に追加する。問題なく動作したら、geosite、geoip、フォールバックのルールを追加します。設定を1段階増やすごとに、元に戻せる状態を保ってください。
テスト対象として、直接接続するサイト、プロキシ経由にするサイト、LAN機器の3種類を用意してください。ブロックをテストする場合は、制御可能なテスト用ドメインも追加します。ルールの対象になるのは、そのコアを経由する接続だけです。アプリがシステムプロキシを使わず通信している場合、ルールが正しくてもマッチ記録は残りません。システムプロキシの適用範囲はシステムプロキシの使い方も確認してください。
7. ルールが動作しないときによくある4つの原因
fullルールを追加したのに、なぜ直接接続になる？
まず、上位にあるgeosite:cn、geoip:cn、または全通信を対象にするルールが先にマッチしていないか確認します。完全一致のドメイン例外をこれらのルールより前に移し、保存してから接続し直してください。接続でアプリが事前に名前解決したIPではなく、ドメインが実際に渡されているかも確認しましょう。
geositeを追加したら、コアが起動しなくなったのはなぜ？
ログにカテゴリが存在しない、またはデータファイルを読み込めないというエラーがないか確認します。現在のデータベースに指定したカテゴリが含まれていることを確認し、クライアントのルールデータ更新機能から更新してください。カテゴリ名が妥当に見えるだけで使わないようにしましょう。まず追加した項目を削除して起動できる状態に戻し、その後1項目ずつ確認します。
ドメインとIPを同じルールに書いたのに、マッチしないのはなぜ？
異なるフィールドは「AND」条件になり、ドメインの名前解決条件も関係する場合があります。どちらか一方にマッチさせたい場合はルールを2つに分け、同じoutboundTagを指定してください。両方の条件を満たす必要がある場合は、アドレスが有効かどうかとdomainStrategyの動作を確認します。
ルールを変更したのに、ブラウザーが古い経路を使うのはなぜ？
ルーティングは通常、新しい接続を確立するときに決まります。すでに確立している長時間接続では、outboundが再選択されない場合があります。変更したルーティング設定が選択されていることを確認し、対象アプリの接続を終了してください。必要に応じてコアを再起動してから再試行します。ログにリクエストがまったくない場合は、アプリがプロキシの入口を通っているか確認してください。
設定には、少数のわかりやすいルールを保ちましょう。個別の例外、ローカルアドレスとカテゴリ、最後に明示的なフォールバックの順にします。問題が発生したら、「接続がコアに届いているか」「接続先はドメインかIPか」「どのルールが先にマッチしたか」「タグが存在するか」の順に確認すると、ルールを追加し続けるより原因を特定しやすくなります。