プラットフォーム 読了目安 12分

V2Rayコアをルーター・バイパスルーターで動かす：導入方法と必要なハードウェアの目安

メインルーターとバイパスルーターでV2Rayコアを直接動かす方法を整理し、ファームウェア要件、メモリと暗号化性能の目安、透過プロキシの基本経路、デスクトップクライアントへ戻すべきケースを解説します。

プロキシコアをルーターに置く場合、本質的な変化は「実行場所を変える」ことではなく、ゲートウェイがLAN内の機器の接続を一括処理する点にあります。各端末でシステムプロキシを個別設定せずに済む一方、ゲートウェイは転送、DNS、ルーティング判定、コネクション追跡、暗号化処理を同時に担います。設定ミスの影響も1台のPCからLAN全体へ広がります。

導入前に、メインルーターとバイパスルーターを区別して考えましょう。メインルーターは回線出口、DHCP、デフォルトゲートウェイを直接管理するため経路が短い反面、コアのメンテナンス時にネットワーク全体へ影響する可能性があります。バイパスルーターは既存のメインルーターの下流に置き、指定した端末だけデフォルトゲートウェイやポリシールーティングを向ける構成です。テストや切り戻しは容易ですが、戻り経路とDNSの向きを別途調整する必要があります。

この記事の要点

複数の端末でV2RayやXrayのプロキシ機能を共有したいユーザー向けに、メインルーターとバイパスルーターの違い、ファームウェアとハードウェアの条件、透過プロキシの経路、導入手順、切り戻しの判断基準を順に説明します。読み終えたら、機器を調整する価値があるかを見極め、ゲートウェイ運用とデスクトップクライアントのどちらを選ぶか判断できます。

メインルーターとバイパスルーター：まず障害範囲を決める

メインルーター構成の通信経路は通常、「端末 → メインルーターの透過プロキシ入口 → V2RayまたはXrayコア → リモートサーバー」です。コアのプロセスとNAT、ファイアウォール、DHCPが同じ機器上で動作します。構成が単純で、すべての端末が同じポリシーポイントを通るのが利点です。一方、コアの異常、ファイアウォールルールの誤り、DNS設定ミスが通常のインターネット接続に直結します。

バイパスルーター構成では、既存のメインルーターを安定した出口として残します。プロキシを使う端末のゲートウェイをバイパスルーターへ向けるか、メインルーターが送信元アドレスに基づいて特定の機器を転送します。バイパスルーターでルール判定を行った後、直接接続またはプロキシ通信をメインルーターへ戻します。端末を段階的に移行しやすく、障害時もゲートウェイを元のメインルーターへ戻せます。

メインルーターで直接運用

DHCP、NAT、DNS、透過プロキシを一元管理でき、経路も最短です。コアの更新やファイアウォール変更前には、復元可能な設定を必ず保存してください。

適しているケース：十分な性能、単純なネットワーク構成、メンテナンス時間を確保できる環境

バイパスルーターで引き受ける

おすすめ

既存のメインルーターを残し、指定した端末だけを移行します。プロキシ障害時はデフォルトゲートウェイを元のアドレスへすぐ戻せます。

適しているケース：初回導入、段階的な検証、家庭内ネットワークを長時間停止できない環境

デスクトップクライアント

PC上でv2rayNを動かし、システムプロキシ、TUN、サブスクリプション、コアのログをユーザーが明示的に管理します。

適しているケース：利用端末が1～2台、ノードの切り替えやルールのデバッグを頻繁に行う場合

バイパスルーターは、機器をスイッチへ接続するだけで自動的に通信を引き受けるわけではありません。端末の通信をバイパスルーターへ送るには、DHCP、手動設定したゲートウェイ、またはメインルーターのポリシーで明示的に指定する必要があります。端末のデフォルトゲートウェイがメインルーターのままなら、バイパスルーター上でコアが正常に動作していても該当する接続は見えません。

ファームウェア環境：コアが起動するだけでは最低条件

ルーターにはまず、対象アーキテクチャ向けのLinuxプログラムを実行できる環境が必要です。代表的なアーキテクチャはx86_64、aarch64、armv7、mipsleです。ダウンロード前にシステムが報告するアーキテクチャを確認し、プロセッサのブランドだけで判断しないでください。64ビットARMでも、システムの表示がaarch64になる場合があります。同じシリーズの旧機種では32ビットのユーザー空間が動作し、armv7ビルドしか使えないこともあります。

