ルーター・バイパスルーターでのXray導入ガイド｜必要なハードウェア・透過プロキシ・ルーティング

1. ハードウェア選び：CPUアーキテクチャと空きメモリを確認

Xrayは接続、プロトコル、ルーティングを処理するコアであり、ルーター用ファームウェアでも、汎用のルーター管理画面でもありません。Linuxが動作する機器でも、任意のXrayバイナリをそのまま実行できるとは限りません。CPUアーキテクチャ、命令セット、システム環境、書き込み可能なストレージが一致している必要があります。ダウンロード前にuname -mでアーキテクチャを、free -mとdf -hでメモリとストレージの空きを確認してください。

以下は導入時の予算目安であり、動作に必要な最低条件やスループットを保証するものではありません。同時接続数、ルールの規模、暗号化処理、ログ量によって必要なリソースは変わります。製品パッケージに記載された無線速度も、プロキシ転送性能の目安にはなりません。

2. メインルーターとバイパスルーター：通信経路を整理する

メインルーターは通常、PPPoE接続、NAT、DHCP、デフォルトゲートウェイを担当します。バイパスルーターはLANに追加する転送機器で、ケーブルを接続しただけで家庭内の通信を自動的に取り込むわけではありません。Xrayで接続を処理するには、対象の通信を端末からバイパスルーターへ送るか、メインルーターのポリシールーティングで転送する必要があります。

• メインルーターに導入：端末の通信がもともと通過する機器に導入するため、制御箇所を集約できます。一方、Xrayやファイアウォール、ルーティングの設定ミスがネットワーク全体に影響する可能性があります。
• 同一サブネットのバイパスルーター：たとえば、メインルーターを192.168.10.1、バイパスルーターを192.168.10.2、テスト端末を192.168.10.100とし、サブネットマスクをすべて255.255.255.0にします。端末のデフォルトゲートウェイをバイパスルーターに変更し、バイパスルーターの上流ゲートウェイはメインルーターに設定します。
• 独立した下流サブネット：バイパスルーターの2つのインターフェースまたはVLANを使い、テスト端末を別のサブネットに配置します。経路を把握しやすくなりますが、転送、ファイアウォール、戻りルートまたは送信元アドレス変換も設定する必要があります。

同一サブネット方式では、バイパスルーターを通らない直接通信の戻り経路や、ICMPリダイレクトによって端末の経路が変わらないかも確認します。送信元アドレス変換を有効にするかは、実際の構成とコネクション追跡の要件で決まります。「バイパスルーターでは必ずNATが必要」と一律には言えません。最初は端末1台だけを変更し、ip routeやOSのルーティング確認ツールでデフォルトゲートウェイを確認してください。

3. 透過プロキシ：通信の取り込み方とプロキシプロトコルは別

透過プロキシは通信を取り込む方法を指し、VLESSやVMessに代わるプロトコルではありません。端末側でアプリのプロキシアドレスを指定せず、ゲートウェイのリダイレクトやポリシールーティングで通信をXrayに渡します。TCP、UDP、IPv6を制御できるかどうかは、Linuxのネットワーク設定、インバウンド設定、プロキシのアウトバウンド、サーバー側の対応状況によって異なります。

Xrayで一般的なLinux透過接続方式では、dokodemo-doorインバウンドを使い、followRedirectで元の宛先を取得します。TPROXY方式では、対応するstreamSettings.sockopt.tproxyの設定も必要です。これらのJSON項目を追加しただけでは、ファイアウォールルールやポリシールーティングは作成されず、システムの転送機能も有効になりません。

OpenWrt 22.03以降では、通常firewall4とnftablesが使われます。firewall3を前提とした古いiptablesの解説は、そのまま適用できません。実際のファームウェア、モジュール、互換レイヤーを確認してください。デスクトップ版v2rayNのTUNスイッチも、ルーター上のXray設定にそのままコピーできる単一の項目ではありません。詳しくはTUN設定の解説をご覧ください。

