2026年10月5日 · 環境別構築 · 約12分

OpenWrtのバイパスルーターでV2Rayコアを直接実行｜ソフトルーター構築と透過プロキシ設定

各端末にクライアントを入れず、OpenWrtのバイパスルーターでV2Rayコアを直接動かす方法を解説。ゲートウェイとDNSの設定、透過プロキシ、ルーティングルールの設計ポイントを紹介します。

この記事の概要

バイパスルーターを構築する際は、まず通常の転送を確認し、その後にコアと透過プロキシを組み込みます。OpenWrtの管理画面とSSHを利用できる方向けに、LAN内のアドレス例を使って、ゲートウェイ、DNS、ポリシールーティング、アウトバウンドルールの連携を解説します。読み終えると、1台から試す手順を立て、設定ミスとトラフィックの取り込みミスを切り分け、接続が切れた場合の復旧手段を確保できます。

バイパスルーターの構成：ゲートウェイとDNSを別々に確認

OpenWrtでV2Rayを起動しただけでは、LAN内の端末が自動的にプロキシを使うことはありません。コアはインバウンドに届いた接続を処理し、OSは端末の通信をコアへ転送します。透過プロキシには、ファイアウォールルール、ポリシールーティング、対応する待ち受けポートも必要です。どれか一つでも欠けると、プロセスが正常に動いていても通信を処理できない場合があります。

この記事では、単一LANインターフェースのバイパスルーターを例にします。メインルーターは 192.168.10.1、OpenWrtは 192.168.10.2、テスト用PCは 192.168.10.100、サブネットマスクはすべて 255.255.255.0 です。これらは説明用のアドレスです。構築前に実際のネットワークに合わせて変更し、バイパスルーターのアドレスがDHCPの自動割り当て範囲外であることを確認してください。

機器設定例役割
メインルーター192.168.10.1上位ネットワークに接続し、初期段階ではDHCPを引き続き提供します。
OpenWrt192.168.10.2、上位ゲートウェイは 192.168.10.1テスト端末の通信を転送し、コアとローカルDNSサービスを実行します。
テスト用PCゲートウェイとDNSをどちらも 192.168.10.2 に設定通信経路を確認し、ほかの端末の設定は変更しません。
その他の端末ゲートウェイとDNSは従来どおりメインルーターから取得通常のインターネット接続を維持し、テストの影響を抑えます。

ゲートウェイはパケットの次の転送先を決め、DNSはドメイン名の解決経路を決めます。両者は別の設定です。DNSだけを変更しても、通常のWeb通信がバイパスルーターを経由するとは限りません。ゲートウェイだけを変更しても、端末がバイパスルーターのDNS設定を使うとは限りません。ブラウザーのセキュアDNS、独自の名前解決機能を持つアプリ、IPv6のデフォルトルートが別経路になる場合もあります。

コアの選び方：ノード設定との互換性を確認

OpenWrtで直接実行するのはコアのプロセスであり、デスクトップクライアントの画面ではありません。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けの設定を管理します。これらのクライアントのメニューや設定を、そのままルーターに適用することはできません。サーバーアドレス、ポート、認証情報、トランスポート方式、TLS、サービス名などを、選んだコアが読み込める形式に変換する必要があります。

V2Flyコア

推奨

この記事では、V2FlyのV2Ray 5.xコマンドライン版を前提に説明します。VMessなどの互換性がある設定をすでに使っている場合は、対応するコアをそのまま使うと移行時の変数を減らせます。ただし、トランスポート関連の項目は実際のバージョンに合わせて確認してください。

向いているケース：互換性のある設定があり、まずはバイパスルーターの経路を検証したい場合

Xrayコア

ノードがREALITYまたはXTLS Visionを明示的に必要とする場合は、対応機能を備えたXrayのバージョンを使用してください。実行ファイルをv2rayにリネームしただけで、設定項目やコマンド引数がすべて共通だと考えてはいけません。

