V2Rayをルーターに導入する方法｜ルーター直結とバイパスルーターの構成・比較

この記事の概要

デスクトップクライアントでは接続できるのに、ルーターに切り替えると一部の端末が通信できない。そんなときはノードを変える前に、通信の取り込み方、DNS、戻り経路を確認しましょう。家庭内ネットワークを見直す方向けに、クライアントとコアの違いを整理し、メインルーター直結とバイパスルーターを比較。1台での試運転、DNSの確認、問題発生時の切り戻し手順を紹介します。IPアドレスとポート番号は設定例であり、ソフトウェアの初期値ではありません。

クライアント・コア・ゲートウェイの役割を把握する

サブスクリプションURLをルーターに入力しただけでは、ゲートウェイとして使えるわけではありません。v2rayNはノード管理や設定生成、コアの起動を行うデスクトップ用GUIクライアントです。ルーターでは通常、OSやCPUアーキテクチャに対応したV2RayまたはXrayコアを動かし、サービス管理機能とファイアウォールルールを組み合わせて通信を転送します。デスクトップ用インストーラーをそのままルーターにコピーしても実行できません。

V2RayとXrayでは設定や機能に違いがあります。VMessとVLESSはプロキシプロトコル、WebSocketなどはトランスポート方式です。ノードで使うプロトコル、トランスポート、セキュリティ関連の設定は、選択したコアに対応している必要があります。サブスクリプションをv2rayNに取り込めたからといって、ルーター側の変換ツールやコアもすべての項目に対応しているとは限りません。

ノード接続層：認証と暗号化を行い、サーバーとの接続を確立します。まず1つのノードで動作を確認してから、ネットワーク全体の通信を取り込みましょう。
通信の入口：明示的なHTTP/SOCKSプロキシは、そのプロキシを指定したアプリの通信だけを受け付けます。透過プロキシには、通信のリダイレクトやポリシールーティングの設定が別途必要です。
ゲートウェイ層：端末の次の転送先、DNS、IPv4/IPv6、ファイアウォールを処理します。待ち受けポートを1つ起動しただけでは、LAN内の通信は自動的に取り込まれません。

構成を選ぶ：元に戻せる接続経路を確保する

家庭内でプロキシが必要な端末が1～2台だけなら、まずデスクトップ用またはAndroid用クライアントを使うと問題を切り分けやすくなります。デスクトップ用はv2rayN、Android用はXrayコアを使うv2rayNGとV2Flyコアを使うv2flyNGです。複数端末で同じポリシーを共有したい場合や、端末ごとにプロキシを設定できない場合に、ゲートウェイの運用を検討しましょう。

バイパスルーターを1台で試す

メインルーターにコアを直接導入

接続、転送、DNS、プロキシを1台に集約できるため、通信経路がシンプルになり、ポリシーも一元管理できます。一方、コアのアップデート、ルールの誤設定、リソース不足が起きると、家全体の通信に影響する可能性があります。設定のバックアップと、現地で操作できる管理手段を用意してください。

向いているユーザー：十分なハードウェアリソースがあり、ファイアウォールやシステムサービスを管理できる方。

端末ごとのクライアントを使い続ける

端末ごとにノードやルーティングを選べるため、家庭内のデフォルトゲートウェイを変更せずに済みます。設定の更新やトラブル対応を個別の端末に限定できますが、各端末で設定を管理する必要があります。システムプロキシを使わないアプリは、別途対応が必要です。

向いているユーザー：端末が少なく、外出先でも使い、アプリごとにポリシーを変えたい方。

IPアドレスを設計する：バイパスルーターは接続するだけでは機能しない

同一サブネットで1つのLANポートを使う構成を例にします。メインルーターを192.168.10.1/24、バイパスルーターを固定アドレスの192.168.10.2/24、テスト用PCを192.168.10.100/24とします。バイパスルーター自身のデフォルトルートはメインルーターを指し、テスト用PCのデフォルトゲートウェイはバイパスルーターを指します。この例は、2つのLANポートを使う構成や複数VLANの構成には当てはまりません。

