ルーターでV2Rayコアを直接動かせる？バイパスルーター構成と導入手順の概要

まず構成を選ぶ：主ルーターで動かすか、専用バイパスルーターにするか

「ルーターでコアを直接動かす」とは、V2RayまたはXrayのプロセスをゲートウェイ機器上で実行し、ファイアウォールでLANの通信をコアへ送る構成です。パソコンやAndroid端末ごとにv2rayNやv2rayNGを起動しなくても、ゲートウェイのルールで通信を振り分けられます。解決できるのは複数端末の一元管理であり、ノードの経路、帯域、遅延が自動的に改善するわけではありません。

主ルーターで動かす構成は経路が短くなります。PPPoE接続、DHCP、DNS、NAT、透過プロキシを1台に集約でき、転送回数が少なくネットワーク構成も把握しやすくなります。一方、設定ミスが家庭内全体の通信に直結します。コアの異常、DNSループ、ファイアウォールルールの誤りによって、通常の直通通信まで止まる可能性があります。

バイパスルーター構成では、プロキシの役割を2台目の機器に分けます。主ルーターは接続と基本ネットワークを引き続き担当し、バイパスルーターは指定した端末だけを処理します。検証中はテスト用パソコン1台のゲートウェイをバイパスルーターのアドレスに変更し、安定してからDHCPで対象端末を増やせます。バイパスルーターが停止しても、主ルーター側で通常のネットワークを復旧できます。

必要な性能：メモリ容量だけでは転送速度は決まらない

コアの実行に必要なストレージとメモリはそれほど大きくありません。実際の体感を左右するのは、シングルコア性能、暗号化処理、接続数、冷却性能です。ルーターにギガビット対応ポートがあっても、透過プロキシ経由でギガビット速度が出るとは限りません。VMess、VLESS、トランスポートの組み合わせによってCPU負荷は変わり、詳細ログや複雑なルールを有効にすると追加負荷も増えます。

OpenWrt 24.10.2とXray 25.6.8を使った導入記録の一例として、4コアARM機で1接続のダウンロードを測定しました。直通は約936 Mbps、VLESS over TCPは約612 Mbps、VMess over WebSocketは約438 Mbpsでした。低クロックの2コア機では、同じ経路で約917 Mbps、214 Mbps、156 Mbpsとなりました。これらはすべての機器に当てはまるベンチマークではありませんが、ポートの規格とプロキシの実効速度が単純に一致しないことは分かります。

• アーキテクチャがコアのファイルと一致するか確認します。一般的な種類はaarch64、armv7、x86_64で、ファイルを混用することはできません。
• フラッシュストレージに十分な空きがあるか確認します。コア本体だけでなく、Geoデータ、設定バックアップ、ログローテーションのための余裕も確保してください。
• 負荷試験は最低15分間続け、速度測定ページの瞬間的なピークだけを見ないでください。温度上昇後のクロック低下のほうが、家庭内での実負荷に近い結果になります。
• TCPとUDPをそれぞれ試験します。Webページが開いても、ビデオ通話、ゲーム、UDPベースのDNSが正常とは限りません。

設定配布：サブスクリプションURLをそのままコアに渡さない

v2rayN、v2rayNG、v2flyNGは、サブスクリプション、ノード、実行パラメータを管理できるGUIクライアントです。V2RayやXrayコアが読み込むのは構造化された設定ファイルであり、一般的なサブスクリプションURLを完全な透過プロキシ構成へ自動変換するわけではありません。サブスクリプションにノード情報しか含まれていない場合、インバウンドポート、DNS、ルーティングルール、ログレベル、ファイアウォール連携が不足します。

安全な手順は、まずクライアントでノードのパラメータを確認し、サーバーアドレス、ポート、ユーザー識別子、トランスポート、TLS関連の項目をルーターの設定に記述することです。デスクトップではv2rayNの「設定」→「パラメータ設定」→「Coreタイプ」で使用中のコア系列を確認し、同じノードで接続テストを行います。Androidではv2rayNGでXrayノードを、v2flyNGでV2Fly設定を検証できます。ただし、クライアントが出力した一部の情報を、そのままルーターの透過プロキシ設定として扱わないでください。

1. アーキテクチャを確認

   ルーターのシステム情報でaarch64、armv7、x86_64のいずれかを確認し、使用可能なフラッシュ容量とメモリも確認します。ディスクは少なくとも80 MB、空きメモリは256 MBを確保することをおすすめします。

2. ノードを検証

   まずv2rayN、v2rayNG、v2flyNGのいずれかで同じノードに接続し、アドレス、ポート、ユーザー識別子、トランスポート、TLS、サーバー名を記録して、ノード自体に問題がないことを確認します。

3. コアを決める

   デスクトップでの検証時はv2rayNの「設定」→「パラメータ設定」→「Coreタイプ」を開き、XrayとV2Flyのどちらで試験したかを確認します。ルーター側では対応する項目を使い、専用機能を混在させないでください。

4. 設定を作成

   インバウンドの待受をローカルアドレスと固定ポートに設定します。たとえば、透過インバウンドには12345、管理用のSOCKSインバウンドには10808を使い、直通、プロキシ、ブロック用のアウトバウンドも設定します。

5. 小規模で稼働させる

   まずテスト端末1台のゲートウェイをバイパスルーターに変更し、Web、DNS、動画、UDPアプリを順番に確認します。ログにループ接続がないことを確認してから、DHCPで配布するゲートウェイの範囲を変更します。

