Xrayをルーター・バイパスルーターで動かす方法｜透過プロキシの構成ガイド

Xrayコアとクライアントの役割を整理する

Xrayは、インバウンド、アウトバウンド、ルーティングルールを処理するコアプログラムです。v2rayNは設定を管理してコアを呼び出すデスクトップクライアントです。v2rayNで使えるノードをルーターに移しても、デスクトップのプロキシ環境全体が移行するわけではありません。Linuxゲートウェイでは、ファイアウォールルール、転送設定、DNSサービス、起動管理も必要です。

VMessやVLESSはプロキシプロトコルであり、透過的に通信を取り込む方式ではありません。ノードのプロトコル、トランスポート層、TLSまたはREALITYのパラメーターはサーバー側と一致させる必要があります。REDIRECTやTPROXYは、LAN内の通信をどのようにローカルのコアへ渡すかを決める仕組みです。アウトバウンド接続が成功しても、正常なのは構成要素の一つにすぎません。

• コア設定：待ち受けインバウンド、ノードのアウトバウンド、直接接続の出口、ドメインやIPのマッチングルールを定義します。
• システムネットワーク：対象端末の通信をインバウンドへ転送し、応答が元の端末に戻るようにします。
• DNS経路：名前解決を行うプロセス、問い合わせの経路、取得した結果とルーティングルールの連携を決めます。
• サービス管理：起動・再起動、ログ、権限、障害時の復旧を管理します。ノード共有リンクでは設定されません。

主ルーターとバイパスルーター：障害の影響範囲で選ぶ

主ルーターは通常、PPPoE接続、DHCP、NAT、デフォルトゲートウェイを担います。通信を取り込む位置が明確な一方、ルールを誤るとネットワーク全体に影響するおそれがあります。バイパスルーターなら実験環境を主ルーターから切り離し、まず1台の端末に対象を限定できます。その代わり、デフォルトゲートウェイ、DNS、戻り経路を明確に設計する必要があり、LANケーブルをつなぐだけで通信が自動的に経由するわけではありません。

同一サブネットのバイパスルーターを例にすると、主ルーターは 192.168.10.1、バイパスルーターは 192.168.10.2、テスト端末は 192.168.10.100 です。バイパスルーターのデフォルトルートは主ルーターに、テスト端末のデフォルトゲートウェイはバイパスルーターに向けます。各アドレスが未使用であることを確認し、固定アドレスはDHCPのアドレスプールから除外してください。

透過プロキシの経路：REDIRECTとTPROXYの違い

透過プロキシを使うと、HTTPやSOCKSプロキシを手動設定していない端末の通信も、ゲートウェイのルールに沿って転送できます。一般的な経路は「端末 → ゲートウェイのファイアウォール → Xrayインバウンド → ルーティング選択 → アウトバウンド」です。通信がゲートウェイを通っていなければ、Xrayのルーティングルールを変更しても効果はありません。

TPROXYはファイアウォールルールを1つ追加するだけでは動作しません。カーネルとファイアウォールのバックエンドが必要な機能に対応していること、マークしたパケットをポリシールーティングでローカルに転送すること、Xrayインバウンドに透過プロキシの設定があることを確認してください。nftablesを使うシステムに、出所不明のiptablesスクリプトをそのまま混在させないでください。互換コマンドが使える場合も、実際に生成されたルールを確認しましょう。

• 予約済みアドレスを先に除外：実際のネットワークに合わせて、ループバック、LAN、ブロードキャスト、マルチキャストなどプロキシ対象外の宛先を除外し、ルーター管理やDHCPの通信を維持します。
• ノードへの接続を除外：プロキシサーバー自身への接続を同じインバウンドで再度取り込むと、ループが発生します。
• 転送通信とローカル通信を区別：転送される通信とゲートウェイ自身が生成する通信では通過するフックが異なります。初回導入では、LANからの転送通信だけを対象にしてください。
• マークの競合を防止：ポリシールーティング用のマークは、マルチWANやトラフィックシェーピングなどと共用される場合があります。使用前に既存ルールとマスクを確認してください。

