V2Rayのカスタムルーティングルール: domain・ip・geositeの構文とマッチング優先順位

ルーティングルールが処理する対象

V2RayまたはXrayのルーティングモジュールは、ノードのプロトコルを変更したり、ノード自体の帯域を向上させたりするものではありません。接続先の情報を受け取り、その接続をどのアウトバウンドへ渡すかを決定します。代表的なアウトバウンドタグは proxy、direct、block で、それぞれプロキシノードへ転送、直接接続、接続拒否を表します。タグ名は変更できますが、ルール内の outboundTag は、大小文字を含めてアウトバウンド設定の tag と完全に一致させる必要があります。

1つのリクエストで利用できるマッチング情報はドメイン名だけではありません。接続先にはIPアドレス、ポート、ネットワーク種別が含まれる場合があり、クライアントによってはプロセス名やインバウンドタグも利用できます。この記事では、特に混同しやすい domain、ip、geosite の3条件を扱います。geositeは実際には domain 配列内に記述し、独立したルールフィールドではなく、あらかじめ整理されたドメインカテゴリを参照します。

ルーティング判断の基本は「上から順に、最初に一致したルール」です。コアはルールリストを順番に読み取り、あるルールの条件がすべて成立すると、そのルールで指定されたアウトバウンドを使用し、後続のルールは確認しません。そのため、同じドメインが広告カテゴリと地域カテゴリの両方に属する場合、前に置いたブロックルールが後ろの直結ルールより先に適用されます。

domainとgeositeの記述方法の違い

domain 配列では複数のプレフィックスを利用できます。すべてのアドレスを通常の文字列で書くのではなく、完全なホスト名、ルートドメイン全体、名前に特定の文字列を含むサイトのどれを対象にするかを先に決めるのが確実です。範囲を広くしすぎると無関係なドメインまで同じアウトバウンドに送られ、狭すぎると静的リソースやAPI、ログイン用サブドメインを取りこぼすことがあります。

regexp: では正規表現を使用できます。たとえば regexp:^([a-z0-9-]+\.)*example\.com$ のように記述します。複雑なホスト名構造を表現できますが、domain: より保守の負担が大きくなります。ルートドメインとすべてのサブドメインを対象にするだけなら、domain:example.com と直接書く方が明確で、エスケープミスによるルール不成立も起こりにくくなります。

geosite:cn はcnという名前のドメインカテゴリを参照し、geosite:category-ads-all は広告関連ドメインのマッチングによく使われます。カテゴリの内容はクライアントが利用するデータファイルに由来し、ルール自体にはカテゴリ名だけを記述します。コアのアップグレード後にカテゴリが存在しないというログが出た場合は、geositeデータが完全か、カテゴリ名が現在のデータバージョンでサポートされているかを確認してください。

{
  "type": "field",
  "domain": [
    "full:api.example.com",
    "domain:static.example.com",
    "geosite:category-ads-all"
  ],
  "outboundTag": "block"
}

ip、CIDR、domainStrategyの組み合わせ方

ip フィールドには、単一のアドレス、CIDRサブネット、geoipカテゴリを記述できます。CIDRのスラッシュ後の数字はネットワークプレフィックス長を示します。たとえば 192.168.0.0/16 は 192.168.0.0 から 192.168.255.255 までを対象にし、10.0.0.0/8 は10で始まるプライベートネットワーク全体を対象にします。家庭用ルーター、ストレージ機器、LANサービスを扱う場合は、サブネットを1つずつ列挙するより geoip:private を使う方が手軽です。

ドメインリクエストをIPルールの対象にできるかどうかは、ルーティングの domainStrategy によって決まります。AsIs では元の接続先を基準に判定し、IPマッチングのためにドメインを自動解決しません。IPIfNonMatch ではドメインルールに一致しなかった後でIPを解決し、IPルールも試します。IPOnDemand では、マッチング中に接続先IPが必要なルールに到達すると、名前解決が実行されることがあります。

1. ドメインだけで振り分ける： AsIs を選び、ルーティング段階で余分な名前解決が発生しないようにします。
2. ドメインを優先し、IPで補完する： IPIfNonMatch を選び、手書きのドメインルールとgeositeカテゴリで先に振り分けます。
3. 前段のルールがIPに依存する： IPOnDemand を検討し、DNS設定から利用可能な結果が返ることを確認します。
4. LANは必ず直結する： geoip:private ルールを地域IPルールと最終プロキシフォールバックより前に置きます。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "192.168.0.0/16",
          "10.0.0.0/8"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

よくある誤りは、同じルールに domain:example.com と geoip:cn を同時に書くことです。「ドメインまたは地域IPのどちらかに一致したら直結」のつもりでも、実際には「ドメインがexample.comに属し、かつ解決結果がそのIPカテゴリに属する場合だけ直結」になります。「または」を表すには2つのルールに分け、同じ outboundTag を指定してください。