Linux 5.10以降のカーネルを推奨し、nftablesまたは完全なiptables拡張が利用できることを確認してください。透過プロキシにはポリシールーティング、接続マーク、TPROXY、REDIRECTなどの機能が必要です。軽量化されたファームウェアはコア本体を動かせても、透過転送モジュールが不足している場合があります。その場合は、端末側で手入力するSOCKSまたはHTTPの受信ポートを開く運用に限られます。

サブスクリプションも、ルーターのコアが標準で直接読み込める汎用形式ではありません。通常はクライアントや管理層がサブスクリプションURLを解析し、コアが読み込めるJSON設定を生成します。V2Rayの設定にサブスクリプションURLを1行追加するだけでは、コアがノード解析、グループ作成、ルーティングルール生成を自動で行うことはありません。ルーター運用では、別途設定管理層を用意するか、受信、送信、ルーティングの各オブジェクトを明示的に手動管理します。

ハードウェアの目安：CPUコア数だけでなく持続スループットを見る

プロキシ通信はユーザー空間のコアを経由するため、スループットは単一コア性能、暗号化アルゴリズム、TLS実装、メモリ帯域、冷却性能の影響を受けます。低クロックの4コアCPUが、高性能な2コアCPUより速いとは限りません。1本の接続におけるハンドシェイク、カプセル化、一部の暗号化処理は、すべてのコアへ均等に分散できないためです。複雑なドメインルールや多数の接続を有効にすると、メモリ負荷も大きくなります。

以下の数値は機器の保証値ではなく、実験室レベルの出発点として参考にしてください。条件は1 GbpsのLAN、リモート回線1本、同時ダウンロード8本、約4000件のドメインルールです。15分間安定稼働させた後のスループットとメモリを確認します。回線遅延、プロトコルの組み合わせ、ファームウェアのビルドオプションによって結果は変わります。

ハードウェア区分 推奨メモリ プロキシスループットの目安 適用範囲
デュアルコアARM、約1.0 GHz 256 MB以上 約45～90 Mbps 軽量なWeb閲覧、少数の端末。高速ダウンロードの全体接続には非推奨
クアッドコアARM、約1.5 GHz 512 MB以上 約160～320 Mbps 家庭での一般的な振り分け、アクティブ端末10～20台
新しいクアッドコアARM、2.0 GHz以上 1 GB以上 約350～650 Mbps 高速回線、多数の同時接続、複雑なルール
x86_64低消費電力プラットフォーム 2 GB以上 約700～940 Mbps ギガビット回線、継続的なダウンロード、DNS・監視サービスの同時稼働

結論：まず15分間の連続テストを行う

速度テストのピークが500 Mbpsに達しても、ルーターが長時間その速度を安定して維持できるとは限りません。15分間連続で動かした後にスループットが20%以上低下する、単一コアが長時間ほぼ100%になる、または本体が明らかにクロックダウンする場合は、目標帯域を下げ、冷却を改善するか、バイパスルーターやデスクトップクライアントへ切り替えてください。

メモリについては、コアがアイドル状態なら数十MBしか使わなくても、ルールファイルの解析、DNSキャッシュ、コネクション追跡、ログによって使用量が増えます。128 MBの機器は何とか起動できても、サブスクリプションで大量の送信先を生成した場合、同時接続が増えた場合、システム更新時にメモリ回収が発生しやすくなります。家庭での振り分け運用では512 MBが現実的な出発点です。フィルタリング、監視、ファイルサービスも動かすなら、1 GBから評価することをおすすめします。

プロトコルの選択もCPU負荷に影響します。VMess自体に暗号化と認証処理が含まれています。VLESSは設計が軽量ですが、TLSやREALITYなどのセキュリティ層と組み合わせると、ハンドシェイクと暗号化のコストが発生します。プロトコル名だけで速度を推測せず、同じノード、同じ時間帯でCPU使用率、持続スループット、初回パケットの遅延を比較してください。

透過プロキシの経路：入口、マーク、ルーティング、DNSをそろえる

透過プロキシの目的は、端末にSOCKSアドレスを入力させないことです。TCPとUDPをまとめて引き受ける場合、まずファイアウォールでプロキシ対象の接続を選別し、本体の透過受信ポート、たとえば12345へ流します。コアは元の宛先アドレスを読み取り、ドメイン、IP、ポート、プロトコルに基づいてルーティングルールを判定し、直接接続、遮断、リモートプロキシ送信のいずれかを選びます。

