2026年8月27日 · プラットフォーム導入 · 約12分

OpenWrtでXrayを動かす方法｜バイパスルーターの透過プロキシ構成

OpenWrtのバイパスルーターでXrayを動かす手順を解説。主ルーターとの役割分担、ゲートウェイやDNSの設定、透過プロキシの方式選びをまとめます。

この記事の概要

v2rayNでノードの動作を確認済みで、OpenWrtのバイパスルーター経由でLAN内の端末を接続したい方向けです。まずテスト端末1台のゲートウェイを変更し、Xrayのアウトバウンド、DNS、透過転送を個別に確認します。主ルーターとバイパスルーターの役割、REDIRECTとTPROXYの選び方、いつでも元に戻せる導入手順が分かります。複数の環境でそのまま使える汎用ファイアウォールスクリプトは掲載していません。

1. 主ルーター、バイパスルーター、Xrayの役割を整理する

主ルーターは回線接続、家庭内ネットワークのデフォルトゲートウェイ、IPアドレスの割り当てを引き続き担当します。OpenWrtのバイパスルーターは指定された端末の通信を受け取り、直接接続するかXrayに渡すかを判断します。Xrayはプロキシプロトコルとルーティングルールを処理するコアであり、起動しただけでLAN全体が自動的に透過プロキシ化されるわけではありません。

LANポート1つ、同一サブネットの構成を例にします。主ルーターは 192.168.50.1、OpenWrtは 192.168.50.2、テスト用PCは 192.168.50.100 です。これらは説明用のアドレスです。導入時は実際のサブネットに合わせ、主ルーターのアドレスプールからバイパスルーターの固定アドレスを除外してください。

設置場所設定例主な役割
主ルーター192.168.50.1インターネットに接続し、従来のDHCPサービスと管理画面を維持する。
OpenWrtのバイパスルーター192.168.50.2DNSサービスとXrayを動かし、転送と通信の振り分けを行う。
テスト用PC192.168.50.100まずこのPCだけゲートウェイとDNSを変更し、ほかの端末には手を加えない。
バイパスルーターのデフォルト経路192.168.50.1バイパスルーター自体とプロキシサーバーへの接続がインターネットに到達できるようにする。

テスト用PCから海外のサービスにアクセスする場合、想定する経路は「PC → バイパスルーター → Xrayのアウトバウンド → プロキシサーバー」です。直接接続する通信はバイパスルーターから主ルーターへ転送されます。LANポート1つの構成では、直接接続の応答が主ルーターからPCへ直接戻り、非対称経路になる場合があります。LANポート2つのゲートウェイ向けファイアウォール設定をそのまま流用しないでください。

2. 対象範囲を決めてから透過プロキシを検討する

まず、解決したい問題を明確にしましょう。プロキシが必要なのがPCのブラウザーだけなら、v2rayNを使い続けるほうが管理しやすい場合が多いです。SOCKS対応アプリを少数だけバイパスルーター経由にしたいなら、アプリ側でプロキシポートを明示的に指定して試せます。端末ごとにプロキシを設定しにくい場合は透過プロキシが便利ですが、ファイアウォール、ポリシールーティング、DNSの追加管理が必要です。

1台だけを透過プロキシにする

おすすめ

まずPCを1台だけ対象にし、送信元アドレスで透過ルールを限定します。Web閲覧、UDPを使うアプリ、LAN内アクセスを確認してから対象を1台ずつ増やせば、障害の影響を抑えられます。

向いているケース：バイパスルーターの初回導入、家庭内ネットワークの安定性を保ちたい場合

プロキシポートを明示して利用

アプリからバイパスルーターのSOCKSインバウンドに接続します。デフォルトゲートウェイを切り替える前に試せます。ノードとXrayの設定確認には使えますが、透過転送が動作していることの確認にはなりません。

向いているケース：プロキシ設定に対応した少数のアプリ、導入前の段階的な切り分け

ネットワーク全体をデフォルトで接続

DHCPでバイパスルーターをゲートウェイとして配布し、複数の端末をまとめて処理します。リース更新、IPv6、DNS、サービス再起動、障害時の切り戻しまで事前に考慮する必要があり、その後の運用管理も集約されます。

向いているケース：1台での検証が完了し、ネットワーク設定を継続して管理できる場合

結論：既存のゲートウェイは維持し、まず1台だけ変更する

最初の検証では、テスト用PCのIPv4ゲートウェイとDNSだけを 192.168.50.2 に変更し、主ルーターのネットワーク全体向け設定は変えません。バイパスルーターに接続できなくなった場合は、PCをIPアドレスの自動取得に戻せば検証を取り消せます。

3. まずXrayを動作させてからゲートウェイとファイアウォールをつなぐ

