Xrayのルーティング優先順位とdomainStrategyをJSON設定例で徹底解説

Xrayで通信先が想定と異なる出口へ振り分けられる場合は、まずルールの並び順と、ドメインをIPアドレスに解決して判定する条件を確認します。特に、IP条件を含むルールを使う構成では、routing.domainStrategy の選択によって、IPルールが評価されるタイミングが変わります。

この記事の要点

Xrayのルーティングは、原則としてルールを上から確認し、最初に一致したルールの出口を使います。ドメイン条件とIP条件の評価関係はdomainStrategyで調整できます。この記事では、各値の違い、ルール順序の組み立て方、JSON設定例、名前解決やスニッフィングを含む切り分け手順を解説します。設定を変更するときは、ルーティング規則とDNSサーバー設定を混同せず、一項目ずつ検証してください。

ルーティング規則は上から評価される

routing.rulesは配列で、通常は先頭から順番に評価されます。条件に一致したルールが見つかると、そのルールに指定されたoutboundTagへ通信が渡され、後続ルールは通常評価されません。このため、広い範囲に一致する規則を先に置くと、後ろに書いた例外規則まで到達できないことがあります。

各ルールの中では、指定した条件が組み合わされます。たとえば、同じルールにdomainとportの両方を指定すると、ドメインとポートの条件を満たす通信が対象です。一方、同じ条件項目に複数の値を並べた場合は、いずれかに一致するかどうかが判定されます。設定を読むときは、「規則どうしの順序」と「一つの規則内の条件」を分けて考えましょう。

ルールの位置	例	注意点
先頭付近	特定ドメインをプロキシへ送る	同じ宛先を直接接続する広い規則より前に置く
中間	社内ネットワークやプライベートIPを直接接続する	IP条件が必要な場合は、名前解決とdomainStrategyを確認する
末尾	その他の通信を既定のプロキシへ送る	全通信に一致する規則は例外より後ろに置く

たとえば、最初に「すべての通信を直接接続」とする規則を置くと、その規則が一致した時点で後続のプロキシ規則は機能しません。逆に、先頭に全通信をプロキシへ送る規則を置けば、後ろの直接接続ルールが使われない構成になり得ます。実際の設定では、例外を先に、範囲の広い既定ルールを最後に置くのが基本です。

domainStrategyの3つの値と選び方

domainStrategyは、ドメイン宛ての通信をIP条件でも判定する必要があるとき、名前解決をどのようにルーティング評価へ利用するかを指定します。DNSサーバー自体を選ぶ設定ではありません。ドメイン規則だけで振り分ける構成と、解決後のIPアドレスも規則に使う構成では、適切な値が異なります。

AsIs

動作: ドメインをIPへ解決せず、受け取った宛先情報で規則を評価
向く条件: ドメイン規則を中心に振り分ける
注意点: IP条件だけでは、ドメイン宛て通信を分類できない場合がある

意図しない名前解決によるIP判定を避けたい場合の基準になります。

IPIfNonMatch

動作: ドメイン条件に一致しない場合、IP条件の判定に使う名前解決を行う
向く条件: ドメイン規則とgeoipなどのIP規則を併用する
注意点: 名前解決の結果や利用するDNS設定が判定に影響する

IPルールを使う一般的な構成で検討しやすい値ですが、実際の規則と合わせて検証してください。

IPOnDemand

動作: 評価中にIP条件が必要になった時点で、ドメインを解決して判定する
向く条件: ドメイン規則を先に評価し、必要な場合にIP規則も使う
注意点: IP条件を含むルールの位置と順序を確認する

規則の評価順序と名前解決がどう結び付くか、ログを見ながら確認します。

まずドメイン規則だけで分類できるなら、不要なIP判定を加えないほうが挙動を追いやすくなります。ドメイン規則に加えて、プライベートネットワークや地域別IPデータを使って振り分ける場合は、IPIfNonMatchまたはIPOnDemandを候補にし、設定したルールに合わせて選びます。どちらを選んでも、DNSの応答が常に特定のIPになることや、名前解決が特定の経路を通ることが保証されるわけではありません。

判断の目安：IP規則が必要な時だけ名前解決を考える

ドメイン条件で目的の振り分けができるなら、IP条件を増やす前にドメイン規則の一致を確認します。IP規則が必要な場合は、domainStrategy、DNS設定、解決結果の三つをまとめて検証してください。

JSON例：例外を先に置き、既定の出口を最後にする

次のコードは、Xray設定のうちrouting部分だけを示す例です。完全な設定ファイルではないため、既存のoutboundsにproxy、direct、blockというタグが定義されている必要があります。geoip:privateを使う場合は、使用中のXrayコアで必要なIPデータが利用できることも確認してください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:intranet.example",
          "domain:service.example.jp"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "192.168.0.0/16",
          "10.0.0.0/8"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:docs.example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "outboundTag": "proxy"
      }
    ]
  }
}