対象	設定例	確認ポイント
メインルーター	`192.168.10.1`	インターネット接続とDHCPを引き続き提供します。
バイパスルーター	`192.168.10.2`	固定アドレスを割り当て、動的アドレスプールとの重複を避けるか、DHCP予約を設定します。
テスト用PC	`192.168.10.100`	デフォルトゲートウェイを一時的に`192.168.10.2`へ手動で変更します。
テスト用PCのDNS	`192.168.10.2`	バイパスルーターで到達可能なDNSサービスが稼働していることを確認してから設定してください。

同一サブネットで1つのLANポートを使う構成では、非対称経路が生じることがあります。PCからの通信はバイパスルーターを経由し、直接接続する通信はメインルーターから外へ出る一方、応答はメインルーターからPCへ直接戻る場合があります。すぐに通信が途切れるとは限りませんが、ステート追跡、統計、特定のファイアウォールポリシーに影響することがあります。送信元アドレス変換、独立したサブネット、追加ルートが必要かどうかは、実際のネットワーク構成に応じて判断してください。ネットワーク全体に適用するNATルールを安易にコピーしないでください。

想定するDHCPサーバーは1つだけにし、端末ごとに異なるゲートウェイが割り当てられないようにします。
バイパスルーターでIPv4転送、ファイアウォールの転送許可、戻り経路を確認します。ポリシールーティングを使う場合は、逆方向パスフィルタリングによってパケットが誤って破棄されないかも確認してください。
バイパスルーターのデフォルトルートを自身に向けたり、メインルーターとバイパスルーターが互いをデフォルトの出口に設定したりしないでください。

順番に導入する：まず明示的プロキシ、次に転送を取り込む

まず「コアが接続できる」ことを確認し、その後で「ゲートウェイが通信を取り込める」ことを確認します。問題を分けて検証すれば、ノード設定、ファイアウォール、DNSに同時に問題が起きても原因を絞り込みやすくなります。以下の手順ではメインルーターの設定を維持するため、失敗してもテスト用PCのネットワーク設定を戻すだけで済みます。

現在の設定を記録する

Windowsの「設定」→「ネットワークとインターネット」→現在接続中のネットワークの「プロパティ」で、IPアドレス、ゲートウェイ、DNSを記録します。編集画面の場所はWindowsのバージョンによって異なる場合があります。まず画面を保存してから、テスト用PCの設定を変更してください。
動作環境を確認する

ルーターのOS上でuname -mを実行してCPUアーキテクチャを確認し、ファームウェアのパッケージソース、ランタイムライブラリ、カーネルバージョンも調べます。そのOSがサポートする方法で導入し、管理画面に表示されたバージョンだけでなく、実際にインストールしたコアのバージョンも記録してください。
ノードを1つだけ検証する

まずテスト用のHTTP/SOCKS入口だけを起動します。例ではポート番号に10808を使用し、信頼できるLAN内からのみアクセスできるようにしたうえで、PCから明示的なプロキシリクエストを送ります。ログに認証エラー、ハンドシェイク失敗、ポートの競合がないことを確認してください。
PCを1台だけ接続する

使用するコアとファイアウォールの方式に合わせて透過プロキシの入口と転送ルールを設定し、テスト用PCのゲートウェイを192.168.10.2に変更します。端末のクライアント経由で通信して成功したように見えるのを防ぐため、テスト前にPCのシステムプロキシとTUNを無効にしてください。
最後にDHCPを変更する

1台で安定動作を確認してから、一括配布を検討します。標準的なOpenWrt LuCIでは「ネットワーク」→「インターフェース」→「LAN」→「編集」→「DHCPサーバー」→「高度な設定」の「DHCPオプション」で、IPv4ゲートウェイとDNSを設定できます。ファームウェアによって項目名が異なる場合があるため、実際の設定項目を確認してください。