以下のメニュー名は、一般的なOpenWrtのLuCI画面を基準にしています。ファームウェアのバージョン、表示言語、インストール済みパッケージによって名称は異なります。OpenWrt 23.05および24.10系で一般的なfirewall4はnftablesを使用するため、旧式のiptables専用透過プロキシスクリプトと混在させないでください。インストール前に、CPUアーキテクチャ、空きストレージ、カーネルモジュールの入手元も確認します。

  1. ネットワークをバックアップする

    「システム」→「バックアップ/アップグレード」を開き、設定のバックアップを作成してダウンロードします。主ルーターとバイパスルーターのアドレスを記録し、主ルーターへ直接接続できる管理手段を確保してください。唯一のリモート接続からゲートウェイを変更するのは避けましょう。

  2. 固定アドレスを設定する

    「ネットワーク」→「インターフェース」→「LAN」→「編集」を開き、バイパスルーターの固定IPアドレス、サブネットマスク、主ルーターを指すIPv4ゲートウェイを設定します。「DHCPサーバー」→「一般設定」で「このインターフェースを無視する」にチェックを入れ、アドレスの二重配布を防ぎます。内容を確認してから保存・適用してください。

  3. アウトバウンドを確認する

    システムのアーキテクチャに合ったXrayを使い、実際に利用できるアウトバウンド設定を用意します。まず、LAN内のテスト端末からのみアクセスできるSOCKSインバウンドでTCP接続を確認します。UDPを試すには、クライアント、インバウンド、リモート側のアウトバウンドがすべて対応している必要があります。

  4. DNSを設定する

    「ネットワーク」→「DHCP/DNS」→「一般設定」を開き、DNSの転送先を確認します。ローカルの 127.0.0.1:5353 で動作するDNSサービスを使う場合、LuCIでは通常 127.0.0.1#5353 と入力します。サービスがそのポートで待ち受けていること、dnsmasqへ再転送する設定になっていないことも確認してください。

  5. テスト端末を接続する

    テスト用PCのネットワーク設定でゲートウェイとDNSを変更し、このPCだけを対象に透過ルールを追加します。インターフェース間の転送許可、カーネルのIP転送設定、戻り経路を確認し、直接接続先とプロキシ経由先を別々にテストします。

  6. 再起動後も動作するか確認する

    現在の接続が正常と確認できたら、ファイアウォールを再読み込みし、次にXray、最後にバイパスルーターを再起動します。ルールが復元されること、DNSが使えること、Xrayの起動前に直接接続の通信が想定どおり処理されることを確認してください。

サブスクリプションURLをXrayの実行設定としてそのまま使うことはできません。v2rayNはサブスクリプションの解析、ノード選択、設定生成を行いますが、Xrayを直接起動するにはインバウンド、アウトバウンド、DNS、ルーティングの完全な設定が必要です。VMessやVLESSのノードで指定されている転送方式、TLS、サーバー名などのパラメーターはサーバー側と一致させてください。サーバーアドレスとポートだけをコピーしても動作しません。

# 以下のパスは、Xrayがインストール済みで、設定ファイルが実際に /etc/xray/config.json にあることを前提とします
xray version
xray run -test -config /etc/xray/config.json

# システムアーキテクチャ、ルーティング、待ち受け状態を確認
ubus call system board
ip -4 route show
netstat -lnptu

4. REDIRECT、TPROXY、通信マークの仕組みを理解する

透過プロキシは単一のスイッチで有効になるものではありません。ファイアウォールが対象通信を識別し、Xrayの透過インバウンドが受信し、ルーティングルールが最後にアウトバウンドを決定します。REDIRECTは主にTCPのリダイレクトに使います。TPROXYはTCPとUDPを処理できますが、対応する透過インバウンド設定、ポリシールーティング、カーネルサポートが必要です。ルール名を置き換えるだけで相互に代用できるわけではありません。

方式用途確認事項
REDIRECT主にTCPの透過的な接続に使用リダイレクト先ポート、元の宛先取得、Xrayの透過インバウンド設定。
TPROXYTCP・UDPの透過的な接続透過ソケット、パケットマーク、ポリシールーティング、ローカルルーティングテーブル。
明示的なSOCKS設定アプリ側でプロキシを指定クライアントのプロキシアドレス、アクセス制御、UDP対応状況。

たとえば透過インバウンドのポートを 12345 に設定した場合、ファイアウォールは対象通信をそのポートへ転送する必要があります。このポートはプロキシサーバーのリモートポートではありません。TPROXYで使うマークとポリシールーティングテーブルも一体で設計してください。マルチWAN、ほかのトンネル、ポリシールーティングサービスが使用中のマークを上書きしないよう注意が必要です。

nft list ruleset で現在のルールを、ip rule show でポリシールーティングを確認し、カスタムテーブルのルートも調べます。nftablesのルールセット全体を安易に削除しないでください。OpenWrtの基本ファイアウォールやリモート管理の保護まで消えるおそれがあります。

5. DNSを独立した通信経路として扱う

Webページが開けない場合は、まず「ドメイン名を解決できない」のか「名前解決は成功するが接続できない」のかを切り分けます。ゲートウェイをバイパスルーターに変更しても、DNSが自動的に経由するとは限りません。アプリ内蔵の暗号化DNS、ブラウザーのセキュアDNS、IPv6で配布されたDNSサーバーが別の経路を作る場合もあります。

53
従来型DNSのUDP/TCPポート
5353
この記事で指定するローカル上流DNSポート
12345
この記事で指定する透過インバウンドポート

