Xrayルーティング規則を深掘り：JSON設定と分割設計の実践

Xrayのルーティングは、接続先を「プロキシ経由」「直接接続」「ブロック」などのアウトバウンドへ振り分ける仕組みです。GUIの「ルール追加」だけでも基本設定は作れますが、複数のドメイン条件、IP判定、DNS処理、独自ルールセットを組み合わせると、最終的にはJSONの構造を理解したほうが原因を見つけやすくなります。この記事では、Xray-coreを利用するv2rayNやv2rayNGなどを想定し、2026年時点で一般的なルーティング設計を、実際のフィールド名と検証手順に沿って整理します。

ルーティングの役割と処理の流れ

Xrayのルーティングは、アプリケーションから受け取った接続要求を、条件に応じて特定のアウトバウンドへ渡します。代表的な出力先は、プロキシノードへ接続するproxy、通常のネットワークへ直接出るdirect、通信を破棄するblockです。ルールは「どの宛先か」「どのポートか」「どのプロトコルか」「どの入站から来たか」といった条件を組み合わせて記述できます。

重要なのは、ルールが通常は配列の先頭から順番に評価され、最初に一致したルールのoutboundTagが使われる点です。たとえば「すべてのドメインをプロキシ」というルールを先頭に置くと、その後ろに書いた国内ドメインの直結ルールは到達できません。例外を先に置き、広い条件を後ろに置くのが基本です。

• 最初に、明確にブロックしたい広告・不要な宛先を処理する。
• 次に、LANや国内サービスなど、直接接続したい例外を指定する。
• その後、ドメインやIPの分類ルールを適用する。
• 最後に、どの条件にも一致しない通信の既定動作を決める。

既定のアウトバウンドをJSON上で暗黙に任せるより、最後に包括的なルールを置いたほうが挙動を説明しやすくなります。ただし、最後のルールを広げすぎると、誤記したドメインまでプロキシへ送られます。設定を変更する前に、現在の設定をバックアップし、変更後はログと実際のアクセス結果を同じ条件で比較してください。

rulesで使う主なフィールドと優先順位

ルーティング設定の中心はroutingオブジェクトです。domainStrategyはドメインルールとIPルールをどの順序で組み合わせるかに関係し、rulesは個別の照合条件を配列で持ちます。各ルールには、たとえばdomain、ip、port、network、protocol、inboundTag、outboundTagを指定できます。

ドメイン条件では、完全一致、サフィックス一致、キーワード一致、正規表現などを用途に応じて使い分けます。一般的な分類ではgeosite:cnのようなルールセットを使い、特定のサービスだけを指定する場合はdomain:example.comやfull:login.example.comのような記法を検討します。利用できる分類名や記法は、組み込まれたXray-coreのバージョンとルールファイルに依存するため、インポート後のログで読み込みエラーがないか確認してください。

domainStrategyをAsIsにすると、受け取ったドメインを優先して判定し、IPルールのために積極的な名前解決を行いません。IPIfNonMatchでは、ドメイン条件に一致しなかった場合に名前解決を行ってからIP条件を確認します。国内ドメインを先に判定し、残った通信だけをIP分類へ送る構成では、IPIfNonMatchが分かりやすい出発点です。

プロキシ・直結・ブロックをJSONで組み立てる

まず出站のタグを固定し、その後にルーティングを作ります。次の例は構造を理解するための最小構成です。プロキシ側の詳細なサーバー情報は、利用するサブスクリプションから取得した設定を使ってください。ここでは、国内サイトとプライベートネットワークを直結し、指定した不要通信をブロックし、それ以外をプロキシへ送ります。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.net",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "outboundTag": "proxy"
      }
    ]
  }
}

1. 設定を保存

   v2rayNでは現在のプロファイルを複製してから編集し、v2rayNGでは設定のエクスポートで元ファイルを保存します。

2. タグを確認

   proxy、direct、blockがoutbounds側とrules側で同じ綴りになっているか確認します。

3. 例外を先置き

   広告ブロック、プライベートIP、国内ドメインの順に確認し、最後に既定のproxyルールを配置します。

4. コアを再起動

   設定を保存した後、「再起動」または「現在のサービスを停止して開始」を実行し、ログにJSON解析エラーがないか確認します。

