V2Rayのカスタムルーティング設定ガイド：domain・ip・geositeの書き方とルールの優先順位

1. ルーティングの対象と評価順序

V2Rayのroutingは、接続先のアドレスやポート、ネットワーク種別、インバウンドタグなどに基づいてアウトバウンドを選択します。Webページの内容をフィルタリングする機能ではなく、URLのパスによる振り分けにも対応しません。同じドメイン内の異なるページにアクセスしても、通常はドメインルールの判定は変わりません。

routing.rulesは配列の先頭から順に評価されます。条件に合うルールが見つかると、そのルールで指定されたアウトバウンドが使われ、後続ルールとの「どちらがより詳細か」という比較は行われません。そのため、特定ドメインの例外はドメインサフィックスのルールより前に、個別ルールはフォールバックより前に配置します。

• ルール間：最初に一致したルールで結果が決まり、ドメインの長さ、プレフィックスの種類、ネットワーク範囲の大きさに応じて自動で並べ替えられることはありません。
• 同じフィールド内：たとえばdomain配列に複数の項目がある場合、そのうち1つに一致すれば条件を満たします。
• 異なる条件フィールド間：たとえばdomainとportを同時に指定した場合、両方の条件を満たす必要があります。同じルールにdomainとipを記述しても、「ドメインまたはIP」という意味にはなりません。
• どのルールにも一致しない場合：ほかのルーティング機能を設定していない一般的な構成では、outbounds配列の先頭にあるアウトバウンドが使われます。必ずしも直結になるとは限りません。

2. domain・full・regexp・geositeの書き方

domainはルールのフィールド名で、domain:はそのフィールド内で使うマッチプレフィックスの1つです。混同しないようにしましょう。以下では、構文の説明に予約済みの例示用ドメインexample.comを使用します。実際のサービスの振り分けを推奨するものではありません。

あるサイトとそのサブドメインをまとめて対象にする場合は、文字列だけに頼らずdomain:example.comを使います。ホスト名1つだけに限定する場合はfull:を使います。ドメイン項目にはhttps://、ポート、パス、クエリパラメーターを含めないでください。これらはこのフィールドで指定する形式ではありません。

{
  "type": "field",
  "domain": [
    "full:status.example.com",
    "domain:example.net",
    "regexp:^api[0-9]+\\.example\\.com$"
  ],
  "outboundTag": "proxy"
}

このJSONでは、3つのドメイン項目はOR条件です。正規表現の\\.は、JSONのデコード後に正規表現で必要な\.になります。バックスラッシュを1つだけ記述すると、JSONの解析時点で設定エラーになることがあります。正規表現にはコアが使用するGoの構文を使い、後方参照や先読み・後読みは使用できません。

3. ip・geoipと接続先ポートの組み合わせ

ipフィールドには、単一のIPアドレス、CIDRネットワーク、geoip:データセット参照を指定できます。IPv4の/32は単一アドレスを表し、192.0.2.0/24はドキュメント用の例示ネットワークです。CIDRをdomain配列に入れたり、ip配列にhttps://を付けたりしないでください。

{
  "type": "field",
  "ip": [
    "192.0.2.0/24",
    "2001:db8::/32"
  ],
  "port": "443",
  "network": "tcp",
  "outboundTag": "direct"
}

このルールに一致するのは、接続先アドレスが2つの例示ネットワークのいずれかに含まれ、接続先ポートが443、ネットワークがTCPの接続だけです。同じアドレスへのTCP 80やUDP 443には一致しません。ここでのportは接続先ポートであり、クライアントのローカル待ち受けポートではありません。ローカルインバウンドをタグで区別する場合は、inboundTagを使います。

• geoip:privateは、プライベートアドレスやローカルアドレス範囲の振り分けによく使われます。実際の対象範囲は、読み込んだデータファイルによって異なります。
• geoip:cnはIPカテゴリ、geosite:cnはドメインカテゴリを参照します。互いに置き換えて使うことはできません。
• ドメインカテゴリとIPカテゴリの判定が一致するとは限りません。1つのドメインが、異なる地域のCDNアドレスに解決されることもあります。
• IPv4ネットワークだけを指定しても、IPv6接続は対象になりません。デュアルスタック環境では、実際に使われているアドレスファミリーも確認してください。

4. domainStrategyがルーティング時の名前解決を制御

routing.domainStrategyは、ルーティング段階でドメインの接続先をどう扱うかを制御します。システムのDNS設定とは異なり、アウトバウンド側にある同名または類似の設定とも別のものです。ルーティング段階で名前解決しない場合でも、その後のアウトバウンドがサーバーへの接続に名前解決を必要とすることがあります。