full:intranet.exampleは指定したドメインとの完全一致を意図する書き方です。domain:service.example.jpはドメインの一致条件として使われ、対象範囲はコアのルール形式に従います。必要な範囲を明確にしたいときは、完全一致向けのfull:、ドメイン条件向けのdomain:、部分文字列向けのkeyword:などを区別してください。実際に一致するかは、利用中のコアの仕様とログで確認します。

この例では、指定した直接接続のドメインを先に評価し、続いてプライベートIPを直接接続へ振り分けます。その後、特定ドメインをプロキシに送り、最後の規則で残りの通信をプロキシへ送ります。より広い条件を先に置くと、後ろの例外に到達できなくなるため、変更後は「どの規則が最初に一致するか」を一つずつ追ってください。

現行設定を保存

編集前に、クライアントが生成しているXray設定とルーティングモードを記録します。v2rayNなどのクライアントが設定を生成する場合、手作業で変更したJSONが次回起動時に上書きされることがあります。クライアント側のカスタム設定欄を使うのか、生成後の設定を確認するのか、管理方法を先に決めてください。
出口タグを確認

outboundsに、規則のoutboundTagと同じタグが存在するか確認します。たとえばproxyを指定した規則があっても、アウトバウンド側のタグが別名なら意図した出口にはなりません。タグの大文字・小文字も含めて照合してください。
例外を上へ配置

特定ドメイン、LAN、プライベートIPなどの例外を、全通信に一致する既定ルールより前に置きます。ルールを一度に多数追加せず、一つ追加するごとに対象通信の出口を確認します。サブドメイン全体が必要なのか、完全一致でよいのかも決めてから条件を選びます。
再起動して検証

JSONの構文とタグを確認してからコアを再起動し、同じドメインへ再接続します。コアの起動エラーがないことをログで確認し、対象通信のルーティング結果を見ます。問題が出た場合は直前の変更だけを戻し、変更前後のログを比較します。

設定の入力場所や適用方法は、利用するクライアントとバージョンによって異なります。GUIに「ルーティング」や「カスタムルール」の項目がある場合も、JSONを直接編集する場合も、実際に起動したコアが読み込んだ最終設定を確認してください。表示上の設定が正しくても、別のコアや古い設定ファイルを起動していれば、期待したルールは適用されません。

振り分けがずれる時はDNS・宛先情報・ログを調べる

ドメインを指定したのにIPルールへ分類されない場合や、同じドメインの接続結果が変わる場合は、規則の順番だけでなく、コアが受け取った宛先情報と名前解決を確認します。DNSの応答は複数のIPアドレスを返すことがあり、CDNなどでは時間やネットワークによって応答先が変わることもあります。IPアドレス宛てに直接接続するアプリでは、ドメイン条件が一致しない場合があります。

ドメイン規則が一致しない：full:とdomain:の使い分け、サブドメインの有無、規則より前に一致するルールがないかを確認します。
IP規則が一致しない：domainStrategy、DNS応答、CIDRの範囲、geoipデータの利用可否を確認します。名前解決の結果が想定したネットワークに属するとは限りません。
ドメインが記録されない：アプリがIPアドレスを直接指定していないか、ドメイン情報を取得できる通信かを調べます。HTTPやTLSのスニッフィングは別の設定であり、すべてのプロトコルやアプリでドメインを取得できるわけではありません。
DNSの経路が気になる：routing.domainStrategyとDNSサーバーの指定は役割が異なります。DNSの送信先、DNS関連のルール、クライアント側の名前解決方法を別々に確認してください。

ログを調べるときは、まずコアの起動時に設定の読み込みエラーがないことを確認し、次に対象ドメインへ一度だけ接続して関連する記録を探します。ログの詳細度を上げると確認しやすくなる場合がありますが、個人情報や認証情報を含む記録を公開しないよう注意してください。ルールの編集前後で同じ宛先を使い、変更した値と結果を記録すると、原因を絞り込みやすくなります。

IPルールを追加したのにドメイン通信が対象にならない？

domainStrategyがAsIsなら、ドメインをIPへ解決してIP条件を評価しない構成があります。IP判定が必要な設計かを確認し、必要に応じてIPIfNonMatchまたはIPOnDemandを検討したうえで、DNS応答とログを確認してください。

特定ドメインをプロキシへ送りたいのに直接接続される？

全通信に一致する規則や、より広い直接接続規則が先にないかを確認します。対象ドメインの例外をその規則より前に置き、使用している一致形式とドメイン名が正しいかを調べてください。

domainStrategyを変えればDNSの送信先も変わる？

いいえ。domainStrategyはルーティング判定における名前解決の利用方法を指定する項目です。DNSサーバーやDNS通信の経路を変えたい場合は、DNS設定と関連するルールを個別に確認します。

安定した設定にするには、最初に例外規則を整理し、IP条件が本当に必要な箇所だけで名前解決を利用します。ルールの順序、domainStrategy、DNS設定を同時に変更すると、原因の特定が難しくなります。一つずつ変更し、同じ宛先で結果を確かめてから次へ進めてください。