v2rayNのカスタムルーティング設定｜domain・ip・geositeの書き方と優先順位

1. ルーティングの入口と使用中のコアを確認する

v2rayNは設定・管理用のクライアントで、接続のルール判定を行うのは実行中のコアです。この記事では、routing.rules、domainStrategy、outboundTagをXrayの設定仕様に沿って説明します。異なる形式の設定を使う場合、メニュー名が似ているだけで同じJSONを貼り付けないでください。

デスクトップ版では、まず「設定」→「ルーティング設定」を開き、変更するルーティング設定を選んでルール一覧を編集します。バージョンによっては、行のダブルクリックや右クリックメニューから編集画面を開きます。ドメイン、IP、ポート、アウトバウンドの各項目があることを確認してください。保存後はメイン画面の「ルーティング」から該当設定を選んで有効にします。追加しただけで切り替え忘れないようにしましょう。

1. 現在の状態を記録：ルーティング設定名、使用中のノード、コアの種類を控え、正常に動作している設定を保存しておきます。
2. 設定を複製：普段使っている設定を直接上書きせず、コピーした設定でルールを調整します。
3. アウトバウンドを確認：直接接続・プロキシ・ブロックに割り当てられたタグを確認します。以下ではdirect、proxy、blockを例にします。
4. 変更を適用：設定を保存してルーティングを有効にし、コアのログに起動失敗や設定の解析エラーが出ていないか確認します。

2. ルールの判定順：最初に一致したルールのアウトバウンドが適用される

通常のフィールドを使うルーティングルールは、一覧の上から順に確認され、条件に一致した最初のルールのアウトバウンドが適用されます。「完全一致のドメインがドメイン集合より自動的に優先される」といった仕組みはありません。下のルールにfull:を指定しても、上の広い条件に一致した時点で判定が終わり、下のルールは選ばれません。

同じフィールド内の複数の値は通常「または」、異なる条件フィールド間は「かつ」で判定されます。たとえばドメイン欄に2つの項目があれば、どちらか一方に一致すれば対象になります。同じルールにポート443も指定した場合は、ドメインと宛先ポートの両方を満たす必要があります。domainとipを同じルールに入力しても、「ドメインかIPのどちらかに一致」という意味にはなりません。

これらはプロトコルのポート番号とアドレス範囲であり、速度測定の結果ではありません。ルーティングのportは宛先ポートを指し、ローカルプロキシの待ち受けポートではありません。ブラウザーがローカルプロキシに接続してHTTPSサイトにアクセスする場合、通常ルールで判定するのはリモート側の443であり、ブラウザーからローカルプロキシへの接続に使うポートではありません。

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

これらのプレフィックスはドメイン欄で使います。https://、パス、クエリパラメーター、ポートは入力しません。ブラウザーのURLがhttps://api.example.com/accountなら、ドメインはapi.example.comです。ルーティングのドメインルールでは、ウェブページのパスによる振り分けはできません。

domain:はサービスとそのサブドメインをまとめて同じ経路にする場合に便利です。full:は単一のエンドポイントに例外を設定する場合に適しています。プレフィックスのない文字列では、example.com.other.testのようなドメインまで一致する可能性があります。通常の設定では、境界が明確なプレフィックスを使いましょう。

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

ここでは3つのドメイン条件を「または」で判定します。コードはJSONなので、正規表現内のバックスラッシュは2つ重ねて記述します。v2rayNのドメイン入力欄にルールを直接入力する場合は、通常regexp:^api[0-9]+\.example\.org$と記述し、JSON文字列用の追加エスケープは不要です。正規表現はコアが対応する仕様に従い、ブラウザーで使えるすべての表現をそのまま利用できるとは限りません。

• geositeはドメインの集合：geosite:cnは「サーバーが中国にあるか」をリアルタイムに判定するものではなく、末尾が.cnのすべてのドメインを指すわけでもありません。
• セット名はデータファイルに依存：ウェブ上の設定例にある分類が、ローカルのデータに含まれているとは限りません。リストが見つからないというエラーが出たら、データの入手元と実際の分類名を確認してください。
• データ更新で対象範囲が変わる：ルールの記述を変えなくても、ドメインデータの更新によって一致結果が変わる場合があります。問題を調べるときは、データの更新日時も記録してください。

4. ipフィールド、CIDR、geoipの違い

ipはルールのフィールド名であり、アドレスの前に付けるプレフィックスではありません。GUIのIP欄には、単一アドレス、CIDR形式のネットワーク、geoip:セットを指定できます。たとえば192.168.0.0/16と入力し、ip:192.168.0.0/16とは書きません。IPv6アドレスもIP欄に入力します。

{
  "type": "field",
  "ip": [
    "10.0.0.0/8",
    "172.16.0.0/12",
    "192.168.0.0/16",
    "fc00::/7"
  ],
  "outboundTag": "direct"
}

このルールは一般的なプライベートアドレス範囲を対象にしますが、ローカルアドレス、リンクローカルアドレス、予約済みアドレスをすべて網羅するものではありません。geoip:privateを使う場合は、ローカルのIPデータファイルにそのセットが含まれていることと、対象範囲を確認してください。LAN内のサービスにアクセスする場合は、リクエストが実際にプロキシコアを通っているかも確認します。システムプロキシを経由しない接続は、このルールの一致ログに記録されません。