見落としやすいのは、IPIfNonMatchを使いながら、末尾にTCP・UDPのすべてに一致するルールを追加するケースです。ドメイン名のリクエストはこのフォールバックにそのまま一致するため、「先行するgeoipルールに一致しなければ、その後に自動で名前解決して再判定する」とは限りません。ドメインルールを優先し、その後に解決済みIPで振り分ける場合は、名前解決の方針とフォールバックの設定を合わせて確認してください。

アプリからコアに渡される接続先がもともとIPアドレスなら、この設定でアドレスを取得する必要はありません。ただし、その場合はドメイン情報が存在しないことがあります。インバウンドのスニッフィング機能で一部のプロトコルからドメイン情報を補える場合もありますが、効果は通信の種類や設定によって異なります。有効にすればすべての接続でドメイン情報が得られるわけではありません。

5. 評価順を確認するrouting設定例

以下は設定の一部であり、単独で動作する完全な設定ではありません。proxy、direct、blockというアウトバウンドタグがすでにあり、それぞれプロキシ、直結、ブロックを行うことを前提としています。タグは設定者が定義するもので、コアが自動作成する予約名ではありません。また、この例では使用可能なデータファイルにprivateカテゴリが含まれている必要があります。

{
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "domain": ["full:status.example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "port": "6881-6889",
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

1. 個別の例外を先に：status.example.comは1番目のルールに一致して直結され、2番目のドメインサフィックス全体を対象とするルールには進みません。
2. サイトのルールは後に：www.example.comは2番目のルールに一致し、proxyが選択されます。
3. プライベートアドレスを優先：最初の2つのルールに一致しなければ、プライベートアドレスは3番目のルールに一致します。ドメイン名の接続先は、この段階で必要に応じて名前解決される場合があります。
4. ポートルールは全体に適用される禁止ルールではない：4番目のルールが対象にするのは、それ以前のルールに一致しなかった接続だけです。先行ルールに一致したサイトやプライベートアドレスは、このルールに進みません。
5. 明示的なフォールバックは最後に：残ったTCP・UDP接続は5番目のルールに一致します。ここではIPOnDemandを使い、先行するIP判定が実行されるようにしています。

geosite:cnを使う場合は、実際の要件に合わせてドメインルールを追加できます。ただし、カテゴリ名に見覚えがあるからといって、例外を確認せずにすべてを対象にしないでください。まずデータファイルが読み込めることを確認し、そのルールを個別ドメインの例外の後、IPルールの前、または別の位置のどこに置くべきか判断します。データの更新によってカテゴリの判定結果が変わることもあります。

6. クライアント画面から実際の設定を確認する方法

v2rayN、v2rayNG、v2flyNGの画面上の項目名やルーティングルールのインポート方法は、バージョンによって異なります。トラブル時は、クライアントのバージョン、コアの名称、使用中のルーティングモードを記録し、現在有効なルールセットを確認してください。サブスクリプションのノードに含まれるVMessやVLESSの接続パラメーターは、ルーティングルールではありません。ノードはアウトバウンド接続を定義し、ルーティングは使用するアウトバウンドを選択します。

1. 現在のルールをバックアップ：変更前のルーティング設定を保存します。通常、サブスクリプションの更新はノードの更新に使うもので、ローカルのカスタムルーティングを配布する汎用的な仕組みではありません。
2. リクエストがコアに届いているか確認：アプリがシステムプロキシまたは指定したローカルプロキシの入口を使用しているか確認します。インバウンドに届いていないリクエストは、これらのルールでは制御できません。
3. 生成された設定を確認：実際のrouting.rulesの順序と、outboundTagがoutbounds[].tagと完全に一致しているかを確認します。
4. 設定を反映して再テスト：ルールを保存したら、クライアントの手順に従ってコアを再読み込みまたは再起動し、新しい接続を開始します。ブラウザーが接続を再利用すると、既存の接続では以前のアウトバウンドが使われ続けることがあります。
5. ログを確認：必要に応じて一時的にログレベルをinfoにし、インバウンド、接続先、選択されたアウトバウンドを確認します。ログ形式はコアごとに異なり、具体的なルール番号が表示されるとは限りません。

一度に変更する条件は1つに絞ることをおすすめします。まずfull:で特定のドメインが振り分けられるか確認し、次にdomain:で対象範囲を広げ、最後にgeositeやgeoipのカテゴリを追加します。設定項目の位置や前後関係を調べるには、設定リファレンスでインバウンド、アウトバウンド、DNSの各フィールドを確認してください。

7. ルーティングルールに関するよくある質問