端末 192.168.1.20
  → デフォルトゲートウェイ 192.168.1.2
  → LANとリモートサーバーのアドレスを除外
  → TPROXY入口 0.0.0.0:12345
  → fwmark 0x1 / ポリシールーティングテーブル 100
  → V2RayまたはXrayのルーティング判定
  → directまたはproxyの送信

ポリシールーティングの要点は、マークを付けたパケットをデフォルトルートへそのまま転送せず、本体の透過受信へ戻すことです。一般的にはマーク0x1と独立したルーティングテーブル100を使います。具体的なコマンドはnftables、iptablesのバージョン、ファームウェアの実装方式によって異なります。2種類のルールを混在させ、一方だけを削除することは避けてください。

DNSはドメインルールが正しく適用されるかを左右します。端末が外部DNSへ直接問い合わせると、ゲートウェイには宛先IPしか見えず、ドメイン単位の分類が安定しません。DHCPでバイパスルーターのアドレスをDNSとして配布し、本体のキャッシュサービスに53番ポートを待ち受けさせ、処理対象の問い合わせを127.0.0.1:1053などのコアDNS受信へ渡す方法があります。同時に、コアがリモートドメインを問い合わせる通信が自身の透過ルールへ再び入らないようにします。

  1. ネットワーク設定を確認する

    メインルーターのアドレス、バイパスルーターのアドレス、DHCP範囲、リモートサーバーのIPを記録します。例ではメインルーターを192.168.1.1、バイパスルーターを192.168.1.2とし、同じアドレスを割り当てないでください。

  2. まず手動接続を開く

    まずコアで127.0.0.1:10808のSOCKS受信を待ち受け、1台のPCでプロキシを手動設定してノード、プロトコル、時刻同期を確認します。この段階ではネットワーク全体のファイアウォールを変更しません。

  3. 透過入口を追加する

    12345の透過受信を追加し、元の宛先アドレスを引き継ぐ機能を有効にします。その後、テスト端末専用のTPROXYまたはREDIRECTルールを設定します。

  4. DNS経路を固定する

    LANの53番ポートを使用するサービスが1つだけであることを確認します。コアDNSの待ち受けを127.0.0.1:1053に設定し、ドメイン振り分けと直接接続時の名前解決結果を検証します。

  5. 引き受ける範囲を広げる

    30分間、ログ、CPU、メモリ、接続数を観察します。ループや通信断がないことを確認してから、単一のテストアドレスから指定した端末グループへ広げ、最後にネットワーク全体への適用を検討します。

導入と受け入れ確認：1台ずつ段階的に拡大する

導入時に、いきなり全体の透過転送を有効にしないでください。まずコア設定を確認し、次に手動プロキシの入口を検証し、その後テスト端末1台だけを対象にします。各段階に独立した確認ポイントを設けることで、問題がノード、コア設定、ファイアウォール、DNS、バイパスルーターの戻り経路のどこにあるか判断できます。

  1. システムのアーキテクチャ、書き込み可能な容量、時刻を確認します。実行環境が現在時刻を正しく報告でき、少なくとも40 MBの空き容量を確保できることが必要です。
  2. コア起動後、最初の30行のログを確認し、設定ファイルが読み込まれ、受信ポートが待ち受け状態になり、送信先ドメインを解決できることを確認します。
  3. テストPCからバイパスルーターの10808 SOCKSポートへ接続し、直接接続の対象とプロキシ対象へそれぞれアクセスして、基本ノードが利用できることを確認します。
  4. テストPCのアドレスを192.168.1.20に固定し、透過ルールがこの送信元アドレスだけに一致するよう設定して、他の機器へ影響が出ないようにします。
  5. TCPによるWebアクセス、UDP DNS問い合わせ、継続ダウンロード、待機後の復帰という4種類のテストを行い、ログに接続ループ、ポート競合、名前解決タイムアウトが出ていないか確認します。
  6. プロキシを停止した直接接続時と、プロキシを有効にした場合のスループットを記録します。500 Mbpsの回線で安定して120 Mbpsしか出ず、同時に単一コアがフル稼働するなら、ルーティングルールを追加し続けるのではなく、ハードウェアのボトルネックと判断してください。

結論：切り戻し可能な設定を完成基準にする