4. 設定ファイルとサービス：まず明示的なプロキシで動作確認

設定ファイルのパスは起動コマンドで決まり、ファイル名だけでは決まりません。/etc/xray/config.jsonはよく使われる配置例です。パッケージや管理画面によって別のディレクトリが使われたり、/var以下に実行時ファイルが生成されたりする場合もあります。生成されたファイルを直接編集すると、次回の保存や再起動で上書きされることがあるため、まず設定の保存元を確認してください。

1. ネットワーク情報を記録する

   OpenWrt LuCIの「ネットワーク」→「インターフェース」で、LANアドレス、上流ゲートウェイ、インターフェース名を記録します。「システム」→「バックアップ／更新」から設定のバックアップも取得してください。全端末に配布するDHCP設定は、まだ変更しないでください。

2. 起動設定を確認する

   xray versionを実行して、Xrayが起動できることを確認します。systemdを使う環境では、systemctl cat xrayに表示されるExecStartを確認してください。OpenWrtでは/etc/init.d/xrayと、そこから読み込まれる設定を調べ、実際のファイルパスを確認します。

3. 設定ファイルを検証する

   実際の設定ファイルがこの一般的なパスにある場合は、xray run -test -config /etc/xray/config.jsonを実行します。構文エラー、認識されない項目、ルールファイルの読み込みエラーを先に修正してからサービスを起動してください。設定テストの成功は、リモートノードへの接続を保証するものではありません。

4. ローカルで動作確認する

   まずSOCKSインバウンドを127.0.0.1:10808だけで待ち受けるようにします。curl --proxy socks5h://127.0.0.1:10808 https://example.com/で接続を確認し、ログで選択されたアウトバウンドも確認してください。ウェブページが開いただけでプロキシ経由と判断しないでください。

5. 1台の端末で通信を取り込む

   明示的なプロキシと実際のノードを確認してから、テスト端末1台に透過ルールを適用します。DNS、TCP、UDP、IPv6を個別にテストし、管理画面に引き続きアクセスできることを確認してから、送信元アドレスの範囲を広げてください。

以下は設定の構造を理解するための、ローカル直接接続の基本例です。接続可能なプロキシノードを含む完成済み設定ではありません。リモートサーバーのパラメーターも透過インバウンドもなく、SOCKSで受け付けた通信はすべてfreedomで直接接続します。現在のサービスで使っている設定がある場合は、そのまま上書きしないでください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

サブスクリプションURLもXrayの起動引数ではありません。クライアント用サブスクリプションにはBase64エンコードされた共有リンクが含まれる場合や、特定の管理ツール向けの形式が使われる場合があります。設定ファイルとして読み込めるのは、Xrayの設定構造に準拠したJSONだけです。サブスクリプション管理ツールを使う場合は、生成されるアウトバウンド、タグ、ルールファイルを確認し、手動編集した内容が更新処理で上書きされないようにしてください。

5. DNSとルーティング：2つの経路をあわせて確認

適切なルーティングには、「接続先」と「ドメイン名の名前解決方法」の両方を把握する必要があります。Xrayのrouting.rulesは上から順に評価され、ルール内のoutboundTagは実在するアウトバウンドのタグを指定しなければなりません。一致するルールがない場合、通常は最初のアウトバウンドが使われます。ドメインルール、IPルール、デフォルトのアウトバウンドの順番は、期待する動作を先に明確にしてから設定に反映してください。

それぞれ用途が異なるため、これらのポートは相互に置き換えられません。12345は設定例として使いやすい値であり、自動的に有効になるシステムのデフォルトポートではありません。ファイアウォールの転送先とXrayの待ち受けポートを一致させてください。認証のないSOCKSポートをインターネットに公開しないでください。LANからアクセスさせる場合も、待ち受けアドレスとファイアウォールで接続元を制限してください。