向いているケース：ノード設定でXray固有の機能が必要な場合

結論：ノードの設定項目をすべて確認する

プロトコル、トランスポート、セキュリティレイヤー、コアのバージョンを記録してから、導入するコアを決めてください。「VLESS」や「VMess」という名称だけでは、ノード設定全体に互換性があるか判断できません。

インストール前に、CPUアーキテクチャ、ストレージ容量、OpenWrtのパッケージフィードも確認してください。uname -m で実行環境のアーキテクチャを確認できますが、パッケージの利用可否はディストリビューションのABIや依存関係にも左右されます。別のOpenWrtブランチのパッケージフィードを混用しないでください。サブスクリプションURLは、ネイティブなコア設定ファイルと同じものではありません。形式に対応したツールで解析し、更新後は動作を確認してから実行中の設定を置き換えてください。

構築手順：まず転送を確認し、1台だけ通信を取り込む

DHCP、DNS、ファイアウォールを一度に変更しないでください。まず設定をバックアップし、テスト用PC 1台だけを変更する方法をおすすめします。以下では一般的なLuCI画面を例にします。翻訳やバージョンによって表示が異なる場合があるため、ボタンの位置だけに頼らず、画面上の項目を確認して操作してください。

  1. 設定をバックアップ

    「システム」→「バックアップ／アップグレード」→「バックアップの作成」を開き、現在の設定を保存します。PCの現在のゲートウェイとDNSを記録し、OpenWrtの管理画面へ直接アクセスする方法も確保してください。

  2. 固定アドレスを設定

    「ネットワーク」→「インターフェース」→「LAN」→「編集」を開き、静的アドレスが例の 192.168.10.2/24、上位IPv4ゲートウェイが 192.168.10.1 になっていることを確認します。DHCPサーバーがもう1台動作していないか確認し、アドレス割り当ての競合を防いでください。

  3. 転送を確認

    透過プロキシはまだ有効にせず、テスト用PCのゲートウェイだけをバイパスルーターに変更します。「ネットワーク」→「ファイアウォール」を開き、関連ゾーンの転送ポリシーと必要な送信元アドレス変換を確認して、通常の直接接続が動作することを確かめてください。

  4. コアをテスト

    必要な設定をすべて用意してから、v2ray test -c /etc/v2ray/config.json を実行します。テストに通ったら、まずフォアグラウンドで起動してログを確認し、その後、設定済みのprocdサービスで管理します。旧バージョンではコマンドが異なるため、先に v2ray help を確認してください。

  5. 対象を1台に限定

    テスト用PC 192.168.10.100 の通信だけを対象に、透過インバウンド、ポリシールーティング、ファイアウォールを設定します。直接接続、プロキシ、DNSが想定どおり動作することを確認してから、DHCPでバイパスルーターのゲートウェイを配布するか検討してください。

# 以下はV2Fly V2Ray 5.xの設定確認とフォアグラウンド実行の例
v2ray version
v2ray test -c /etc/v2ray/config.json
v2ray run -c /etc/v2ray/config.json

# 以下は別のSSHセッションでシステム状態を確認
ip -4 route show
ip -4 rule show
ss -lntup
logread -e v2ray

透過プロキシ：インバウンド、マーク、ポリシールーティング

透過プロキシは、システムプロキシのポートを外部に公開する機能ではありません。一般にREDIRECTは主にTCPのリダイレクトに使われます。TPROXYはTCPとUDPを処理できますが、カーネルモジュール、透過ソケットのサポート、パケットマーク、ポリシールーティングが連携している必要があります。インバウンド設定は、ファイアウォールで採用する方式に合わせてください。

OpenWrt 22.03以降、標準のファイアウォールはfirewall4とnftablesに移行しています。古い手順にあるiptablesコマンドを、現在の設定にそのまま使わないでください。まず実際に使われているファイアウォールを確認し、必要なTPROXY機能が利用できることを確かめます。コマンドが正常終了しても、ルールが対象の通信に適用されたとは限りません。

