上級テクニック 読了目安 14分

Xray JSON設定を深掘り：ルーティング分割と運用設計

Xray-coreのJSON設定を、inbounds・outbounds・routing・DNS・policy・observatoryの役割から実践的に解説します。ルールの評価順、DNSリーク対策、設定ファイルの分割、Gitでの管理、秘密情報の扱いまで、実際に動かせるサンプルを使って保守しやすい構成を作る方法を紹…

XrayのJSON設定は、ノード情報を記述するだけのファイルではありません。インバウンドで通信を受け、DNSで名前解決の経路を決め、ルーティングで接続先を振り分け、アウトバウンドから実際の通信を送出する一連の動作を定義します。開発環境では1つのconfig.jsonにすべてをまとめても動かせますが、本番運用では、設定の変更範囲、検証方法、ログの保存先、障害時の切り戻しまで考えた構造が必要です。

この記事では、Xray-coreのJSON設定を実運用で管理するために、ルーティングとDNSの関係、複数ファイルへの分割、VLESSとVMessのアウトバウンド設計、設定テスト、ログを使った切り分けを順に整理します。v2rayNなどのGUIから生成したノード設定を、ゲートウェイやサーバー上のXray設定へ移す場合にも利用できる考え方です。

本文速覧

本番環境で壊れにくいXray JSON設定を作るため、通信の流れを可視化し、DNS・ルーティング・アウトバウンドを役割ごとに分離します。具体的なJSON例、設定分割時の注意点、ログに現れるエラーと確認手順までまとめています。

4層
基本構成
3段
ルーティング優先順位
1080
SOCKS待受ポート例
2026
運用基準年

Xray JSON設定を4つの層に分けて考える

Xrayの設定全体は、インバウンド、アウトバウンド、DNS、ルーティングの4層に分けると理解しやすくなります。インバウンドはローカルアプリやLAN機器から通信を受ける入口です。アウトバウンドは、プロキシサーバーへ送る経路、直接接続する経路、通信を破棄する経路など、出口を定義します。DNSは名前解決の問い合わせ先と解決方法を決め、ルーティングはどの通信をどの出口へ渡すかを決めます。

例えば、ローカルのSOCKS5ポートを127.0.0.1:1080で開き、通常の宛先をVLESS経由で送る場合、インバウンドにはsocks-inというタグを付けます。ルーティング規則はこのタグを条件にできるため、同じXrayプロセス内で別の入口を追加しても、意図した通信だけを特定のアウトバウンドへ送れます。タグは単なる表示名ではなく、設定要素を接続する識別子です。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 1080,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

上の例では、プロキシ用の実際の接続設定をまだ入れていません。freedomはXrayから宛先へ直接接続するアウトバウンドであり、VLESSやVMessのリモートノードを表すものではありません。プロキシ出口を追加する場合は、プロトコル、サーバーアドレス、ポート、UUID、暗号化方式、TLSまたはREALITY、トランスポート方式などをサーバー側と一致させます。フィールド名が似ていても、VLESSとVMessの設定を混在させてはいけません。

アプリが接続インバウンド受信DNS判定ルール照合アウトバウンド送出

結論:タグを先に設計する

設定を増やす前に、インバウンドとアウトバウンドのタグ命名を決めてください。socks-in、http-in、proxy、directのように役割を明確にすると、ルール追加時の誤送出を減らせます。

ルーティング規則は順序と判定対象を分離する

Xrayのルーティングは、上から順にルールを評価し、最初に条件へ一致したルールのoutboundTagを使用します。すべての規則を比較して最適な出口を自動選択する仕組みではありません。そのため、LANやブロック対象などの例外を先に置き、地域別の直通ルールを続け、最後に残りをプロキシへ送るフォールバックを配置します。

