Xrayのルーティング設定を深掘り：domainStrategyとDNS分岐の実践ガイド

ルーティングルールは上から評価し、最初の一致で決まる

Xrayのルーティングは、受け取った接続の情報をルールに照らし、条件に一致したアウトバウンドへ振り分けます。通常、ルールは配列の先頭から評価され、最初に一致したルールが適用されます。後ろのルールは、先に一致した接続については評価されません。そのため、広い条件を先頭に置くと、細かい例外ルールが使われないことがあります。

ルールの条件には、ドメイン、IPアドレス、ポート、ネットワーク種別、受信タグなどを使えます。たとえば、社内ドメインを直接接続し、プライベートIP宛てを直接接続したうえで、残りをプロキシに送るなら、例外を先に、対象範囲の広いルールを後ろに置きます。ルールに一致しない接続の行き先に頼るより、最後に明示的な振り分けルールを用意するほうが、設定の意図を確認しやすくなります。

ルールを並べ替えた後は、意図した例外が先に評価されるか、最後の広いルールが残りの接続を受けるかを確認してください。ルーティングルールの順序と、アプリからXrayに接続が渡るかどうかは別の問題です。ルールが正しくても、アプリがローカルプロキシを利用していなければ、対象の通信はXrayのルーティング対象になりません。

domainStrategyとDNSサーバー選択を区別する

domainStrategyは、DNSの問い合わせ先を選ぶ設定ではなく、ルーティングでIP条件を照合する際のドメイン名の扱いに関係します。Xrayで一般的に使われる値は AsIs、IPIfNonMatch、IPOnDemand です。どれを選ぶかで、IPルールがドメイン名で指定された接続に適用されるタイミングが変わります。

AsIsでは、ドメイン名で到着した接続がIPルールに一致するとは限りません。IPIfNonMatchは、先にドメインルールを評価し、そこで一致しなかった場合にIPルールの判定へ進むときに使います。IPOnDemandは、IP条件が評価に必要となった段階でドメインの解決を行う動作です。実際の解決結果はDNSの設定や実行環境にも左右されるため、値だけで経路を断定しないでください。

一方、DNS設定は名前解決に使うサーバーや、問い合わせ対象に応じたDNSの選択を扱います。XrayのDNS設定にドメイン別のサーバーを定義しても、それだけで通信のアウトバウンドが決まるわけではありません。逆に、ルーティングでドメインをプロキシへ送るルールを作っても、DNS問い合わせが必ず同じプロキシ経路を通るとは限りません。名前解決と接続の振り分けを別々に確認することが重要です。

JSON例を使って設定し、段階的に検証する

次の例は、DNS設定とルーティング設定の要点を示す断片です。完全なXray設定ファイルではないため、利用する場合は既存のJSON内の該当箇所に統合してください。directとproxyのタグを持つアウトバウンドが別途必要です。DNSサーバーのアドレスや使用可能な機能は環境とコアのバージョンに合わせ、起動ログで設定の読み込み結果を確認してください。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": ["domain:internal.example"],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["domain:example.net"],
        "skipFallback": true
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:internal.example"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.net"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

この例では、社内ドメインのルールとプライベートIPのルールを先に置き、指定ドメインをプロキシへ送り、最後に残りのTCP・UDP接続をプロキシへ送ります。最後のルールが広い範囲を受けるため、それより後ろに例外を置いても適用されません。DNSの domains は問い合わせ先の選択に関係し、outboundTag は接続の送信先に関係するため、同じドメインが両方に登場していても役割は異なります。

1. 設定を退避する：編集前に現在のJSONを複製します。既存のroutingやdnsを丸ごと置き換えず、現在のルールと重複する条件がないか確認してください。
2. JSONを検査する：カンマ、引用符、括弧の対応を確認します。クライアントが設定確認機能を提供している場合は、保存後にその機能を実行し、コアの起動ログにも構文エラーがないことを確認してください。
3. 対象を一つ試す：社内ドメインとプロキシ対象のドメインを一つずつ選び、名前解決と接続結果を別に記録します。複数のルールを同時に変更すると、どの変更が結果に影響したか分かりにくくなります。
4. ルールを見直す：期待と異なる経路になったら、先に一致したルール、実際の宛先がドメインかIPか、利用中のアウトバウンドタグを確認します。変更後はコアを再起動し、同じ対象で再テストします。

UseIPはDNS側の問い合わせ戦略に関する値で、domainStrategyの代わりではありません。また、社内DNSのアドレスやHTTPS DNSのURLは例示です。実際の環境で利用できるDNSサーバーに置き換え、社内名の問い合わせが外部サーバーへ流れないよう、必要に応じてサーバー選択ルールとフォールバック動作を確認してください。

経路が想定と違う場合に確認する順番

通信先が想定外になった場合は、まず「DNSの答えが違う」のか、「ルーティングルールの一致先が違う」のかを分けます。ブラウザーの表示だけでは、名前解決、ローカルプロキシへの接続、Xray内のルール評価、リモート側の接続結果のどこで変化したか判断できません。対象のドメイン、解決結果、ルールの順序、ログに出る接続先をそろえて確認しましょう。

• ルール順序：対象のドメインやIPより前に、ネットワーク種別などの広い条件が一致していないか確認します。
• アウトバウンドタグ：一致したルールのタグと、実際に定義されたアウトバウンドのタグが完全に一致しているか確認します。
• DNSの分岐：社内名が社内DNSへ問い合わせられているか、意図しない外部DNSへのフォールバックがないか確認します。
• 接続の入口：対象アプリがXrayのローカルプロキシ、または設定した通信取り込み方式を利用しているか確認します。