透過プロキシの核心：インバウンドポート、ポリシールーティング、DNS

透過プロキシは、SOCKSポートを1つ有効にするだけではありません。SOCKSポートはアプリ側から明示的に接続する必要がありますが、ルーターが扱うのは任意の宛先へ向かう元の通信です。ファイアウォールで接続をマークして転送し、ポリシールーティングでマーク済みのパケットをローカルの透過インバウンドへ戻し、コアが元の宛先に基づいてプロキシか直通かを判断します。

TCPにはリダイレクトまたはTPROXYを使えますが、UDPでは通常、宛先情報を保持できるTPROXYが必要です。TCPだけを処理すると、Webは正常でもゲーム、リアルタイム通話、一部のDNSリクエストが迂回したり失敗したりします。新しいOpenWrtでは通常、firewall4とnftablesが基盤となります。古い解説のiptablesコマンドはそのまま流用できません。考え方は同じでも、構文と組み込み場所が異なります。

{
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

上の設定はコア側の主要な構造だけを示したもので、ノードのアウトバウンドは含まず、ファイアウォールルールの代わりにもなりません。ポート12345はnftablesの転送先と一致させる必要があります。LANアドレス、マルチキャスト、ルーター管理アドレス、DHCP通信は先に除外してください。除外しないと、ゲートウェイの管理画面へのアクセスまで再びプロキシへ送られる可能性があります。

DNSの通信経路は別に整理する

• LAN端末は通常、ゲートウェイの53番ポートへ問い合わせを送り、ゲートウェイ上のローカルDNSサービスが使用する上流DNSを決定します。
• コアのDNSインバウンドが1053番ポートで待ち受ける場合、ローカルDNSサービスから指定ドメインを127.0.0.1:1053へ転送できます。1053番ポートを再び53番へ戻してループさせないでください。
• 中国本土のドメインとLAN内のドメインはローカルDNSで解決し、プロキシが必要なドメインはリモートDNSへ渡して、対応する接続をプロキシのアウトバウンドから送ります。
• 障害調査では、問い合わせたドメイン、返されたアドレス、実際のアウトバウンドを別々に記録します。「DNSの応答がある」だけでは、振り分けが正しいか判断できません。

ルーティングの振り分け：まずLANを除外し、プロキシ範囲を決める

ルーターの振り分けでは、コアのルールとファイアウォールルールを同時に考える必要があります。ファイアウォールはどの通信をコアへ入れるかを担当し、コアは入った後にどのアウトバウンドへ送るかを担当します。一方だけを変更すると、本来直通すべきLAN通信まで捕捉されるか、コアにプロキシルールがあっても通信が透過インバウンドへ入らない問題が起きます。

最小限のルールセットでは、まず基本ネットワークを使える状態にしてからドメイン分類を追加します。プライベートアドレス、ループバック、リンクローカル、マルチキャスト、ルーター自身が必要とする接続は透過入口を迂回させます。プロキシのアウトバウンド接続も除外が必要です。除外しないと、ノードサーバーへの接続をコア自身が再捕捉し、通信ループが発生してCPUを急速に消費します。

1. 192.168.1.0/24などのLANセグメント、主ルーター、バイパスルーター、ネットワークストレージの固定アドレスを先に除外します。
2. ノードサーバーのアドレスを除外し、プロキシのアウトバウンドがポート12345へ再び入らないようにします。ノードのアドレスが変わった場合はルールも更新します。
3. DHCPで使うUDPの67番と68番ポート、LAN内の検出や管理に必要な通信は許可します。
4. その後、プロキシが必要なドメインまたはアドレスのルールを追加します。未一致の通信はあらかじめ決めた方針で直通させ、デフォルトですべてブロックしないようにします。
5. 最後に、ルーター自身の更新、LAN端末間の通信、通常のWeb、動画、UDPアプリをテストします。

稼働前の確認：ログ、切り戻し、障害の切り分け

ネットワーク全体を正式に切り替える前に、プロキシに依存しない管理経路を用意します。最も簡単なのは、主ルーターの固定管理アドレスを残し、IPアドレス、ゲートウェイ、DNSを手動入力できるパソコンを1台用意する方法です。DHCPやバイパスルーターが停止しても、主ルーターへ直接アクセスして設定を復旧できます。

ログレベルは、デバッグ時はinfo、安定稼働後はwarningがおすすめです。debugを長期間有効にすると大量の書き込みが発生し、小容量のフラッシュストレージには不向きです。見るべきなのは全接続の記録ではなく、ポート使用状況、DNSタイムアウト、ルーティングループ、アウトバウンドのハンドシェイク失敗、プロセスの再起動を繰り返していないかです。

導入する価値は、端末数とメンテナンスにかけられる手間で決まります。パソコンやAndroid端末が1～2台だけなら、v2rayN、v2rayNG、v2flyNGを端末ごとに使うほうが分かりやすく、障害範囲も小さくなります。テレビ、ゲーム機、その他プロキシを個別設定できない端末をまとめて管理したい場合に、バイパスルーターの価値がはっきりします。

実際の導入では、切り戻せることを第一に考えます。まずノードを検証し、次にコアを動かす。まずローカルSOCKSで試し、その後に透過通信を接続する。まず端末1台を対象にし、その後DHCPを変更する。構成、DNS、ポリシールーティングを分けて検証すれば、ルーターでコアを直接動かすことは難しくありません。ただし、通常のクライアントよりネットワーク保守の層が一つ増えるのも事実です。