判定対象は、ドメイン、IPアドレス、ポート、ネットワーク種別、インバウンドタグなどに分けて考えます。domainとipを同じルールへ無計画に詰め込むと、条件が想定以上に限定されることがあります。ドメインで判定する規則と、IPで判定する規則は、別オブジェクトにしたほうがログと設定の対応を追いやすくなります。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["socks-in"],
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["socks-in"],
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["socks-in"],
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategyは単純なDNSの有効・無効ではありません。例えばIPIfNonMatchでは、ドメイン条件に一致しなかった場合に、必要に応じて名前解決を行ってIP条件を追加で評価します。ドメインをIPへ変換するためのDNS設定が不適切だと、geoipによる判定が期待どおりにならない場合があります。DNSの応答先とルーティングの意図を別々に考えず、どの場所で名前を解決するかまで設計してください。

優先順位判定対象出口目的
1geoip:privatedirectルーター、NAS、LAN機器を直接接続
2geosite:cndirectドメインカテゴリによる直通
3geoip:cndirectIPアドレスによる補足判定
4残りのTCP・UDPproxyフォールバックとしてプロキシ送信

DNS設定とルーティングを同じ経路図で管理する

DNS設定は、単に高速なサーバーを指定するだけの項目ではありません。プロキシ対象のドメインをローカルDNSで解決すると、名前解決結果が地域やネットワーク環境に依存し、ルーティング後の接続先と一致しないことがあります。一方、すべての問い合わせを同じ上流へ送ると、LAN名の解決や社内ドメインの利用に支障が出る場合があります。

運用では、ローカル用、直接接続用、プロキシ経由用のDNSを分ける設計が有効です。例えばlocalhostや内部ドメインはLANのDNSへ送り、直接接続する地域ドメインは指定したUDPまたはTCP DNSへ送り、プロキシ対象はリモート側で解決します。Xrayのバージョンや構成によって利用できるDNS機能は異なるため、使用中のコアのドキュメントと設定テスト結果を必ず確認してください。