後半の2つは設定例であり、Xrayの固定デフォルト値ではありません。既存の待ち受けを確認してから使ってください。5353 はマルチキャストDNSにもよく使われるため、バインドするアドレスとプロセスが競合しないことを確認します。LAN向けのDNSサービスは通常53番ポートで待ち受け、内部の上流DNSはループバックアドレスだけにバインドすれば、不要な外部公開を避けられます。

  1. リクエストが届いているか確認する：PCで nslookup example.com 192.168.50.2 を実行し、バイパスルーターから応答があるか確認します。このテストで確認できるのは指定したDNSサーバーだけで、すべてのアプリがそのサーバーを使っていることを示すものではありません。
  2. 上流への経路を確認する：プロキシ経由でアクセスするDNS上流には、明確なアウトバウンド経路が必要です。プロキシサーバーのドメイン名を解決するための事前解決を、まだ確立していないプロキシ接続だけに依存させないでください。
  3. DNSのループを確認する：dnsmasqからローカルDNSサービスへ転送した後、そのサービスが同じリクエストをdnsmasqへ戻さないようにします。ループがあると、長時間待たされた後にタイムアウトすることがよくあります。
  4. ドメイン名ルールとIPアドレスルールを調整する：ドメイン名で通信を振り分ける場合、Xrayがどのようにドメイン情報を取得するかを明確にします。スニッフィングですべてのアプリをカバーできるとは限りません。宛先IPしか受け取れない場合、元のドメイン名を復元できないことがあります。
  5. IPv6も考慮する：IPv4だけを対象にすると、端末が主ルーターから通知されたIPv6デフォルトルートを使って直接インターネットへ接続する場合があります。まずテスト端末をIPv4に限定して確認し、その後IPv6のルーティングとDNSを別途設計してください。ノードの障害と決めつけないようにしましょう。

結論：名前解決と接続の結果を別々に記録する

変更のたびに一段階ずつ確認します。まずDNSがアドレスを返すか記録し、次にリクエストが使用したアウトバウンドとハンドシェイクの結果を確認します。ノード、DNS上流、透過ルールを同時に変更すると、成功してもどの変更が効いたのか判断できません。

6. 症状から原因を切り分け、元に戻す手順を用意する

少なくとも、ローカルの管理用アドレス、直接接続するはずの宛先、プロキシ経由にする宛先を1つずつ用意します。Xrayのアクセスログでインバウンド、宛先、アウトバウンドのタグを確認し、システムログと照らし合わせます。切り分け中は一時的にログの詳細度を上げ、原因が分かったら適切なレベルに戻してください。ログにアクセス先が含まれる場合があるため、共有前にアドレス、認証情報、サブスクリプション情報を削除します。

ゲートウェイを変更したら、バイパスルーターの管理画面にも接続できない

まずPCのゲートウェイを元の主ルーターに戻すか、IPアドレスを自動取得に戻します。PCとバイパスルーターが同じサブネットにあることを確認してから、192.168.50.2 にアクセスしてください。固定アドレスの競合と管理サービスの待ち受け状態を確認し、いきなりXrayを再インストールするのは避けましょう。

SOCKSでは接続できるのに、透過プロキシが動かない

テスト用PCのデフォルトルート、透過インバウンドのポート、該当するファイアウォールルールのカウンター、TPROXYのマークとポリシールーティングを順に確認します。Xrayにリクエストが届いていない場合は、まず通信の入口を調べましょう。リモートノードの設定を繰り返し変更しても解決しません。

Webページは開くのに、音声通話やゲームがつながらない

まずTCP REDIRECTだけを設定していないか確認し、次にUDP透過インバウンド、リモート側のUDP対応、ファイアウォールの許可設定を調べます。ブラウザーでページを開けてもUDPが処理されている証拠にはならず、すべてのアプリが同じ経路を通るとも限りません。

電源を入れ直したら、また使えなくなった

Xrayの起動状態、DNS上流が利用可能になるタイミング、ファイアウォール再読み込み後のルールを確認します。logread で起動エラーを調べ、ドメイン名の事前解決も再確認してください。端末から一度だけ手動実行し、再起動すると消えるルールに依存しないようにします。

対象を広げる段階になったら、DHCPの配布オプションを検討します。一般的なIPv4 DHCPオプションでは、オプション3がデフォルトゲートウェイ、オプション6がDNSサーバーを指定します。両方を同じ機器にする必要はありません。変更後はクライアントにリースを再取得させる必要があり、既存の接続は古い経路を使い続ける場合もあります。まずリースを更新した端末1台で検証してから、ほかの端末を変更してください。

バイパスルーターの導入で重要なのは、ルールを増やすことではなく、各段階を個別に検証できることです。クライアントが通信をバイパスルーターへ渡していること、ファイアウォールが想定範囲だけを対象にしていること、DNSがループしないこと、Xrayのアウトバウンドが使えること、戻り経路が設計どおりであることを確認します。その後、デスクトップクライアントで動作確認済みのノード設定を長期運用用の設定へ移せば、管理しやすくなります。

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