メインルーターから上記の設定を一括配布する場合、DHCPオプションの3,192.168.10.2はIPv4のデフォルトゲートウェイ、6,192.168.10.2はDNSを指定します。変更後、テスト端末でリースを更新し、実際に割り当てられた値を確認してください。バイパスルーターのDNSが動作する前にネットワーク全体へ配布しないでください。また、IPv4のDHCPオプションだけでIPv6も設定できるわけではありません。

# 例：バイパスルーターでHTTP/SOCKS混合入口 10808を設定済み
# Windowsではcurl.exeを使用し、その他のシステムではcurlを使用
curl.exe --proxy socks5h://192.168.10.2:10808 --connect-timeout 10 -I https://example.com/

# バイパスルーターのDNSサービスが応答するか確認
nslookup example.com 192.168.10.2

socks5hは、接続先ドメインの名前解決をプロキシ側に任せる指定です。これは明示的なプロキシ経路の確認にしか使えず、PCの通常のDNSリクエストや透過プロキシが正しく設定されている証明にはなりません。続けて、端末のプロキシを無効にした状態で、通常のブラウザーと実際に使うアプリをそれぞれテストしてください。

DNS・IPv6・UDPの経路を分けて確認する

「一部のWebサイトは開くのに、ほかは読み込み中のまま」という場合は、まずDNSクエリの行き先を確認します。アプリによってはシステムDNSを使う一方、安全なDNSを有効にしてHTTPS経由で独自に名前解決することもあります。バイパスルーターのドメイン振り分けルールから、同じクエリが見えるとは限りません。DNSサーバーのアドレスを1つ確認しただけで、すべてのアプリが同じ経路で名前解決していると判断しないでください。

通常のDNSが使うUDP/TCPポート

10808

この記事で手動設定した混合入口

1台

ゲートウェイを初めて切り替える際のテスト対象

DNSのループを防ぐ：システムのリゾルバーがクエリをコアへ送り、コアの上流DNSが同じリゾルバーを指していると、クエリが転送され続けるおそれがあります。「端末→ローカルリゾルバー→上流」の実際の経路を図にし、ノードサーバーのドメインを起動時に名前解決できる経路も確保してください。
AとAAAAを個別に検証する：AレコードとAAAAレコードを問い合わせ、IPv4とIPv6の実際の出口を確認します。端末がメインルーターからIPv6のデフォルトルートを受け取ったままの場合があるため、IPv4のゲートウェイを変更しても、すべての通信がバイパスルーター経由になるとは限りません。
UDPへの対応を確認する：音声通話、ゲーム、QUICを使うアプリはUDPに依存する場合があります。ノード、コアの入口、透過転送方式が対象の通信に対応していることをそれぞれ確認してください。TCPのWebページを1回開けただけでは、検証として不十分です。
ルールの適用範囲を明確にする：ゲートウェイ自身の管理用アドレス、LANのサブネット、マルチキャストやブロードキャスト、プロキシサーバーへの接続をどう扱うか、明確に決めてください。コア自身の送信通信が再び入口へ戻らないようにします。

性能を比較する：CPUのシングルコア性能、メモリ、障害の影響範囲を確認

ギガビット対応のLANポートがあっても、暗号化プロキシでギガビットの速度が出るとは限りません。CPUのシングルコア性能、プロトコルやトランスポートの負荷、同時接続数、ログの書き込み、放熱がスループットに影響します。メインルーターは接続、ファイアウォール、Wi-Fi管理なども担うため、プロキシの負荷が高まると、ほかの端末の遅延も増えることがあります。バイパスルーターなら計算負荷を別の機器に移せますが、メインルーターの転送性能がボトルネックになる可能性は残ります。