12345
透過インバウンドのポート例
0x1
ポリシールーティングのマーク例
100
専用ルーティングテーブル番号の例

以下は設計例であり、実測値でも、すべてのシステムに必要な固定値でもありません。TPROXYルールで対象の接続を 12345 のインバウンドに渡してマークを設定し、対応する ip rule でマーク付きパケットを専用ルーティングテーブルへ送ります。テーブルにはローカル配送ルートが必要です。マーク値、マスク、ルーティングテーブル番号を一組として確認し、既存のポリシーと競合しないようにしてください。

確認箇所確認内容未確認の場合に起こること
通信の入口送信元アドレス、LANインターフェース、TCP/UDPの対象範囲コアに接続記録が残らない、または別の端末の通信まで誤って取り込む。
除外ルールLAN、管理用アドレス、ブロードキャスト／マルチキャスト、ノードサーバーのアドレス管理画面にアクセスできない、LAN内サービスが不調になる、またはプロキシループが発生する。
透過インバウンド待ち受けアドレスとポート、元の宛先の取得、TPROXYソケットのオプション通信がローカルホストに届いても、受け取れるプロセスがない。
ポリシールーティングパケットマーク、ルールの優先度、ローカル配送ルートパケットが転送されるか破棄され、インバウンドにリクエストが届かない。
コアのアウトバウンドサーバー設定、DNS、直接接続／プロキシルールの順序インバウンドに記録はあるが、アウトバウンド接続に失敗する。

最初はLANから転送される通信だけを取り込み、ルーター自身のOUTPUT通信をすぐに対象にしないでください。コアがリモートサーバーへ接続すると、新たなローカル通信が発生します。その通信まで透過インバウンドに戻すと、ループが起きます。後からローカル通信も取り込む場合は、専用のアウトバウンドマークやプロセス除外を設計し、ノードのドメイン名を解決した後のアドレス変化にも対応してください。

DNSと振り分け：名前解決の経路を把握する

DNSは独立したサービスとして設計することをおすすめします。端末からバイパスルーターの 53 番ポートに問い合わせ、dnsmasqなどのローカルDNSサービスが適切な上位DNSへ転送します。V2Ray設定のDNS機能は、LANに公開されたDNSサービスと同じではありません。待ち受けや転送経路を別途設定する必要があります。

確認しやすい設計の一例は、ローカルDNSサービスをLANの 53 番ポートで待ち受けさせ、指定した問い合わせを、本機の 127.0.0.1:1053 で動作する名前解決サービスへ転送する方法です。ポート番号は例です。実際にサービスが待ち受けていることを確認してください。下流の名前解決サービスが問い合わせを 192.168.10.2:53 に送り返すと、DNS転送ループが発生します。

# nslookupをインストールしたテスト用PCから実行
nslookup example.com 192.168.10.2

# OpenWrtで待ち受けとポリシーを確認
ss -lnup
ip -6 route show
nft list ruleset

結論：速度測定で経路を推測せず、ログで確認する

直接接続する宛先とプロキシを使う宛先をそれぞれ明確に指定し、DNSログ、ルールカウンター、コアのアウトバウンドタグを照合してください。Webページが開けても、接続が完了したことしか確認できず、想定したアウトバウンド経路を通った証明にはなりません。

透過プロキシで取り込んだ通信には、宛先IPしか含まれないことがあります。ドメイン名に基づいて振り分ける場合は、その情報をどこから取得するのか明確にしてください。コアのプロトコルスニッフィングで取得できるのは一部のプロトコルに含まれる情報であり、すべてのアプリからドメイン名を復元できるわけではありません。DNSの応答、ドメインルール、実際の接続先が一致している必要があります。関連項目はDNS設定ガイドを参照してください。ただし、デスクトップクライアントの設定項目をOpenWrtのファイアウォールルールとしてそのまま使うことはできません。