• LANと管理用アドレス：まず直接接続する範囲を決め、ルーターの管理画面、ネットワークストレージ、プリンターへのアクセスがリモート側のアウトバウンドへ流れないようにします。
• ドメインルール：透過接続で取得できるのは宛先IPだけの場合があります。一部のプロトコルではスニッフィングでドメイン名を判別できますが、すべてのドメインを復元できるとは限らず、通信内容の復号を意味するものでもありません。
• 名前解決の方針：routing.domainStrategyは、ルーティング照合時のドメイン名の解決方法を制御する項目です。システム全体のDNSサーバーを切り替える設定ではありません。Xray内蔵DNS、アウトバウンド側の名前解決、端末のDNSはそれぞれ別の処理です。
• DNSの処理経路：端末からの問い合わせは、まずルーターのdnsmasqに届き、そこから別のDNSサービスへ転送される場合があります。Xrayにdnsを設定しただけでは、端末のDNS問い合わせが自動的にXrayへ送られるわけではありません。
• IPv6の経路：IPv4の透過ルールだけを設定すると、端末の通信がメインルーターのIPv6デフォルトルートから外へ出る場合があります。AAAAレコードの名前解決、IPv6ゲートウェイ、通信を取り込む範囲を個別に確認してください。

VLESSノードを使う場合、接続先アドレス、ポート、ユーザーID、トランスポート方式、安全性の設定はサーバー側と一致させる必要があります。ルーターへ導入しても条件は変わりません。VMessとVLESSはプロキシプロトコル、TCPやWebSocketなどはトランスポート関連の設定です。プロトコル名だけから機器のスループットを判断することはできません。各項目の意味はルーティング設定リファレンスと用語集をご覧ください。

6. よくあるトラブル：症状から原因を絞り込む

トラブル対応時は、バイパスルーターを経由しない管理用端末を1台確保してください。まず元のゲートウェイとバイパスルーターのゲートウェイで結果を比較し、DNS、Xrayのログ、ファイアウォールのカウンターを確認します。MTU、プロトコル、DNS、ルーティングルールを同時に変更すると、原因を特定しにくくなります。

7. 導入後の確認：1台からネットワーク全体へ広げる

各端末にクライアントを入れずに利用するには、対象端末の通信が設定したゲートウェイを通り、DNS、IPv4、IPv6の方針も一致している必要があります。独立したネットワーク、手動ルーティング、独自の暗号化DNSを使う端末は同じ経路を通らない場合があるため、端末の種類ごとに確認してください。

• 基本接続：LAN内の管理画面、直接接続するサイト、プロキシ経由にする接続先をテストし、ログに記録されたアウトバウンドの方向を確認します。
• プロトコルの対応：TCP、実際に利用するUDPアプリ、IPv6を個別に確認します。ブラウザーで速度測定を1回行うだけでは不十分です。
• 性能の確認：同じ接続先、同じ時間帯で直接接続とプロキシ経由を比較し、CPU使用率、空きメモリ、接続数を記録します。単発のピーク値を継続的なスループットと見なさないでください。
• 再起動後の復旧：バイパスルーターを再起動してから、サービス、DNS、ポリシールーティング、ファイアウォールルールを再確認し、一時的なコマンドに依存していないことを確認します。
• 障害時の復旧：Xrayサービスを停止するテストを行い、管理用端末からメインルーターへアクセスできることと、ほかの端末のゲートウェイおよびDNSを元に戻す方法を確認します。

ノードの利用可否をまだ確認できていない場合は、先にデスクトップ版v2rayNまたはAndroid版v2rayNGで端末単体の動作を確認すると、ノードの問題とゲートウェイの問題を切り分けやすくなります。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用するため、各コアの機能や設定形式を別々に確認してください。端末単体での確認後、接続パラメーターとルーティング方針をルーター環境へ移行します。クライアントのデータディレクトリ全体をそのままコピーしないでください。