ルーターにXrayを導入するには、コアの起動だけでなく、通信の振り分け、DNS、障害時の復旧方法も考える必要があります。クライアントで接続できることを確認済みで、複数のLAN機器で出口を共有したい方に向けて、メインルーター・バイパスルーター・デスクトップでの運用を比較し、ハードウェア選び、1台での動作確認、トラブル対処の手順を解説します。コアを起動しただけで、ネットワーク全体のプロキシ設定が完了するわけではありません。
1. Xrayコアとルーターによる通信制御の違い
Xrayはプロキシプロトコル、インバウンド、アウトバウンド、ルーティングルールを処理するコアです。ルーターのファームウェアではなく、LAN全体を自動設定する機能もありません。ルーターに実行ファイルを置いて起動しても、構成の一部が動き始めたにすぎません。端末からの通信がコアに届くかどうかは、ゲートウェイ、システムの転送設定、ファイアウォールルール、インバウンド設定にも左右されます。
v2rayNはデスクトップ向けクライアント、v2rayNGはXrayコアを使用するAndroid向けクライアント、v2flyNGはV2Flyコアを使用するクライアントです。クライアント画面にあるサブスクリプション管理、ノード一覧、接続ボタンは、Xrayの実行ファイルをルーターにコピーしても使えるようにはなりません。サブスクリプションのテキストも、通常はXrayのJSON設定ファイルとしてそのまま読み込めません。
- アプリごとにプロキシを設定：アプリにプロキシのアドレスとポートを入力します。対象範囲が明確で、まずノードの接続を確認するのに適しています。LAN全体の通信をルーターで制御する必要はありません。
- 透過プロキシ：ゲートウェイのルールで対象の通信をコアに転送します。通常、端末ごとにプロキシを設定する必要はありませんが、ルーター側で転送、戻り経路、除外ルールを整える必要があります。
- DNS振り分け：DNS問い合わせをどのリゾルバーに渡し、どの出口から送るかを決めます。通信の振り分けに関係しますが、同じ処理ではありません。
2. 導入場所：デスクトップ、バイパスルーター、メインルーター
導入先を決める前に、対象となる端末の台数と、プロキシ切断時に通常の直接接続を許可するかを確認します。バイパスルーターは特定のソフトウェアではなく、ネットワーク上で端末のゲートウェイやポリシー転送を担う機器の役割です。専用の小型PCでも仮想マシンでも構いません。仮想マシンの場合は、仮想NIC、ブリッジ接続、ホスト側のリソース割り当ても確認してください。
まずはデスクトップで接続確認
おすすめまずv2rayNで、同じノードとネットワークを使って接続を確認します。目的のサービスにアクセスできたらゲートウェイへ移行しましょう。問題が起きても、ノード側とルーター側のどちらに原因があるか切り分けやすくなります。
おすすめの用途：初めての導入、PC 1台での利用、すぐに元へ戻したい場合
専用のバイパスルーター
メインルーターのPPPoE接続と通常のDHCP設定を維持し、選んだ端末だけをバイパスルーター経由にします。段階的にテストしやすい一方、デフォルトゲートウェイ、DNS、戻り経路の設計が必要です。接続しただけで設定が有効になるわけではありません。
おすすめの用途：複数端末で同じルールを使う場合、メインルーターの変更を抑えたい場合
メインルーターで直接運用
同じ機器でPPPoE接続、転送、名前解決、プロキシを処理するため、通信経路を集約できます。一方、アップデート、メモリ不足、ファイアウォール設定の誤りが、すべての端末のネット接続に影響するおそれがあります。
おすすめの用途：ハードウェアに余裕があり、メンテナンス時間と復旧手段を確保できる場合
LANポートが1つのバイパスルーターでは、送受信の通信が同じインターフェースを通ることがあり、スイッチング経路と戻り経路の確認が別途必要です。LANポートが2つあっても、必ず性能が上がるとは限りません。NICのドライバーが不安定だったり、CPUのシングルコア性能が不足したりすれば、高負荷時や複雑なルールの処理でボトルネックになります。ポートの公称速度をプロキシの実効速度とみなさないでください。
3. ハードウェア要件：余裕を持って選ぶ
すべてのノードやルールセットに共通する最低要件はありません。CPUアーキテクチャは実行ファイルの動作可否、メモリはルール数や接続数、書き込み可能なストレージはインストール、更新、ログ保存に関わります。以下は導入計画の目安であり、Xrayの公式最低要件や回線速度を最大限に引き出す保証値ではありません。
| 確認項目 | 計画の目安 | 確認方法 |
|---|---|---|
| CPU・アーキテクチャ | 対応ビルドが用意されているARM64またはx86-64の機器を優先 | uname -mを実行し、システムABIとパッケージのアーキテクチャを確認 |
| 本体メモリ | 軽い用途での試用は512 MiBを目安にし、複雑なルールや追加サービスを使う場合は1 GiB以上を検討 | free -mのavailableと、負荷が高い時間帯のログを確認 |
| 書き込み可能な空き容量 | 更新時の一時ファイルやデータファイルとは別に、256 MiB以上を確保するのがおすすめ | df -hで実際のインストール先のパーティションを確認。フラッシュ容量の公称値だけで判断しない |
| ネットワークインターフェース | 回線速度と、シングルNIC・デュアルNICの構成に合わせて選択 | 通常の転送とプロキシ経由の転送を個別にテストし、CPU使用率とパケットロスを比較 |
| 冷却・電源 | 継続的な負荷をかけても安定して動作することを確認 | 温度、クロック低下、再起動、LANポートの切断履歴を確認 |
フラッシュ容量の少ない機器では、コアの使用容量より先にログでパーティションが埋まり、障害が起きることがあります。通常は必要なエラーログだけを保存し、トラブル対処時のみ一時的にログレベルを上げてください。ログローテーションを設定するか、メモリ上にログを保存する方法もあります。外部ストレージを使う場合は起動時のマウント順を確認し、サービス起動時に設定ディレクトリがまだ使えない状態を防ぎましょう。
結論：実際の負荷で試す
実際に使うノードを1つ選び、30分間連続して動作させます。その間にウェブ閲覧、動画再生、DNS問い合わせを行い、空きメモリ、CPU使用率、温度を記録してください。リソースに余裕がなければ、まずルールや追加サービスを減らし、それから機器の交換を検討します。
4. バイパスルーターの試運転：接続する端末は1台ずつ
以下は一般的なOpenWrt LuCI画面を前提とした手順です。画面の翻訳やバージョンによって表示が異なる場合があります。例では、メインルーターを192.168.10.1、バイパスルーターを192.168.10.2、テスト端末を192.168.10.100とし、サブネットプレフィックス長はすべて/24です。これはアドレス設計の一例です。使用前に既存のネットワークとアドレスの使用状況を確認してください。
-
現在の設定を保存
LuCIの「システム」→「バックアップ／アップグレード」で設定をバックアップし、現在のゲートウェイとDNSを記録します。メインルーターをゲートウェイとして使う管理用端末を1台残し、有線接続で管理画面にアクセスできることを確認してください。
-
管理用IPアドレスを固定
「ネットワーク」→「インターフェース」→「LAN」→「編集」→「一般設定」を開き、バイパスルーターのアドレスを192.168.10.2に設定します。選択したシングルNIC構成では、バイパスルーターの上流ゲートウェイを192.168.10.1に設定し、このアドレスがDHCPの動的割り当て範囲に含まれていないことも確認してください。
-
アドレス割り当てを確認
メインルーターでアドレスを一元管理する場合は、バイパスルーターの「ネットワーク」→「インターフェース」→「LAN」→「編集」→「DHCPサーバー」→「一般設定」で「このインターフェースを無視する」にチェックを入れます。IPv6のRAとDHCPv6の設定も確認し、計画外のゲートウェイ広告が発生しないようにしてください。
-
コアの設定を確認
機器のアーキテクチャに合ったXrayと実際に使用する設定を用意し、設定ファイルを検証してからプロセスを起動します。まずアプリごとのプロキシ設定で外部接続を確認し、その後、選択した方式に合わせて転送、インバウンド、除外ルールを設定します。この段階では、ネットワーク全体のDHCP設定を変更しないでください。
-
テスト端末を切り替え
テスト端末1台だけで、IPv4のゲートウェイを192.168.10.2に変更します。バイパスルーターでDNSサービスが正常に動作している場合は、DNSも同じアドレスに変更します。ローカル管理画面、直接接続する通信、プロキシ経由の通信をそれぞれ確認してから、対象を段階的に広げてください。
上記のアドレス設定でできるのは基本的なネットワーク構成までで、透過プロキシのルールは完成していません。同一サブネットのシングルNIC構成では戻り経路が非対称になる場合があり、送信元NATが必要かどうかは転送方式や通信の取り込み方によります。パケットキャプチャ、コネクショントラッキング、コアの要件を踏まえて検証してください。出所が不明なファイアウォールコマンドを一括で本番ルーターに貼り付けないでください。
# 以下のコマンドは確認用です。パスは実際のインストール先に合わせてください
uname -m
free -m
df -h
ip route
xray version
xray run -test -config /etc/xray/config.json
# OpenWrtで最近のシステムログを確認
logread | tail -n 80
# nftablesを使うシステムで現在のルールを確認
nft list ruleset5. 透過プロキシとDNS：2つの経路を整理
透過プロキシでは通常、通信をどのインバウンドに渡すかと、DNS問い合わせをどのリゾルバーに渡すかという2つの経路を設定します。LinuxのREDIRECTとTPROXYは同じものではありません。REDIRECTはTCPのリダイレクトによく使われます。TPROXYでTCPやUDPを取り込む場合は、カーネルの対応に加え、パケットマークとポリシールーティングを連携させる必要があります。リダイレクトルールを1つ追加しただけで、UDPも使えるとは限りません。
振り分けルールでは、照合の順序とデフォルトの転送先も明確にしてください。ドメイン名で照合する場合、コアがドメイン名を取得できるかを考慮する必要があります。クライアント側で接続先がすでにIPアドレスに解決されていたり、アプリが独自の暗号化DNSを使ったりすることがあるためです。スニッフィングで情報を補える通信もありますが、すべての接続で元のドメイン名を取得できるわけではありません。
10808と12345はこの記事の設定例にすぎず、すべてのクライアントやルーターで固定のデフォルト値として使われるものではありません。ポート番号が異なっていても、ファイアウォールの転送先が実際のインバウンドと一致していれば問題ありません。DNSの53番ポートではUDPとTCPの両方を考慮し、どちらか一方だけに限定しないでください。
- 基本的なネットワーク通信を除外：DHCP、必要なマルチキャストとブロードキャスト、LANの管理用アドレス、コア自身の通信を残し、誤ってプロキシに送らないようにします。
- プロキシループを防止：ノードサーバーへの外部接続は通常の出口を通し、透過プロキシのルールで元のインバウンドへ戻されないようにします。ノードのアドレスがドメイン名の場合は、IPアドレスの変更や起動時の名前解決も考慮してください。
- 名前解決の役割を分ける：LAN内のホスト名は通常ローカルのリゾルバーで処理し、一般のドメイン名はポリシーに応じた上流DNSを使います。リゾルバー自身の通信経路も計画に沿っている必要があります。
- IPv6を個別に確認：IPv4だけで通信を取り込む設定では、端末がIPv6で直接接続する可能性があります。IPv4・IPv6の両方に対応したルールを設定するか、テスト範囲でIPv6の広告と接続経路を明確に無効化してください。
- 待ち受け範囲を制限：LAN向けのDNSやプロキシのインバウンドをWANに公開しないでください。待ち受けアドレスとファイアウォールを組み合わせ、接続元を制限します。
6. よくあるトラブル：ゲートウェイ、DNS、外部接続の順に確認
トラブル対処では、一度に変更する条件を1つに絞ります。まず端末が想定どおりのゲートウェイを取得しているか、次にDNSの応答、最後に接続が正しいアウトバウンドへ進んでいるかを確認してください。ブラウザーでページを再読み込みするだけでは、キャッシュ、接続の再利用、アプリ独自の名前解決が混在し、問題の発生箇所を特定しにくくなります。
ゲートウェイを変更したのに、以前の出口を使うのはなぜ？
まず端末の実際のルーティングテーブルとIPv6のデフォルトルートを確認し、古いリースやRAが引き続きメインルーターを指定していないか調べます。次に、バイパスルーターで通信取り込みルールが実際に適用されているか確認してください。デフォルトゲートウェイをバイパスルーターに変更しても、通信がそこを通ることが分かるだけで、Xrayに届いているとは限りません。
IPアドレスには接続できるのに、ドメイン名を開けないのはなぜ？
nslookupに対応したテスト端末でnslookup example.com 192.168.10.2を実行し、問い合わせがタイムアウトしないか確認します。バイパスルーターでDNSを待ち受けていない場合、端末のDNSにそのアドレスを指定しないでください。続けて、DNSサービスの待ち受けアドレス、53番ポートのルール、上流への通信経路を確認します。
ウェブは見られるのに、ゲームや音声通話が使えないのはなぜ？
UDPが想定したインバウンドに届いているか、アウトバウンドが必要な転送に対応しているか、ポリシールーティングが正しく設定されているかを確認します。TCPのウェブ閲覧が成功しても、UDPが使えるとは限りません。特定のアプリとログで確認し、1回のTCP遅延テストだけで経路全体が正常だと判断しないでください。
再起動後にネットワーク全体が切れた場合、まず何を戻す？
まずテスト端末のゲートウェイとDNSを元の値に戻し、残しておいた管理用端末からログインします。コア、DNSサービス、ファイアウォールルールの起動順序を確認してから、時刻同期とストレージのマウントを調べてください。サービスの復旧を確認してから通信の取り込みを再開し、原因が分からないまま再起動を繰り返さないようにします。
障害時の動作も事前に決めておきます。コアが停止した場合に、対象の通信を直接接続させるのか、それとも遮断するのかを選び、どちらの場合も明示的に設定して実際にテストしてください。メンテナンス時間中にコアを一度停止し、端末の動作が想定どおりか確認できます。「プロセスが自動再起動する」だけでは、十分な復旧対策になりません。
7. 動作確認と選択：複数端末で必要な場合に移行
ルーターで運用する利点は、ルールを一元管理でき、端末ごとにプロキシを設定しにくい機器も対象にできることです。その反面、ネットワーク障害の影響範囲は広がります。PC 1台だけで使う場合は、v2rayNのノード切り替え、ログ確認、設定の復元がより簡単です。Android端末では、まずv2rayNGでXrayノードを確認できます。v2flyNGを使う場合は、ノードとV2Flyのプロトコル互換性を別途確認してください。
- 機能テスト：直接接続する宛先、プロキシ経由の宛先、LAN内サービス、DNS、UDPを個別に確認します。1つのウェブページだけですべてを判断しないでください。
- 性能テスト：同じノードを使い、近い時間帯にデスクトップとルーターの通信速度を比較します。CPU、メモリ、温度も記録し、ノードの混雑と機器側のボトルネックを切り分けてください。
- 再起動テスト：バイパスルーターを再起動し、端末のリースを更新して、アドレス、ルール、DNS、外部接続がすべて復旧するか確認します。管理画面が開くだけでは不十分です。
- 復旧テスト：ゲートウェイ、DNS、通信取り込みルールを元に戻す具体的な手順を記録します。バックアップから復元できることを確認し、テスト経路を通らない管理用の接続手段も残してください。
1台での動作確認が終わったら、端末またはアドレスのグループごとに適用範囲を広げます。ファームウェアの入れ替え、コアのアップデート、ノードの切り替え、DNSルールの変更を同時に行わないでください。変更を分ければ、ログと比較テストで各手順の効果を判断できます。