よくあるトラブル：通信経路を段階ごとに確認

ゲートウェイを変更したら通信できなくなった。まず何を確認する？

まずテスト用PCのゲートウェイをメインルーターに戻し、上位ネットワークが正常であることを確認します。次に透過プロキシを無効にし、バイパスルーターの通常転送だけを検証します。LANの転送ポリシー、上位のデフォルトルート、戻りの経路を確認してください。最初にノードを変更する必要はありません。

コアは動作しているのに、接続記録がないのはなぜ？

PCの実際のゲートウェイが 192.168.10.2 になっているか確認し、nftablesルールのカウンターも確認してください。カウンターが増えているのにインバウンドに記録がない場合は、12345 の待ち受けとマークからルーティングテーブルへの対応を確認します。また、ブラウザーが明示的なプロキシ設定を引き続き使っていないかも確認してください。

IPアドレスには接続できるのに、ドメイン名がタイムアウトする

nslookup example.com 192.168.10.2 を実行します。53 番ポートで待ち受けているか、LANから本機へのDNS問い合わせが許可されているか、上位DNSに到達できるかを確認してください。1053 へ転送している場合は、そのポートで実際にサービスが動作していることも確認します。

Webページは見られるのに、ゲームや一部のアプリが使えない

TCPのリダイレクトしか設定していないか、ノードとアウトバウンドが必要なUDP通信に対応しているか確認してください。IPv6のデフォルトルートと関連ルールも確認します。特定のプロトコルを恒久的に遮断して通信の取り込み不足を隠すのではなく、まずアプリが実際に使うトランスポートを確認してください。

ファイアウォール再起動後にプロキシが使えなくなった場合

再起動前後の nft list ruleset と ip rule show を比較してください。カスタムルール、ポリシールーティング、コアのサービスには、それぞれ永続化と起動順序の設定が必要です。同じマークを追加するルールが重複していないことも確認してください。

ログを共有する場合は、時刻、インバウンドタグ、アウトバウンドタグ、エラーの種類を残してください。タイムアウトは、サーバーに到達できない、名前解決に失敗する、戻りの経路に問題があるなど、複数の原因で起こります。ポートの競合は ss -lntup で待ち受けプロセスを確認してください。「接続失敗」という最後の1行だけを切り取らず、サブスクリプションURLや認証情報を公開しないでください。

動作確認と復旧手順：全端末に展開する前に

バイパスルーターを使うと一元管理できますが、障害の影響範囲も広がります。1台での試験では、再起動、DNS問い合わせ、LAN内アクセス、直接接続とプロキシのアウトバウンド、UDP、IPv6を最低限確認してください。すべての確認が終わるまでは、メインルーターの従来のDHCP設定を維持し、全端末のゲートウェイを急いで変更しないでください。

  1. 再起動を確認：OpenWrtを再起動し、コアのサービス、DNS、透過ルール、ポリシールーティングが復旧することと、ルールが重複していないことを確認してください。
  2. LAN内を確認：メインルーターの管理画面、ファイル共有、その他のローカルサービスにアクセスし、LANの除外ルールが必要な通信まで遮断していないことを確認してください。
  3. 障害時の挙動を確認：コアを停止し、取り込まれた接続がどうなるか確認します。障害時に直接接続へ切り替える設計がなければ、プロキシ通信は通常失敗します。自動的に直接接続へ切り替わるとは限りません。
  4. 復旧手順を確認：テスト端末のゲートウェイとDNSを元の値に戻し、カスタムの通信取り込みルールとポリシールーティングを削除します。コアだけを停止してリダイレクトルールを残すと、通信できなくなる場合があります。
  5. 全体への展開は最後に：メインルーターのDHCP設定でバイパスルーターのゲートウェイとDNSを配布したら、端末のリースを更新し、実際に割り当てられたアドレスを確認してください。固定設定の端末は個別に対応する必要があります。
v2rayN をダウンロード対応プラットフォームとインストーラーを見る