ルーターへの導入で重要なのは、デスクトップクライアントをそのまま移すことではありません。カーネル、システムルーティング、ファイアウォール、DNSを連携させることがポイントです。利用可能な接続設定があり、LAN内の端末をまとめて振り分けたい方に向けて、まずメインルーターとバイパスルーターの違いを整理し、CPUアーキテクチャとリソースの余裕を確認します。最後にテスト用端末で通信経路を検証し、ネットワーク全体のゲートウェイを一度に変更してトラブル時の確認手段を失う事態を防ぎます。
ルーターで動かすのはカーネルであり、デスクトップクライアントではない
v2rayNはデスクトップ向けの設定・接続管理クライアント、v2rayNGはXrayカーネルを使うAndroidクライアント、v2flyNGはV2Flyカーネルを使うクライアントです。サブスクリプション管理や設定生成、操作画面を備えています。一方、ルーターでは通常、XrayまたはV2Flyのコマンドラインプログラムを直接実行し、ファームウェアのサービス管理機能で起動します。クライアント画面の「システムプロキシ」設定を、ルーター全体のプロキシ機能としてそのまま使うことはできません。
カーネルは受信接続を処理し、ルーティングルールを適用して送信接続を確立します。どの端末の通信をカーネルに通すかは、システムの転送設定、ファイアウォール、ポリシールーティングによって決まります。プロセスを起動し、ログに待ち受け成功と表示されても、同じネットワーク上のテレビやパソコンなどがプロキシ経由になったとは限りません。
- アプリごとのプロキシ設定：プロキシ対応アプリにルーターのアドレスとSOCKSまたはHTTPポートを入力します。まずは単一のアプリで試せるため、変更の影響を抑えられます。
- 透過プロキシ：リダイレクトやTPROXYなどで指定した通信をカーネルに渡します。システムモジュール、ファイアウォールルール、インバウンド設定の連携が必要です。
- 端末ごとの振り分け：端末のIPアドレスやネットワーク範囲でプロキシ対象を決め、カーネル側のドメイン・IPルールなどで送信先を振り分けます。
メインルーターとバイパスルーター：障害時の影響範囲を先に確認
メインルーターは通常、PPPoE接続、アドレス配布、デフォルトゲートウェイ、ファイアウォールを担います。構成を集約でき、通信経路も比較的シンプルです。一方、カーネルの更新や転送ルールの変更、メモリ不足がLAN全体に影響する可能性があります。バイパスルーターならプロキシ機能を別の機器に分け、メインルーターの基本的なインターネット接続を維持しやすくなります。その分、戻りの通信経路、アドレス配布、DNSを明確に設計する必要があります。
バイパスルーター：まずテスト端末1台で接続
おすすめメインルーターのPPPoE接続とDHCPはそのままにし、テスト端末だけゲートウェイまたはアプリのプロキシ設定を変更します。問題が起きたら、その端末をメインルーターに戻して段階的に検証できます。他の端末への影響も避けられます。
おすすめのケース：安定稼働中のメインルーターがある、ゲートウェイでの振り分けを初めて試す、明確な切り戻し手順が必要
メインルーターでカーネルを直接実行
通信の取り込みと外部への接続を1台に集約でき、転送を一元管理しやすくなります。ただし、管理用の接続手段を確保し、CPU、メモリ、ストレージ、ファームウェアのモジュールが追加の処理に足りるか確認してください。
おすすめのケース：ファームウェアのファイアウォールに詳しい、設定を復元できる、メンテナンス時間を確保できる
構成例：メインルーターは維持し、バイパスルーターで個別に検証
メインルーター：192.168.10.1
- インターネット接続とDHCPを引き続き担当します。
- アドレスの競合を避けるため、バイパスルーター用に192.168.10.2を確保します。
- 他の端末のデフォルトゲートウェイは変更しません。
バイパスルーター：192.168.10.2
- デフォルトルートは192.168.10.1に設定します。
- 転送が必要な場合は、IPフォワーディングを有効にしてファイアウォールを設定します。
- テスト端末では、構成に応じてゲートウェイとDNSサーバーを設定します。
これらのアドレスは同一サブネットでの例です。適用前に、現在のネットワーク範囲、DHCPアドレスプール、既存の固定IPアドレスを確認してください。
LANポートが1つのバイパスルーターでも動作しますが、戻りの通信経路には注意が必要です。直接接続の通信がメインルーターから端末へ戻り、バイパスルーターを経由しない場合があります。送信元アドレス変換が必要かどうかは、コネクショントラッキング、ファイアウォール、戻り経路を踏まえて判断してください。汎用的なルールをそのまま流用するのは避けましょう。複数のLANポートがあっても、設定上の問題が自動的に解決するわけではありません。各区間の入口・出口と戻り経路を説明できる構成にすることが重要です。
ハードウェア選び：アーキテクチャ、メモリの余裕、ストレージ書き込みを確認
実行ファイルを選ぶ前に、まず機器の情報を確認しましょう。CPUの製品名だけでは互換性を判断できません。ARMのビット数と命令セット、MIPSのエンディアンやビルド要件を確認する必要があります。ハードウェアが64ビット対応でも、ファームウェアのユーザーランドが64ビットとは限りません。動的リンクされたプログラムは、ランタイムライブラリやローダーの影響も受けます。「実行できません」と表示されても、まず接続先やサブスクリプションを疑う必要はありません。
# デバイスの端末でシステム情報とリソースを確認。コマンドのオプションはファームウェアによって異なる場合があります
uname -m
uname -a
free -m
df -h
ip route show
ip -6 route show| 確認項目 | 確認する内容 | 選定への影響 |
|---|---|---|
| CPUとシステム | aarch64、armv7l、x86_64など。ファームウェアパッケージのアーキテクチャも確認 | 実行できるカーネルビルドが決まるため、機器の型番だけで判断できません |
| メモリの余裕 | 起動前、ルール読み込み後、接続増加時にavailableなどの指標を確認 | ルールセット、接続数、DNSキャッシュ、その他のサービスがメモリを共有します |
| 書き込み可能な空き容量 | カーネル、ルールファイル、一時更新ファイル、ログを保存するパーティション | 新しいファイルのダウンロードと古いファイルの置き換えには、追加の空き容量が必要です |
| システム機能 | ファイアウォールのバックエンド、ポリシールーティング、透過プロキシに必要なモジュール | 通信を取り込む方法が決まります。プログラムが起動するかどうかだけでは不十分です |
| ネットワークと冷却 | LANポートの速度、ドライバーの安定性、継続負荷時の温度とCPU使用率 | 長期的な安定性に影響します。コア数だけからスループットを推定することはできません |
機器を新たに購入する場合、軽量なゲートウェイならメモリ512 MB以上を初期選定の目安にし、複数のサービスを同時に動かすなら1 GB以上を検討できます。これはリソース計画の目安であり、カーネルの最低要件や性能を保証するものではありません。メモリの少ない既存機器でも、設定を絞れば動作する場合があります。不要なルールやバックグラウンドサービスを減らし、メモリ不足でプロセスが終了しないか確認してください。スワップ領域の有効化を、継続的なメモリ不足の代わりにしないでください。
選定の判断：使う予定のルールセットで試し、ハードウェアの交換を検討
同じ機器で、アイドル時、ルール読み込み後、複数端末を日常利用しているときのリソース変化を記録します。カーネルにエラーがないのにCPU使用率が高い状態が続く場合は、暗号化や転送の負荷を確認してください。プロセスがシステムによって終了された場合は、まずメモリ関連のログを確認します。「接続先への接続が遅い」という症状だけでは、ルーターの性能不足とは判断できません。
ポート、DNS、透過プロキシ：通信経路を分けて検証
明示的なプロキシ設定で通信できることは、重要な出発点です。ただし、それだけで透過プロキシが正しく動いているとは証明できません。まずテスト専用のSOCKSインバウンドを用意し、単一のアプリで外部接続を確認してから、ゲートウェイ転送を追加しましょう。以下の3つのポート番号は役割を示す例であり、クライアントやファームウェア共通の初期値ではありません。実際の待ち受けポートは設定とシステムの出力を確認してください。
- 待ち受けアドレスを確認：
127.0.0.1のみで待ち受ける場合、他のLAN端末から直接接続できません。LAN内にプロキシを提供する必要がある場合は、適切なアドレスにバインドし、ファイアウォールで接続元を制限してください。プロキシポートをインターネットに公開してはいけません。 - プロキシ自身の通信を除外：カーネルが確立する外向き接続を、通信取り込みルールで再度捕捉しないようにします。構成に応じてプロセス、ユーザー、通信マーク、宛先アドレスなどで除外し、サーバーのアドレスへ正常に接続できることを確認してください。
- TCPとUDPを個別に処理：あるリダイレクト方式がTCPに対応していても、UDPまで処理されるとは限りません。TPROXYにはポリシールーティングと対応モジュールも必要です。ポート転送ルールを1つ追加するだけでは動作しません。
- DNSの名前解決経路を設計：まずサーバーのドメイン名を誰が名前解決するかを決め、それから各ドメインの問い合わせ経路を設定します。プロキシの確立に名前解決が必要なのに、名前解決には未確立のプロキシが必要という構成では、起動時に依存関係がループします。
- IPv6を個別に検証：IPv4のルールしか設定していない場合、IPv6通信は別の経路を通る可能性があります。IPv6の通信振り分けを行うか明確にし、端末が受信したルーター広告とDNS情報も確認してください。
設定移行：接続情報を引き継ぎ、ルーター固有の設定を再構築
デスクトップで使えているノード設定は移行の参考になりますが、ルーターの設定を丸ごと上書きしないでください。v2rayNが生成した実行設定には、ローカルのポートやファイルパス、クライアント管理用の項目が含まれる場合があります。サブスクリプションの内容も、そのまま実行できるカーネル用JSONとは限りません。サーバーへの接続情報とローカルの実行設定を分け、移行先カーネルの仕様に沿って再構築してください。
- 接続情報を控える：アドレス、ポート、プロトコル、認証情報、トランスポート方式、セキュリティ層を記録します。TLSのserverName、WebSocketのpathとHost、REALITYのサーバー公開鍵とshortIdなどは、実際の構成に合わせて確認してください。これらの項目を相互に置き換えることはできません。
- 移行先カーネルの対応状況を確認：プロトコル、トランスポート、セキュリティ層の組み合わせがサポートされているか確認します。あるクライアントにサブスクリプションをインポートできても、そのクライアントが処理できるというだけで、別のカーネルが同じ設定を受け付けるとは限りません。
- ローカル設定を再構築：待ち受けアドレス、インバウンドポート、ルーティングルール、DNSを設定し、ルールファイルのパスを機器上で有効なものに変更します。実行ユーザーにファイルの読み取り権限と必要な操作を行う権限があることも確認してください。
- 有効化する前に検証：カーネルの設定チェックコマンドで項目と参照ファイルを確認してから、フォアグラウンドで起動してログを確認します。テストに通っても、設定を読み込めることが確認できただけです。実際の通信も検証してください。
- 最後にサービス管理へ登録：ファームウェア標準のサービス管理機能で起動と再起動を行い、起動経路を複数設定しないようにします。バックアップファイルの場所、復元手順、サービスの停止方法も記録してください。
# 実行ファイル名をxray、設定ファイルの保存先を次のパスと仮定
# まずヘルプで、現在のビルドが対応するコマンドオプションを確認
xray help run
xray run -test -config /etc/xray/config.json
# 設定チェックに通ったら、フォアグラウンドで起動してログを確認
xray run -config /etc/xray/config.jsonV2Flyを使う場合は、該当ビルドのヘルプを確認してください。Xrayのコマンドや設定項目が共通とは限りません。また、サブスクリプションの自動更新は、カーネルの起動だけで使える機能ではありません。取得、変換、設定チェック、ファイル置き換えを適切に管理する必要があります。更新に失敗した場合は、動作中の設定を空の結果で上書きせず、直前の正常な設定を保持してください。
よくあるトラブル：設定を変える前に、通信が途切れている箇所を特定
変更する項目は毎回1つに絞りましょう。まず機器自体で名前解決と外部接続ができるか確認し、次にカーネルの接続、最後に端末からゲートウェイまでの転送経路を検証します。DNS、ルーティングルール、プロトコルを一度に変更すると、接続が復旧しても原因を特定しにくくなり、再起動後も動作するか確認できません。
「実行できません」と表示される。ダウンロードしたファイルが違う？
まずuname -mを実行して、ファームウェアパッケージのアーキテクチャと照合します。次にファイルの実行権限、動的ローダー、ランタイムライブラリの要件を確認してください。「Exec format error」は通常、アーキテクチャまたはファイル形式の問題を示します。接続処理に進む前の段階なので、まずサーバー側の設定を変更する必要はありません。
バイパスルーター自身は接続できるのに、パソコンのゲートウェイに設定するとWebページが開かない？
IPフォワーディング、ファイアウォールの転送ポリシー、デフォルトルート、戻り経路を確認してください。続いて、パソコンから例としてSOCKSポート1080に明示的に接続します。接続できる場合は、ノードを再インポートするより、透過プロキシの通信経路を優先して調べましょう。その後、DNS、TCP、UDPを個別にテストしてください。
一部のWebサイトだけで問題が起きる。プロトコルを変えるべき？
まずルールの適用状況、DNSの応答、IPv6の経路を確認します。意図せず直接接続されている宛先、取り込まれていないUDP、経路MTUの問題がないか調べてください。同じ端末で明示的なプロキシ設定と透過プロキシを比較する方が、いきなりプロトコルを切り替えるより原因特定に役立ちます。
再起動すると動かなくなる。起動スクリプトを追加すべき？
まずサービスの状態、起動ログ、設定ファイルの権限を確認し、起動時にネットワーク、時刻同期、ルールファイルの準備が整っているか調べます。多重起動によるポート競合を避けてください。起動スクリプトを重ねて追加するのではなく、既存サービスの依存関係と設定ファイルのパスを修正しましょう。
運用開始の前に：接続だけでなく、復旧できることも確認
接続対象を増やす前に、機器の再起動、カーネルの停止、設定の復元をそれぞれ一度テストしてください。テスト端末を元のメインルーターに戻せること、管理画面に常時アクセスできることを確認してから、DHCPの配布設定を段階的に変更します。ネットワーク全体で初めて通信を取り込む作業と、初めてのアップデートを同時に行わないでください。