マッチング優先順位とそのまま使えるルール順序

ルールの優先順位は domain、ip、geosite の種類では決まりません。「完全一致ルールがカテゴリルールより自動的に優先される」という仕組みもありません。信頼できる唯一の優先順位は配列の順番です。カスタム例外は一括カテゴリより前に置き、ブロックルールはそれを覆う可能性のある直結・プロキシカテゴリより前に置き、最後にTCPとUDPを対象にするフォールバックルールを追加します。

以下の例では、「カスタム直結、広告ブロック、プライベートアドレス直結、地域ドメイン直結、地域IP直結、その他はプロキシ」の順に並べています。実際に使う前に、アウトバウンドタグが本当に direct、block、proxy であることを確認してください。サブスクリプションのテンプレートで別のタグが使われている場合は、タグの値だけを置き換え、条件の順序はむやみに変更しないでください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:portal.example.com",
          "domain:intranet.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "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"
      }
    ]
  }
}

フォールバックルールは、すべてのコア設定で必ず手書きする必要はありません。一致しない接続がデフォルトのアウトバウンドへ進む場合もあるためです。ただし明示的なフォールバックを置くと、設定の確認や移行が容易になります。別の設定へ移行するときも、最後のルールを見れば未分類トラフィックの行き先を判断でき、アウトバウンド配列の先頭項目を推測する必要がありません。

v2rayNでルールを登録して検証する

v2rayN 7.12.xのデスクトップ画面を例にすると、まず「設定」→「ルーティング設定」を開き、現在使用中のルールセットをコピーしてから複製した方を編集します。直接上書きせずコピーを使えば、構文エラーが起きてもすぐ元のルールへ戻せます。マイナーバージョンによってボタンの位置は変わることがありますが、確認すべき項目はルール順序、ドメインリスト、IPリスト、接続先ポート、アウトバウンドタグです。

入力が終わったら新しいルールセットを選択し、コアを再起動します。続いて「設定」→「パラメータ設定」を開き、ローカル待受ポートを確認します。一般的なローカルポートは 10808 ですが、現在の画面に表示されている値を優先してください。ポートを変更した場合は、テストコマンドも同じ値に置き換えます。システムプロキシが有効なら、カスタム直結ドメイン、プロキシ対象ドメイン、LANアドレスをそれぞれ1つずつ開き、3種類の接続が想定したアウトバウンドへ進むか確認します。

• 4種類のテスト対象を用意します：カスタム例外、geositeカテゴリ、IPサブネット、未分類ドメイン。
• 各カテゴリを3回ずつ連続してテストし、合計12件のリクエストを記録して、キャッシュや一時的な名前解決失敗を除外します。
• リアルタイムログで、接続先アドレス、一致したアウトバウンドタグ、失敗理由を確認します。
• ルールを変更したらコアを再起動し、古い接続で新ルールの有効性を判断しないでください。
• LANをテストするときは、192.168.1.1 のように機器のIPアドレスを直接入力し、privateの直結ルールに一致することを確認します。

curl --proxy socks5h://127.0.0.1:10808 https://example.com
curl --proxy socks5h://127.0.0.1:10808 https://www.example.org

socks5h の h は、プロキシ側でドメイン解決を行うことを示します。これによりコアが元のドメイン名を認識し、domainやgeositeルールを適用しやすくなります。ローカルで先に名前解決し、そのIPをプロキシへ渡すテスト方法に変えると、ログには接続先IPしか表示されないことがあり、その場合domainルールには当然一致しません。

よくある問題と切り分け方

ルールが正しそうなのに結果が合わない場合、原因は構文ではなく、現在の設定でルールが有効になっていない、想定と異なる接続先情報になっている、または前方のルールがすでに一致していることが多いです。調査では全ルールを何度も入れ替えず、まず対象ドメインを1つに絞り、ログでコアが実際に受け取ったのがドメインかIPかを確認してください。

最後に順序を確認します。手書きの例外はカテゴリより前にあるか、ブロックルールは広範囲の直結より前にあるか、privateはプロキシのフォールバックより前にあるか、domainStrategyはドメイン優先の設計に合っているかを確認してください。この4点を設定から直接読み取れるようにしておけば、後からルールを追加しても既存の振り分けを壊しにくくなります。

1. まず単一の接続先に対する full: ルールを書き、アウトバウンドタグが有効か確認します。
2. 次に domain: へ範囲を広げ、ルートドメインと2つのサブドメインで検証します。
3. geositeカテゴリを追加し、カスタム例外はカテゴリより前に残します。
4. 最後にgeoip、CIDR、TCP/UDPのフォールバックを有効にし、ログを段階的に確認します。