この例のUUIDは説明用の値であり、そのまま接続に使うものではありません。VLESS、VMess、Trojanなどのプロトコルを手動で置き換える場合も、サーバー側のプロトコル、ポート、TLS、伝送方式、認証情報が一致していなければ接続できません。ルーティングだけを検証したい場合は、まず既存の正常なノードを維持し、出站とrules部分だけを変更するのが安全です。

DNS判定と分割ルーティングを組み合わせる

ルーティングとDNSは関連しますが、同じ処理ではありません。DNSはドメインをIPアドレスへ変換し、ルーティングは通信をどのoutboundへ渡すかを決めます。アプリケーションがドメイン名のまま接続要求を渡せる場合は、ドメインルールを先に適用できます。一方、IPだけが渡される通信や、geoip判定が必要な通信では、名前解決の方法とタイミングが結果に影響します。

国内ドメインをローカルDNS、国外ドメインをリモートDNSへ分ける場合は、DNSサーバーの条件と通常通信のルールを混同しないようにします。リモートDNSの問い合わせ自体をプロキシ経由にしたいなら、DNS用の出站タグを用意し、対応するDNS設定とルーティング条件を組み合わせます。DNSサーバーの入口がドメイン形式の場合、その名前を解決するための初期経路が必要になることもあります。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ]
      },
      "https://dns.example.net/dns-query"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "outboundTag": "proxy"
      }
    ]
  }
}

UseIPv4はIPv4だけを問い合わせる指定です。IPv6の到達性がないネットワークで、利用できないAAAAレコードを先に取得して待ち時間が増える場合に役立ちます。ただし、IPv6を実際に使う環境で一律にIPv4へ固定すると、経路の選択肢を狭めることがあります。DNS変更後は、ブラウザーのキャッシュだけでなく、Xray-coreを再起動して同じドメインへ再接続し、名前解決と出站の両方を確認してください。

カスタムルールセットの作成と運用

サービス固有のドメインを頻繁に追加する場合、rules配列へ長いドメイン一覧を直接書き続けるより、カスタムルールセットへ分離したほうが管理しやすくなります。たとえば仕事用、動画サービス、開発サービス、広告ドメインを別ファイルに分け、同じ分類を複数のクライアントで再利用します。ルールセットの形式、配置方法、読み込み記法はXray-coreやクライアントの対応状況によって異なるため、まず使用中のバージョンが外部ファイルをサポートしているか確認してください。

運用では、ドメインを追加した日付、追加理由、適用先のoutboundを記録します。ドメインの移転やCDN利用によってIPが変わるサービスを、固定IP一覧だけで管理するのは不安定です。可能な限りドメイン条件を優先し、IPの固定リストはLAN、既知の内部ネットワーク、どうしても必要な例外に限定します。

カスタムルールセットを更新した直後は、いきなり全通信へ適用せず、テスト用のプロファイルで読み込みエラーと一致結果を確認します。JSONの末尾カンマ、タグ名の誤記、ルールファイルの文字コード、相対パスの間違いは、設定全体が起動しない原因になります。v2rayNではコアのログ表示を開き、v2rayNGではログ画面から起動時エラーと接続先を確認してください。

適用後の検証とよくある問題

ルーティング変更後は、単に「接続できた」だけで成功と判断しないでください。直結対象、プロキシ対象、ブロック対象を少なくとも1件ずつ用意し、同じ端末、同じノード、同じネットワークでテストします。DNSキャッシュやブラウザーキャッシュの影響を避けるため、設定反映後にコアを再起動し、必要なら別のドメインでも確認します。

最終的には、ルーティングを「すべてをプロキシに送る設定」ではなく、通信要件を分類する設計として扱うことが大切です。先にdirect、proxy、blockの責任範囲を決め、次にドメイン、IP、ポート、ネットワーク条件を優先順位どおりに並べます。そのうえでDNSの解決経路とログを確認すれば、接続不良の原因がルールなのか、名前解決なのか、ノードや回線なのかを切り分けられます。設定を大きく書き換えるより、バックアップ、1項目の変更、再起動、3種類の通信テストという小さなサイクルを繰り返してください。