導入完了とは、Webページが開くだけではありません。2分以内に透過ルールを停止し、元のDNSとデフォルトゲートウェイへ戻せることも必要です。ネットワークを復旧するためにファームウェアの再書き込みが必要なら、現在の変更には独立した切り替え手段がなく、対象範囲を広げるべきではありません。

受け入れ確認で記録する4種類のデータ

ログレベルを長期間デバッグのままにしないでください。検証中は一時的に詳細度を上げても構いませんが、原因特定後はwarningまたはerrorへ戻し、ログローテーションを設定します。ルーターのフラッシュメモリは書き込み寿命も容量も限られています。すべての接続を継続的に記録すると無駄な書き込みが増え、ルートファイルシステムがログで埋まる可能性もあります。

v2rayN、v2rayNG、v2flyNGへ戻すべきタイミング

ゲートウェイ運用がすべてのネットワークに適しているわけではありません。プロキシが必要なデスクトップPCが1台だけなら、v2rayNのほうが直接的な場合が多いでしょう。サブスクリプション更新、ノードテスト、システムプロキシ、TUN、ログを同じ画面で管理できます。v2rayN 7.xでは、「設定」→「パラメーター設定」→「Core タイプ」で現在のコア選択を確認し、ノードのプロトコルに応じて互換性のあるコアへ切り替えられます。

Android端末では、必要なコアに応じてv2rayNGまたはv2flyNGを使用できます。v2rayNGはXrayコアを使用するため、対応するプロトコル機能が必要な設定に適しています。v2flyNGはv2flyコアを使用し、V2Ray互換プロトコルをベースとした接続に向いています。端末クライアントならノードを個別に切り替えられ、ネットワーク全体のファイアウォールを再読み込みする必要もなく、問題を1台の端末に切り分けやすくなります。

バイパスルーターでコアが起動しているのに、端末の通信が通らないのはなぜ？

まず端末でデフォルトゲートウェイを確認します。192.168.1.1のままで、バイパスルーターが192.168.1.2なら、通信は自動的に迂回しません。テスト端末1台のゲートウェイとDNSを手動で192.168.1.2へ向け、透過入口のカウンターが増えるか確認してください。

Webは開けるのに、一部のアプリが常に直接接続する場合は？

そのアプリがUDP、独自DNS、システムプロキシに従わない接続を使っていないか確認します。ルーター側ではUDPの透過転送とDNS経路を同時に検証してください。ハードウェアやファームウェアがTPROXYに対応していない場合は、デスクトップ側でv2rayNのTUNモードを使う方法があります。

透過プロキシを有効にすると、リモートノードが再接続を繰り返す原因は？

まずリモートサーバーのIPが透過ルールの対象になっていないか確認します。そのIPを直接接続の除外リストへ追加し、ルーター本体からコアが開始する接続も除外します。その後、古いコネクション追跡情報を削除してコアを再起動してください。

メモリ256 MBのルーターはまだ使える？

ルールの規模と同時接続数を制限し、少数の端末だけを対象にして、空きメモリを30分間連続で観察する方法があります。空きメモリが長時間30 MB未満になる、プロセス終了が頻発する、サブスクリプション更新後に再読み込みできない場合は、512 MB以上のバイパスルーターまたはデスクトップクライアントへ移行してください。

ルーターの調整を続ける価値がないのはどんなとき？

透過転送モジュールがない、安定スループットが回線速度の3分の1未満、設定更新でネットワーク全体が頻繁に停止する、または利用端末が1～2台だけなら、v2rayN、v2rayNG、v2flyNGを直接使うほうが、通常は保守コストを抑えられます。

最終的な選択は、障害範囲とメンテナンス頻度を軸に決めます。テレビ、ゲーム機、ワークステーションなど複数の端末で統一ルールを共有し、十分な性能のゲートウェイがすでにあるなら、バイパスルーターが堅実な出発点です。サブスクリプションの切り替え、ノード比較、詳細ログの確認を頻繁に行う場合や、プロキシを使う端末が少ない場合は、デスクトップまたはAndroidクライアントのほうが管理しやすくなります。

メインルーターとバイパスルーターのどちらを選ぶ場合も、「直接接続へ戻せること」を導入計画に最初から含めてください。元のゲートウェイアドレス、DNS設定、ファイアウォールのバックアップ、サービス停止コマンドを残し、対象を1台ずつ広げます。ルーターでプロキシを使う価値は一元管理にあります。一元管理によって障害まで拡大するなら、ルールを複雑にするのではなく対象範囲を縮小すべきです。

V2Rayクライアントをダウンロード