この記事は、プロキシ機能を1台の端末から家庭用ゲートウェイへ移行したい方を対象としています。特定の管理画面でのインストール手順ではなく、通信がどの機器を通るのか、TCPとUDPがどのようにコアへ入るのか、DNSクエリを誰が処理するのか、障害時に直接接続へ戻す経路をどう残すのかを整理します。
まずゲートウェイの役割を決め、配置場所を選ぶ
ルーターでV2Rayコアを直接動かすとは、通常、Linuxゲートウェイ上でXrayまたはV2Flyを実行し、ルーティングルールで指定端末の通信をコアへ送る構成を指します。XrayとV2Flyは接続、プロトコル、ルーティングを実際に処理するコアプログラムです。一方、v2rayN、v2rayNG、v2flyNGは端末向けクライアントであり、ルーターのゲートウェイ構成と同一視できません。
メインルーター構成では、コアを動かす機器が、接続認証、DHCP、NAT、ファイアウォール、デフォルトゲートウェイを同時に担います。すべての端末が自然にこの機器を通るためポリシーを完全に適用できますが、設定ミスがLAN全体に影響する可能性もあります。ファイアウォール、DNS、コアサービスを変更する前に設定をエクスポートし、有線経由で管理アドレスへログインできる端末を用意してください。
バイパスルーター構成では、既存のメインルーターを残し、別の機器を同じLAN内に設置します。端末は、ゲートウェイの手動設定、DHCPによる配布、またはメインルーターのポリシールーティングによってバイパスルーターへ接続できます。移行範囲を制御しやすく、テレビ、仕事用PC、テスト端末を段階的に切り替えられる点が利点です。一方、経路が長くなるため、ゲートウェイや戻り経路の設定ミスでループが発生しやすくなります。
メインルーターに直接構築
デフォルトゲートウェイ、DHCP、DNS、透過プロキシを1台に集約でき、ポリシーの入口が統一されます。LAN内の端末を1台ずつ変更する必要もありません。
適している環境：ネットワーク構成がシンプルで、ファイアウォールと起動サービスを管理できる場合
バイパスルーターへ段階的に接続
おすすめ元のメインルーターを残し、テスト端末や指定した機器だけをバイパスルーターへ向けます。障害発生時も元のゲートウェイへすぐ戻せます。
適している環境：初回構築、低リスクでの移行、端末単位の制御が必要な場合
端末クライアントを併用
ルーターは通常のネットワークとして運用し、PCではv2rayN、Android端末ではv2rayNGまたはv2flyNGを使って、それぞれでプロキシ状態を管理します。
適している環境：端末数が少なく、端末ごとにノードを切り替えたい場合
結論：初回はバイパスルーターで経路を検証する
まずはテスト端末1台のデフォルトゲートウェイとDNSだけを変更し、TCP、UDP、名前解決、戻り経路が正常であることを確認してから接続範囲を広げます。ネットワーク全体のデフォルトゲートウェイをいきなり変更するより、問題を特定しやすくなります。
構築前にアーキテクチャ、メモリ、システム機能を確認する
インストールパッケージはプロセッサのアーキテクチャに合わせる必要があります。ソフトルーターではx86_64が一般的ですが、小型のARM機器ではaarch64の場合があります。名称が似ていてもバイナリを共用できるとは限りません。uname -mを実行してアーキテクチャを確認し、nftables、ポリシールーティング、TPROXYに対応しているかも調べてください。SOCKSの受け入れポートを1つ設定するだけでは、LAN内の通信を自動的に取り込めません。
リソース要件を把握するための基準例として、OpenWrt 23.05.5、Linux 5.15.167、4コアのx86_64プロセッサ、空きメモリ512 MBを想定します。一般的な家庭内ネットワークでのルール照合と数百Mbpsの転送に対応できます。大容量のgeosite、geoipデータ、詳細なアクセスログはメモリ使用量とストレージへの書き込みを増やすため、容量の少ないフラッシュ機器ではログレベルを下げ、ローテーションで保持するファイル数も少なくしてください。
推奨構成：管理面と転送面を分けて検証する
ゲートウェイ側
- XrayまたはV2Flyをシステムサービスとして起動
- 透過プロキシの受け入れを12345番ポートで待ち受け
- ローカルDNSの受け入れを127.0.0.1:1053で待ち受け
- 管理アドレスとLANセグメントは直接接続として残す
端末側
- まず1台の端末でゲートウェイアドレスを固定
- DNSを振り分け処理を担うゲートウェイへ向ける
- Web、ダウンロード、UDPアプリを個別にテスト
- 切り替え前後の出口IPと遅延を記録
コアが起動できるのは設定構文が通ったことを示すだけです。端末の通信が実際に透過プロキシの受け入れへ入り、戻り経路まで正常に処理されて初めて、ゲートウェイ経路が利用可能になったと判断できます。
透過プロキシでは入口と戻り経路を同時に処理する
透過プロキシの役割は、プロキシの存在を認識していない端末の接続をXrayまたはV2Flyへ渡すことです。LinuxではTPROXYやリダイレクトが一般的な入口になります。リダイレクトはTCPを扱いやすく、TPROXYは元の宛先情報を保持しながらUDPにも対応できますが、追加のfwmark、ポリシールーティング、ローカルルーティングテーブルが必要です。利用できる機能は、コアモジュールとファイアウォールの構成に左右されます。
完全なルールセットでは、少なくともルーター自身の管理アドレス、LANセグメント、マルチキャストアドレス、ノードサーバーのアドレス、コアプロセスが生成する接続を先に除外し、その後でプロキシ対象のTCPとUDPを捕捉します。ノードサーバーを除外しないと、ノードへの接続が再び透過プロキシの入口へ入り、接続タイムアウト、CPU使用率の上昇、同じ宛先を繰り返すログとして現れることがあります。
- 透過プロキシの受け入れを作成し、
12345などの待ち受けポートを固定して、必要に応じてTCPとUDPを有効にします。 - ポリシールーティングテーブルを作成し、
0x1のマークが付いたパケットをローカルループバックインターフェースへ送ります。 - ファイアウォールチェーンでは、まず直接接続の除外ルールを記述し、その後で対象通信にTPROXYとマークを設定します。
- コアのルーティングルールを設定し、LAN、管理アドレス、ノードアドレスがdirectの送信経路を通るようにします。
- サービスを再起動したら、プロセスの状態だけでなく、待ち受けポート、ルールカウンター、コアのログも確認します。
ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
nft add rule inet proxy prerouting \
meta l4proto { tcp, udp } \
tproxy to :12345 meta mark set 0x1DNSの振り分けがドメインルールの安定性を左右する
通信の振り分けだけでDNS設計がない場合、ドメインルールが適用されない、名前解決結果と出口が一致しない、端末がゲートウェイを迂回して外部DNSへ直接問い合わせるといった問題が起こりがちです。管理対象の端末はDNSをゲートウェイの53番ポートへ統一し、ローカルDNSサービスがドメインの種類に応じて直接接続用の名前解決、またはコアのローカルDNS受け入れへ転送する構成を推奨します。
分かりやすい構成例は、LAN内の端末がゲートウェイの53番ポートへ問い合わせ、dnsmasqがローカルドメインとDHCPホスト名を処理し、コアで処理する問い合わせを127.0.0.1:1053へ転送する形です。その後、XrayまたはV2FlyがDNSルールに従って送信先を選択します。1053の上流を53へ戻すと再帰ループになるため、必ず避けてください。
| 確認項目 | 推奨設定 | 異常時の症状 |
|---|---|---|
| 端末のDNS | ゲートウェイLANアドレスの53番ポートを指定 | ドメインルールが断続的に適用されない、または出口が一致しない |
| コアDNSの受け入れ | 127.0.0.1:1053だけで待ち受け | ポートがLANに公開される、または他の機器から直接呼び出される |
| キャッシュの場所 | dnsmasqまたはコアのどちらが主なキャッシュを担うか明確にする | ルール変更後も古いアドレスが返される |
| IPv6クエリ | IPv6のルーティングとプロキシポリシーを同時に有効化・無効化 | 端末がポリシー対象外のIPv6出口を優先して使用する |
一般的なOpenWrtの管理画面では、「ネットワーク」→「インターフェース」→「LAN」→「DHCPサーバー」→「詳細設定」から、端末へ配布するDHCPとDNSのパラメーターを確認できます。システムのバージョンによって項目名は多少異なるため、変更後はテスト端末でリースを再取得し、システムの名前解決コマンドで実際のDNSサーバーを確認してください。画面上の設定だけで判断してはいけません。
結論：DNSと透過プロキシはセットで検証する
テストでは、ドメインの名前解決結果、適用されたルーティングルール、実際の出口を同時に記録します。Webページが開くかどうかだけでは、DNSの迂回、キャッシュ未更新、IPv6が取り込まれていない問題を発見できません。
性能テストではコアの負荷と回線品質を分けて考える
ゲートウェイの性能は、プロセッサのコア数だけでは判断できません。暗号化アルゴリズム、接続数、ルールセットの規模、ログレベル、NICドライバー、ハードウェア割り込みの分散がスループットに影響します。透過プロキシを有効にすると、一部のハードウェアアクセラレーションやフローオフロードがファイアウォールルールを迂回する場合があります。一部の接続だけポリシーどおりに制御されない場合は、関連するオフロード機能を無効にして再測定してください。
参考テストでは、4コアのN5105、メモリ8 GB、ギガビット有線LAN、下り500 Mbpsの回線を使用し、テスト端末とゲートウェイはともに有線接続としました。同じノード、同じ時間帯で、メインルーターの直接転送は438 Mbps、同一セグメントのバイパスルーター経由は421 Mbpsでした。継続転送時のコアプロセス使用率は単一コア換算で約118%、ゲートウェイ全体のCPU使用率は約34%でした。これらの数値は測定方法を示すためのもので、実際の回線環境での測定に代わるものではありません。
- まずプロキシを通さないLAN内のスループットを測定し、NICのネゴシエーションやケーブルの問題を切り分けます。
- 次に外部ネットワークへの直接接続速度を測り、遅延、パケットロス、ダウンロード、アップロードの基準値を記録します。
- 透過プロキシを有効にした後、同じ端末、同じノード、同じ測定先で再テストします。
- 少なくとも5分間継続して測定し、CPU、メモリ、温度、接続数も同時に確認します。
- TCPダウンロード、Webの短時間接続、UDPが必要なアプリを個別にテストし、1項目の結果だけで全体を判断しないようにします。
速度が低下してもCPU使用率が高くない場合は、まずノード品質、MTU、DNS、戻り経路を確認してください。1つのコアだけが継続的に高負荷で、他のコアに余裕がある場合は、単一接続の処理や割り込み分散がボトルネックの可能性があります。バイパスルーターで増える転送段数だけで大幅な速度低下が自動的に起こるわけではありません。二重NAT、100Mbpsポート、無線による戻り経路を先に疑うべきです。
よくある構築トラブルと復旧方法
ゲートウェイサービスには明確な起動順序を設定します。ネットワークインターフェースとシステム時刻が利用可能になってからコアを起動し、コアの待ち受けが成功してから透過プロキシのルールを有効にします。ノードにドメイン名を使う場合、時刻未同期やDNS未稼働が初回接続の失敗原因になることがあります。サービスマネージャーには失敗時の再起動間隔も設定し、誤設定による高頻度再起動を防いでください。
復旧手順は構築前に準備しておく必要があります。メインルーター構成では、少なくともLAN管理アドレス、有線でのログイン方法、透過プロキシを無効にしたファイアウォール設定を1つ残してください。バイパスルーター構成では、テスト端末のデフォルトゲートウェイとDNSをメインルーターへ戻せます。すでに停止している可能性のあるプロキシ経路に復旧操作を依存させないでください。
コアは動作しているのに、端末が直接接続のままなのはなぜ？
まずポートを確認し、12345が待ち受け中であることを確認します。次にnftablesのルールカウンターが増加しているかを確認してください。カウンターが常にゼロなら、端末のゲートウェイがこの機器を指していないか、パケットが想定したpreroutingチェーンを通っていない可能性があります。
バイパスルーターを有効にするとLAN内の機器へアクセスできなくなるのはなぜ？
LANセグメントが透過プロキシのルールから除外されているか確認し、バイパスルーターで同じセグメントを2つのインターフェースに同時設定していないかも確認してください。テスト中はLANアドレスを1つに保ち、DHCPサービスの重複と非対称な戻り経路を避けます。
Webは使えるのに、一部のUDPアプリがタイムアウトするのはなぜ？
透過プロキシの受け入れでUDPが有効になっているか、ポリシールーティングがUDPにも適用されているか、ファイアウォールがTCPだけに一致していないかを確認します。その後、MTUとノードプロトコルが現在の転送方式に対応しているかを調べ、コアのログで拒否された宛先ポートを特定してください。
ドメインルールを変更しても古い結果が適用されるのはなぜ？
端末、ローカルDNSサービス、コアDNSのキャッシュを順番に削除してから、再度問い合わせます。dnsmasqが53番ポート、コアが1053番ポートを使っている場合は、相互転送によるループが発生していないことも確認してください。
XrayとV2Flyはどのように選べばよい？
まず、実際に使用するノードのプロトコルに合わせてコアを選びます。VLESS、XTLS、REALITYの設定を使う場合は、通常Xrayを選択します。既存のVMessなどの設定をV2Flyで運用している場合は、V2Flyを継続して使用できます。移行前に、同じ設定で端末クライアントが正常に接続できることを確認してください。
構築後の受け入れ確認には、ゲートウェイ再起動後のサービス自動復旧、サブスクリプションや設定更新によるローカル除外ルールの上書き防止、DNSクエリのループがないこと、ノードサーバーのアドレスが常に直接接続であること、LAN管理アドレスがプロキシを通らないこと、コア停止後に所定の操作で通常のネットワークへ戻せることを含めます。これらを満たしてから、ゲートウェイのポリシー対象にする端末を増やしてください。