{
  "dns": {
    "servers": [
      "192.168.1.1",
      {
        "address": "8.8.8.8",
        "port": 53,
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https+local://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

この例のアドレスやカテゴリは環境に応じて変更します。家庭内DNSが192.168.1.1でない場合、そのままコピーしてはいけません。また、DNS要求そのものをXrayのインバウンドへ送り、同じインバウンドを再びDNS処理へ戻すような構成は、転送ループの原因になります。ログに同じ問い合わせが短時間で繰り返し現れる場合は、DNSの送信先、ルーティング規則、待受ポートの重複を確認します。

設定ファイルを分割して変更範囲を小さくする

設定が長くなったら、インバウンド、アウトバウンド、DNS、ルーティングを別ファイルで管理したくなります。ただし、Xrayが任意のディレクトリ内のJSONを自動的に結合するとは限りません。起動方法と使用するXray-coreの仕様を確認し、複数ファイルを読み込む方式を採用する場合は、配列の結合順、重複キー、同名タグの扱いを検証してください。

初回構築や障害調査では、最終的にコアが読む単一の完成設定を出力できる状態が安全です。分割ファイルだけを見て「正しい」と判断するのではなく、生成後のJSONに必要なinbounds、outbounds、dns、routingがすべて存在するか確認します。ファイル名を数字で始める運用は読み込み順を意識しやすくしますが、実際の順序が保証されるかは実行環境に依存します。

/etc/xray/
├── config.json
├── conf.d/
│   ├── 10-inbounds.json
│   ├── 20-outbounds.json
│   ├── 30-dns.json
│   └── 40-routing.json
└── backup/
    ├── config-2026-09-05.json
    └── config-2026-09-04.json

変更手順は、バックアップ、編集、構文検証、差分確認、再読み込み、疎通確認の順に固定します。待受ポートを変更した場合は、ファイアウォールとクライアント側の接続先も同時に確認します。設定をリロードしたつもりでも、サービス管理側が別のパスを指定していると、編集したファイルは使われません。プロセス一覧や起動ログで実際の設定パスを確認してください。

  1. 現行設定を保存

    /etc/xray/config.jsonと関連ファイルを日時付きでバックアップし、現在のXray-coreのバージョンと起動引数も記録します。

  2. 役割別に編集

    インバウンド、アウトバウンド、DNS、ルーティングを分け、同じ変更で複数の責務を変更しないようにします。

  3. 設定を検証

    実行中のサービスを止める前に、使用中のXray-coreで設定テストを実行し、JSON構文と必須フィールドを確認します。

  4. 差分を確認

    タグ、ポート、UUID、サーバーアドレス、ルール順が意図せず変わっていないか、前回のバックアップとの差分を確認します。

  5. 疎通を確認

    ローカルポート、DNS、直通サイト、プロキシ対象サイト、LAN機器の順にテストし、ログと結果を保存します。

ログを使ってJSON設定の問題を切り分ける

設定エラーは、JSONの構文エラー、コア起動エラー、ルーティング不一致、DNS失敗、リモート接続失敗に分けて調べます。最初からサーバーの状態を疑うのではなく、Xrayが設定を読み込んで待受ポートを開けたかを確認してください。ポートが開いていない場合、ルーティング規則を変更しても通信は改善しません。

設定を編集したのに動作が変わらない?

サービスの起動引数が参照する設定パスを確認し、再読み込み後にプロセスの開始時刻とログを確認します。別の設定ファイルを編集しているケースがよくあります。

直通にした通信までプロキシへ送られる?

geoip:privateや必要なドメイン規則をフォールバックより前へ置き、対象インバウンドのタグが一致しているか確認します。

ドメイン規則に一致しない?

domainStrategy、DNSの解決結果、スニッフィングの有無を確認します。アプリがIPアドレスへ直接接続している場合、ドメイン規則だけでは判定できません。

JSONは正しいのに接続できない?

構文が正しいことは、UUID、ポート、TLS、SNI、Realityの公開鍵、flowなどが正しいことを意味しません。クライアント側とサーバー側の項目を一つずつ照合してください。

代表的なログは次のように分類できます。failed to read configやinvalid characterは、JSONの構文、ファイル権限、指定パスを確認する段階です。address already in useは、同じポートを別プロセスが使用しているか、Xrayのインバウンドを重複定義している可能性があります。connection refusedは接続先ポートでサービスが待ち受けていない、または途中のファイアウォールで拒否されていることを示します。

failed to read config
invalid character '}' after object key
address already in use
connection refused
no route to host
failed to find an available destination
TLS handshake error
context deadline exceeded

failed to find an available destinationが出た場合は、ルーティング先のタグが存在するか確認します。ルールのoutboundTagがproxyでも、アウトバウンド側のタグがproxy-outなら一致しません。TLS handshake errorでは、時刻、SNI、証明書、トランスポート、Reality関連のパラメータを確認します。context deadline exceededは広い意味のタイムアウトであり、DNS、TCP到達性、リモートサーバー、経路混雑の順に切り分ける必要があります。

症状最初に見る場所次の確認
コアが起動しない設定パスとJSON構文ポート重複、ファイル権限、タグ重複
ポートに接続できないlistenアドレスと待受状態OSファイアウォール、クライアントのポート
直通・プロキシが逆になるルール順とoutboundTagdomainStrategy、DNS、IP判定
TLSで失敗する時刻、SNI、証明書トランスポート、flow、サーバー側設定
名前解決だけ失敗するDNSサーバーとqueryStrategyDNSループ、到達性、キャッシュ

ログレベルを一時的にdebugへ上げると、ルール判定や接続処理の詳細を確認しやすくなります。ただし、本番環境で長期間debugログを有効にすると、ディスク使用量が増え、UUIDや接続先などの情報がログに残る可能性があります。調査が終わったらinfoまたはwarningへ戻し、アクセスログにはローテーションと保存期間を設定してください。

v2rayN をダウンロード