確認項目	確認方法	判断の目安
CPUと温度	10分間連続で通信し、各コアの使用率と機器の温度を確認します。	特定のコアが高負荷のままなら、CPU全体の使用率だけで判断しないでください。
メモリの空き容量	`free`、プロセスごとのメモリ使用量、システムログを確認します。	キャッシュと利用可能なメモリを区別し、メモリ不足によるプロセス終了がないか確認します。
遅延と安定性	アイドル時とダウンロード中にそれぞれ測定し、最低30分間は状態を観察します。	これらは推奨するテスト時間であり、この記事で測定した結果ではありません。
再起動後の復旧	現地で復旧操作ができる人がいる状態で、コアとゲートウェイをそれぞれ再起動します。	サービスの自動起動、ルールの復元、DNSの起動順序を確認します。

メインルーターにコアを直接導入する場合は、ハードウェアオフロードと透過プロキシのルールが共存できるかを重点的に確認してください。一部のオフロード経路では、必要な処理チェーンを通らない場合があります。速度測定の数値を追って、オフロードをすべて有効にしないでください。バイパスルーターでは、電源が切れたときの動作も確認が必要です。DHCPでネットワーク全体にバイパスルーターをデフォルトゲートウェイとして配布している場合、故障してもメインルーターへ自動的には切り替わりません。

メンテナンスに備えて、コアの設定、サービスの起動項目、ファイアウォールルール、DHCP設定を保存してください。アップデート前に切り戻し可能なバージョンを記録し、テスト端末でサブスクリプション変換、ドメインポリシー、UDPを確認してから適用範囲を広げます。サブスクリプションの更新に成功しても、設定データを取得できたというだけで、すべてのノードが現在のコアで動作するとは限りません。

症状ごとに原因を調べ、デスクトップクライアントとの役割分担を保つ

バイパスルーターにゲートウェイを変更したら、PCがまったく通信できない

まずゲートウェイを192.168.10.1に戻し、元のネットワークが使えることを確認します。次に192.168.10.2へアクセスできるか、バイパスルーター自体がインターネットに接続できるか、転送が許可されているかを調べます。DNS変更後にドメイン名で接続できなくてもゲートウェイへ到達できるなら、DNSを個別にテストしてください。すぐにコアを再インストールする必要はありません。

明示的なプロキシなら使えるのに、無効にすると接続できない

ノードと明示的な入口はおおむね動作しているため、次は透過プロキシの入口、ファイアウォールのルール適用数、ポリシールーティングを確認します。まずPCが実際に使っているデフォルトゲートウェイを調べ、リクエストが対象のルールに一致しているか確認してください。すでに動作確認済みのノード認証設定を何度も変更する必要はありません。

PCは正常なのに、同じWi-Fiにつないだスマートフォンはバイパスルーターを通らない

スマートフォンに割り当てられたゲートウェイとDNSを確認し、Wi-Fiに再接続してリースを更新します。IPv6ルートと、アプリ独自の名前解決設定も調べてください。v2rayNGまたはv2flyNGが起動中なら、いったん接続を停止してからゲートウェイ経由の通信を試し、2つのルールが干渉しないようにします。

家庭内にバイパスルーターがあっても、v2rayNを使える？

使えますが、役割分担を明確にしてください。普段はPCからゲートウェイを利用し、ノードを個別にテストするときにv2rayNの「システムプロキシ」で「システムプロキシを自動設定する」を選択できます。ノードへの接続がゲートウェイ側でもう一度プロキシされないか確認し、必要に応じて明示的な直接接続ルールを設定して、意図しない二重プロキシを防いでください。

最終確認では、Webページが開くかどうかだけでなく、LAN内のファイル共有、プリンター、音声通話、普段使うアプリが正常に動くことも確認してください。DNSとIPv6の経路をテストし、ネットワーク設定を自動取得に戻せば元の接続方法へ復帰できることも確かめます。システムの転送ルールに慣れていない場合は、端末のクライアントを使い続け、ゲートウェイの導入範囲を管理できるテスト環境に限定するほうが、家庭全体の出口をすぐ置き換えるより運用しやすいでしょう。