· ルーティング · 約12分

Xrayのカスタムルーティングルール設定ガイド：domain・full・regexp・ip・geositeの使い分けと優先順位

Xrayのルーティング条件の違いと使い分け、上から順に評価されるルールの優先順位を解説。v2rayNでカスタムルールを作成・調整するための実用例も紹介します。

この記事の概要

この記事は、ノードに接続でき、通信の振り分けを細かく調整したい方向けです。ドメイン項目とIPフィールドの違いを確認し、3つのルール例で最初に一致したルールが適用される仕組み、条件の組み合わせ、DNS解決との関係を解説します。最後に、v2rayNで元に戻せるカスタム設定を保存する方法を紹介します。例には構文の説明用に予約されたドメインを使用しており、これらのドメインへのアクセスを接続テストとして扱うものではありません。

まず確認：ドメインのプレフィックスとIPフィールド

Xrayのrouting.rulesは、順序に沿って評価されるルール配列です。各ルールでは「どの接続を」「どのアウトバウンドに送るか」を指定します。domain、ip、portはマッチ条件、outboundTagは既存のアウトバウンドを指定する項目です。ここで扱うルーティングはサブスクリプションのノード一覧の並べ替えではなく、VMessやVLESSノードの認証パラメーターを変更するものでもありません。

記法設定箇所マッチする範囲
full:api.example.comdomain配列指定したドメインに完全一致します。サブドメインは含みません。
domain:example.comdomain配列ルートドメインとサブドメインに一致します。例：www.example.com。notexample.comには一致しません。
regexp:^api[0-9]+\.example\.com$domain配列正規表現に一致するドメインを対象にします。例：api12.example.com。
geosite:cndomain配列現在のドメインデータベースに登録されたカテゴリを参照します。対象範囲は使用するデータファイルによって異なります。
192.168.0.0/16ip配列このIPv4ネットワークに一致します。先頭にip:を付ける必要はありません。
geoip:privateip配列IPデータベース内のプライベートアドレスセットを参照します。該当するデータが利用可能である必要があります。

混同しやすいのが「ipプレフィックス」です。ここでのipはJSONのフィールド名であり、domain:と対になる汎用的なドメイン項目のプレフィックスではありません。ip:192.168.1.1をドメインリストに入れても、宛先IPのマッチ条件にはなりません。プレフィックスなしのドメイン文字列は通常、部分一致として扱われます。そのため、example.comは明示的にdomain:example.comと指定した場合より広い範囲に一致します。

マッチ範囲に応じて記法を選ぶ

特定のAPIだけプロキシ経由にする場合、通常は正規表現を使う必要はありません。サイト全体とサブドメインをまとめて処理する場合も、ホスト名を一つずつ列挙する必要はありません。まず境界が明確な記法を使うと、後からトラブルを調べる際に判断しやすくなります。

ドメインの範囲を明確にする

おすすめ

単一ホストにはfull:、ルートドメインとサブドメインにはdomain:を使います。どちらもルールを一つずつ確認しやすく、手動でルールを書く際の基本になります。

用途：特定サイトの経路変更、個別APIの例外設定。

カテゴリセットを参照する

複数のドメインをまとめるにはgeosite:を使います。カテゴリ名は自由に付けられるラベルではなく、使用中のデータベースに存在している必要があります。データ更新により、カテゴリに含まれるドメインが変わる場合もあります。

用途：地域やサービスごとのカテゴリを管理し、少数の特定ドメインを例外として追加する。

パターンを正規表現で指定する

番号付きホストなどの規則的な名前にはregexp:を使います。Xrayの正規表現構文は、あらゆるブラウザーの正規表現機能と同じではありません。先読みや後方参照を含む式をそのまま流用しないでください。

用途：複数のホスト名に共通の命名規則があり、一致する例と一致しない例を用意できる場合。

正規表現は入力方法に応じた記述が必要です。GUIのプレーンテキスト形式のドメイン欄では、通常regexp:^api[0-9]+\.example\.com$と入力します。JSON文字列にする場合は、次の例のようにバックスラッシュをもう一段エスケープします。先頭の^と末尾の$でドメイン全体を指定し、より長い文字列への誤マッチを防ぎます。

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

ルールの順序：例外を先に、カテゴリを後に

ルールは上から順に評価され、条件に一致した最初のルールでアウトバウンドが決まります。その後に「より具体的な」ルールがあっても評価は続きません。full:だからといって、前にあるdomain:より自動的に優先されるわけではありません。カテゴリ項目にも、配列の順序とは別の優先順位はありません。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:api.example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

これはルーティング部分の設定例であり、クライアントの完全な設定ではありません。設定全体としてそのままインポートしないでください。既存の設定にproxyとdirectのアウトバウンドが定義されている必要があります。ドメイン宛ての接続では、api.example.comは1つ目、www.example.comは2つ目のルールに一致します。IPアドレスを直接指定した接続では、192.168.1.20が3つ目のルールに一致します。

要点：例外ルールを先に、カテゴリルールを後に

特定のドメインが誤ったアウトバウンドに送られる場合は、まずそのドメインの個別ルールを広範囲のカテゴリルールより前に移動し、ログで確認します。すぐに重複するカテゴリルールを追加しても、既存ルールが遮られるだけです。

IPネットワークとDNSポリシーの連携

IPルールがマッチするのは宛先アドレスであり、現在のPCのパブリックIPアドレスではありません。クライアントがドメインを受け取ったとき、事前に名前解決し、その結果をルーティングに使うかどうかはdomainStrategyによって異なります。これはDNS設定全体を意味するものではありません。どのリゾルバーを使うか、DNSリクエストをどう送信するかは、DNS設定と関連するルーティング設定も確認してください。