トラブル対応のためにファイアウォール全体を無効にしないでください。透過プロキシの待ち受けポートは必要な接続元だけに許可し、WAN側に公開しないようにします。ログに権限エラーが出た場合は、透過ソケットに必要な機能とサービスの実行ユーザーを確認してください。すべてのサービスを恒常的に高い権限で実行するのは避けましょう。

DNS振り分け：名前解決と通信の出口をそろえる

Webページが開けないからといって、ノードの障害とは限りません。端末が引き続き主ルーターから配布されたDNSを使っている場合や、アプリ内の暗号化DNSが想定した経路を迂回している場合があります。DNS問い合わせがバイパスルーターに届いていても、DNSサーバーへの通信経路と実際のアクセス経路が異なると、利用中の出口に適さないIPアドレスが返ることがあります。

ここで使う 12345 は説明用に選んだポート番号で、Xrayの固定ポートではありません。ファイアウォールの転送先ポートとインバウンドの待ち受けポートを一致させてください。従来型DNSはUDPとTCPの両方を使う場合があるため、UDP 53だけを許可する設定では不十分です。暗号化DNSの経路も、ポート53のルールだけから判断できません。

1. 端末への配布を確認：ルーター画面の上流DNSアドレスを変更しただけでなく、端末が実際に取得したDNSアドレスが想定した名前解決の入口を指しているか確認します。
2. 個別に検証：LAN内のドメイン、直接接続するドメイン、プロキシ経由でアクセスするドメインをそれぞれテストし、応答されたアドレスと最終的な出口を記録します。
3. 接続前の名前解決を確認：ノードの接続先がドメイン名の場合、プロキシ接続を確立する前に名前を解決できるようにします。「名前解決にはプロキシが必要、プロキシ接続には名前解決が必要」という依存ループを避けてください。
4. キャッシュを処理：ルールを変更した後は、端末とゲートウェイの関連キャッシュを削除してテストアプリを再起動し、古い名前解決結果や接続が検証を妨げないようにします。

ドメインによる振り分けは、宛先情報の取得元にも左右されます。透過インバウンドで取得できる元の宛先は、一般にIPアドレスです。トラフィックのスニッフィングでプロトコルからドメインを補える場合もありますが、すべての接続で復元できるとは限りません。ドメインルールが必要な場合は、DNSの設計、スニッフィング設定、ルールの順序を合わせて確認してください。スニッフィングを有効にするだけでは不十分です。

段階的な導入：アウトバウンドの確認から1台の端末の通信取り込みまで

以下では、一般的なLinuxゲートウェイでの作業手順を紹介します。設定ファイルの場所やサービス名はインストール方法によって異なります。コマンド内の /etc/xray/config.json と xray.service は具体例です。実行前に実際のパスを確認してください。軽量ファームウェアでは別のサービス管理方式を使う場合があります。

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

   主ルーターのアドレス、DHCP範囲、DNS、インターフェース名、ファイアウォールルールを保存します。変更中のリモート接続だけに頼らず、有線接続やローカルコンソールから設定を復旧できることを確認してください。

2. アウトバウンドを検証

   プロセッサーのアーキテクチャとXrayのバージョンを確認し、まずノード設定をテストします。ループバックアドレスだけで待ち受ける明示的プロキシを使ってアウトバウンドを検証し、全端末を対象にするルールはまだ追加しません。

3. インバウンドを確認

   透過インバウンドのポートを決め、ポートが使用中でないことを確認します。TPROXYを使う場合は、インバウンドの透過設定、システムの対応状況、ポリシールーティング、マークを合わせて確認してください。プロセスが起動していることだけでは不十分です。

4. 1台の端末から通信を取り込む

   テスト端末 192.168.10.100 の通信だけを対象にします。まずTCPをテストし、次にUDP転送に対応したアウトバウンドを使って実際に確認してください。Webページが開けたことをUDPの検証の代わりにしないでください。