同じウェブサイトでも複数のCDNアドレスを使う場合があり、DNSの応答もネットワーク状況によって変わります。一度の名前解決で得た単一のIPを使ってサイト全体の経路を振り分けるより、ドメインルールのほうが安定します。IPルールは、アプリがIPアドレスへ直接接続する場合、固定のLAN内デバイスを指定する場合、または明確なネットワーク範囲を対象にする場合に優先して検討してください。

5. ドメイン解決ポリシーによってIPルールの適用タイミングが決まる

ドメインを含むリクエストについて、コアが先にIPアドレスを解決してからIPルールで判定するかどうかは、routing.domainStrategyなどの設定で決まります。この設定は「最終的な接続先をどのDNSで解決するか」「トラフィックのスニッフィングを有効にするか」とは別の話です。スイッチを1つ有効にすればすべて解決するわけではありません。

たとえば「すべてのTCP・UDPをプロキシ経由にする」ルールを一覧の末尾に置いた場合、IPIfNonMatchでは、具体的なドメインルールに一致しなかったリクエストが、このネットワーク全体のフォールバックルールに先に一致することがあります。ルールに一致した後で自動的に再解決し、geoip:cnへ振り分けられることは期待できません。「中国本土のIPを直接接続に設定したのに効かない」場合によくある原因です。

• ドメインルールを中心にする：明確なドメイン例外やセットを先に配置し、不要な名前解決が判定に介入しないようにします。
• IP分類を利用する：現在の名前解決ポリシー、DNSの動作状況、先行するルールへの一致がないかを確認してください。
• アプリが渡す情報がIPのみ：ドメインルールの判定材料が不足する場合があります。スニッフィングでドメインを補えるかはプロトコルや設定によって異なり、すべての接続で有効とは限りません。

6. 直接接続・プロキシ・ブロックの設定例

一般的には「明確な例外を先に、広いセットを後に、最終フォールバックを最後に」配置します。ただし、ブロックと例外のどちらを優先するかは、実際の要件によって決めてください。特定のドメインを必ずブロックするなら、許可する可能性のあるルールより上にブロックルールを置きます。ブロック対象のセットから特定のサイトだけ除外するなら、そのセットより上に明確な許可ルールを置きます。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example.org"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["full:api.example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["10.0.0.0/8", "192.168.0.0/16"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

例にあるドメインは書式の説明用であり、利用可能なノードや実在するテストサービスではありません。設定には対応するアウトバウンドタグを定義しておく必要があります。directは直接接続、blockはブロック、proxyは実際のプロキシアウトバウンドに対応します。タグは参照用の名前であり、proxyと記述するだけでノードが自動作成されるわけではありません。

1. 明示的にブロック：拒否する必要がある具体的な宛先を先に処理します。
2. ドメインの例外：特定のエンドポイントやサイトにアウトバウンドを指定し、後続のセットに上書きされないようにします。
3. プライベートIP：IPアドレスでアクセスするLAN内の宛先を処理します。この例ではAsIsを使用するため、ドメインを積極的に解決してこのルールに一致させることはありません。
4. セットを直接接続：実際のgeositeデータに基づいて、残りのドメインを判定します。
5. 最終フォールバックはプロキシ：まだ一致していないTCP・UDPトラフィックをプロキシ経由にします。

どのルールにも一致しない場合、Xrayは通常、設定内で最初に定義されたアウトバウンドを使います。この暗黙の動作を「デフォルトで必ずプロキシになる」と考えないでください。クライアントが生成する設定では、アウトバウンドの順序が異なる場合があります。明示的なフォールバックは読みやすくなりますが、前述の名前解決ポリシーの影響も考慮してください。

7. ルールが機能しないときの確認手順とよくある質問

まず、リクエストがコアに届いていない、届いた後に誤ったルールへ一致している、正しいアウトバウンドに一致したものの接続に失敗している、という3つの状況を切り分けます。1つ目はシステムプロキシとアプリの設定、2つ目はルールの順序と判定フィールド、3つ目はノード、DNS、宛先への接続状況を確認します。ルーティングが正しくても、プロキシノードが使えるとは限りません。

1. 変更は1ルールだけ：実際に使うドメインを1つ選び、full:ルールを追加して、対象を含む可能性のあるルールより上に配置します。
2. 新しい接続を確立：ルーティングを保存して有効にしたら、既存のページやアプリの接続を閉じてリクエストをやり直します。既存の長時間接続は、ルールを編集しても自動的に経路が選び直されません。
3. ログを確認：v2rayNのログで宛先、エラー、アウトバウンドタグを確認します。必要に応じて一時的にログレベルを上げてください。通常のアクセスログには、一致したルールの行番号が表示されない場合があります。
4. 生成された設定を確認：現在のコアが読み込んでいる設定に新しい項目が含まれていること、タグのつづりがoutboundsの定義と一致していることを確認します。クライアントが再生成する一時設定を長期的に直接編集しないでください。
5. 設定を元に戻す：原因がわかったら一時的なテストルールを削除し、ログレベルも元に戻して、不要なアクセス情報が記録されないようにします。

調査記録を保存するときは、ルールの順序、宛先の種類、アウトバウンドタグ、エラー情報だけを残します。スクリーンショットや設定を共有する前に、サブスクリプションURL、ノードの認証情報、不要なアクセス先ドメインを隠してください。ルールを大量に追加するより、再現可能な一致結果を1つ確認するほうが原因を特定しやすくなります。