32ビット
IPv4アドレスの長さ。/32は単一アドレスを表します。
128ビット
IPv6アドレスの長さ。/128は単一アドレスを表します。
65,536
192.168.0.0/16に含まれるアドレスの総数
ポリシー値処理内容確認ポイント
AsIsルーティング段階では、ドメインをIPアドレスに変換しません。ドメインがルールに一致しなくても、IPルールで自動的に補われるとは限りません。最初からIPアドレスで指定された宛先は、引き続きマッチできます。
IPIfNonMatch通常の条件でドメインがどのルールにも一致しない場合、名前解決を試みてから再度マッチングします。前段の広範囲なドメインルールに一致すると、より適切なIPルールを探すために再選択されることはありません。
IPOnDemandマッチング中にIPを必要とするルールが見つかると、必要な名前解決が行われます。IPルールの位置によって名前解決のタイミングが変わります。広範囲のIPルールを前方に置きすぎると、ドメイン例外の結果が変わる場合があります。

たとえば、オフィス機器192.168.1.20の管理画面を直結にするには、IPフィールドに192.168.1.20/32を入力します。プライベートアドレス全体を追加する必要はありません。ドメイン名でアクセスする画面の場合、接続時にコアへ渡される宛先がドメイン名なのかIPアドレスなのかも確認してください。アプリのプロキシ方式、DNSキャッシュ、スニッフィング設定によって、認識される宛先情報が変わることがあります。

v2rayNで元に戻せるルールを作成する

以下では、中国語のデスクトップ画面で一般的な操作手順を紹介します。バージョンによって編集操作がボタンにある場合と右クリックメニューにある場合があります。「ルーティング設定」と現在有効なルールセットを確認してください。ルーティング設定の一部を、ノードのサーバーアドレス、サブスクリプションURL、転送パラメーターに貼り付けないでください。

  1. コアを確認する

    「設定」→「パラメーター設定」を開き、現在のノードのプロトコルに対応するコアがXrayになっているか確認します。バージョンによってコアの割り当てが別の設定ページにある場合は、そのページで確認してください。まずノード自体が接続できる状態にします。

  2. 設定をバックアップする

    「設定」→「ルーティング設定」を開き、現在使用中のルールセットを確認します。画面にエクスポートまたはコピー機能がある場合は、それを使って複製を保存してください。すでにカスタムルールがある場合は、変更前に順序も記録しておきます。

  3. 例外ルールを追加する

    使用するルールセットを編集し、次のルールを追加します。ドメインにはfull:api.example.comを入力し、アウトバウンドはプロキシを選択します。不要な条件は空欄のままにしてください。GUIのフォームには各フィールドの値だけを入力し、JSON全体を貼り付けないでください。

  4. ルールの順序を調整する

    次に、ドメインをdomain:example.com、アウトバウンドを直結にしたルールを追加します。画面の並べ替え機能を使い、個別の例外ルールをサイト全体のルールより前に配置してください。さらに前にあるカテゴリルールが例外ルールを遮っていないかも確認します。

  5. 有効化して確認する

    ルールセットを保存して現在のルーティング設定に適用し、画面の案内に従ってサービスを再読み込みまたは再起動します。実際に管理する宛先に例示用ドメインを置き換えたうえで、既存の接続を閉じて新しいリクエストを送信してください。問題があれば、バックアップしたルールセットに戻して変更箇所を確認します。

確認時は一度に変更する条件を1つに絞ります。プロキシ経由にするドメイン、直結にするドメイン、LAN内のIPをそれぞれ選び、新しい接続を作成して時刻と宛先を記録します。ルールを変更しても、確立済みの長時間接続がただちに別のアウトバウンドへ移るとは限りません。ブラウザーが接続を再利用していると、「保存しても反映されない」ように見えることがあります。

よくある質問：ルールが正しいのに適用されない場合

fullを使っているのに、なぜ直結になる？

まず、前にあるdomain:、geosite:などの広範囲なルールにすでに一致していないか確認します。次に、実際に接続しているホスト名を確認してください。Webページ本体、API、画像、ログインサービスで異なるドメインが使われることがあります。メインページだけに例外を設定しても、すべてのリクエストが対象になるとは限りません。

geositeカテゴリを追加したらコアが起動しない場合は？

ログに表示されたデータファイルの読み込みエラーやカテゴリが見つからないというメッセージを確認し、使用中のデータファイルにそのカテゴリが含まれているか、コアが実際にどの場所から読み込んでいるかを調べます。まず追加した項目を取り消して接続を復旧し、クライアントのルールデータ更新機能で対応してください。カテゴリ名だけを見て存在すると判断しないでください。

ドメインとIPはそれぞれ一致するのに、両方を指定すると一致しないのはなぜ？

同じルール内の異なる条件は、通常すべて満たす必要があります。「このドメインまたはこのネットワークを直結する」場合は、ルールを2つに分けてください。同じ宛先グループに限定する必要がある場合は、DNSポリシーとコアが実際に取得したアドレスも確認します。

正規表現のテストは通るのに、JSONに貼るとエラーになるのはなぜ？

まずバックスラッシュのエスケープを確認してください。JSONで文字としてのドットに一致させるには通常\\.、プレーンテキストの入力欄では通常\.と記述します。次に、使用中の正規表現エンジンが対応していない構文を削除し、一致するドメインと一致しないドメインをそれぞれ使って確認してください。

安定したカスタムルーティングは、少数の個別例外、明確なカテゴリルール、分かりやすいフォールバック動作で構成できます。変更のたびに「宛先、ルールの位置、想定するアウトバウンド、実際のアウトバウンド」を記録すると、似たルールを重ねるより管理しやすくなります。データベースを更新した後は、例外設定が必要だったドメインも再確認してください。

v2rayN / v2rayNG ダウンロード