5. 名前解決を連携して検証

   テスト端末のDNSを設定済みの名前解決用入口に向けます。直接接続、プロキシ経由、LAN内アクセス、IPv6の各経路を個別に検証し、コアとファイアウォールのログも確認してください。

6. 再起動後の復旧を確認

   ゲートウェイを再起動し、サービスの起動順序とルールの永続化を確認します。コアの停止を想定したテストを行い、あらかじめ決めた障害時の動作を検証してから、DHCPで対象範囲を広げるか判断してください。

読み取り専用の確認を先に行い、転送ルールは後から変更する

# プログラムのバージョンと設定を確認；設定テストに合格してもリモート接続できるとは限らない
xray version
xray run -test -config /etc/xray/config.json

# IPv4・IPv6のルートとIPv4のポリシールートを確認
ip -4 route show
ip -6 route show
ip -4 rule show

# 待ち受けポートと現在のnftablesルールを確認
ss -lntup
nft list ruleset

# systemdを使用し、サービス名がxrayの場合のみ
systemctl status xray --no-pager
journalctl -u xray -n 80 --no-pager

ルールやプロセス情報の確認には、管理者権限が必要な場合があります。ルールを確認する際は、テスト通信に応じてマッチカウンターが増えているか見てください。増えない場合は、インターフェース、送信元アドレス、チェーンの適用位置を先に確認します。カウンターが増えてもコア側に対応する記録がなければ、ポート、ポリシールーティング、インバウンド設定を調べます。どの変更が効いたのか分からなくなるため、複数の層を一度に変更しないでください。

ルーティングと性能：根拠をもとにボトルネックを特定

ルーティングルールは通常、記述順に照合されますが、プロトコル、ドメイン判定ポリシー、IPアドレスの解決方法にも左右されます。まずLAN向けルールと必要な例外を明示し、その後に用途別の振り分けとフォールバックの出口を設定します。送信元アドレス、ドメイン、宛先IPを併用して管理する場合は、各ルールの目的を記録しましょう。試しにルールの位置を入れ替えるだけの運用は避けてください。

ルーターの公称無線速度をプロキシの実効速度と混同しないでください。暗号化、接続数、単一コアの性能、放熱はいずれも結果に影響します。テストには有線端末を使い、ノードと測定先を固定してCPU使用率を記録しましょう。速度測定のピーク値を一度見るだけでは、無線干渉とゲートウェイの処理能力を切り分けられません。

• IPv6：IPv4だけを対象にしても、すべてのアプリの通信がプロキシを経由するとは限りません。ルーター広告、IPv6のデフォルトルート、ファイアウォール、DNSのAAAA応答を確認し、IPv6も個別に取り込むのか、直接接続を維持するのかを明確にします。
• トラフィック高速化：ハードウェアまたはソフトウェアのオフロードによって、想定したルールを通信が迂回する場合があります。管理された範囲で関連機能を一時停止して比較し、互換性を確認してから元に戻してください。
• リバースパスの確認：複雑なポリシールーティングは、厳格な検証と競合する場合があります。まずインターフェース設定とパケット損失の根拠を確認し、必要な箇所だけ調整してください。全体を無効にするコマンドをそのまま使うのは避けましょう。
• 障害時の動作：コアが停止した場合、プロキシ通信も停止させるのか、直接接続に切り替えるのかを明確に設計してください。後者では通信の出口が変わるため、暗黙の標準動作にしてはいけません。

よくある質問：バイパスルーターで通信を取り込んだ後のトラブル対処

導入後は、いつでも元に戻せるよう設定内容を記録してください。端末のゲートウェイとDNS、バイパスルーターのアドレス、透過プロキシのポート、ルールの適用位置、サービス名、障害時の動作を残します。コアの更新やサブスクリプションの変更後も、「アウトバウンド → 通信の取り込み → DNS → デュアルスタック → 再起動」の順に再検証してください。コアや名前解決の基礎はコアの解説とDNS設定の解説をご覧ください。