2026年8月28日 · 導入環境 · 約12分

バイパスルーターでV2Rayコアを動かす:ルーターやLinux小型PCでXrayを直接実行する方法

ルーターとバイパスルーターの構成、ゲートウェイ設定、透過プロキシ、DNS転送を解説。LinuxでXrayを動かす際の注意点も紹介します。

この記事の概要

バイパスルーターの導入は、デスクトップクライアントをルーターに移すだけではありません。ゲートウェイ、コアの受け口、ファイアウォール、DNS、戻り経路をまとめて設計する必要があります。Linuxの端末操作に慣れた方向けに、IPv4のテスト用ネットワークを例に導入手順を説明します。まずXrayのアウトバウンドを確認し、次に1台の端末を接続してから、透過プロキシの対象を広げます。設定例は段階ごとの動作確認用です。そのまま実行すればネットワーク全体を切り替えられるスクリプトではありません。

1. ルーターとバイパスルーターの通信経路

メインルーターはインターネットへの出口となり、通常は接続認証、IPアドレスの割り当て、NATを担当します。バイパスルーターは既存のLANに追加する転送用デバイスです。対象の端末から通信をいったん受け取り、直接接続するか、プロキシ経由で外部へ送るかを判断します。LANケーブルをつなぐだけで、ほかの端末の通信が自動的に流れ込むわけではありません。端末のゲートウェイ、DHCPオプション、またはメインルーターのポリシールーティングで経路を指定する必要があります。

この記事では、メインルーターを192.168.10.1/24、Linux小型PCを192.168.10.2/24、テスト用PCを192.168.10.100/24とします。これらは説明用のプライベートIPアドレスです。導入時は実際のネットワークに合わせて変更し、DHCPの自動割り当てと重複しないよう、メインルーターで小型PCのアドレスを予約してください。

1台の端末だけをバイパスルーター経由にする

おすすめ

メインルーターの設定は変えず、テスト用PCのデフォルトゲートウェイだけを192.168.10.2に変更します。小型PCのデフォルトゲートウェイは192.168.10.1のままです。影響範囲が小さく、通信できなくなっても元に戻しやすい方法です。

向いているケース:初回の動作確認、既存の家庭内ネットワーク、端末ごとの段階的な移行

メインルーター上で直接実行

メインルーターでXrayを動かし、同じ機器上で通信を振り分けます。経路を集約できますが、CPUアーキテクチャ、使用可能メモリ、ストレージ容量、ファイアウォールとの連携方法を確認してください。

向いているケース:設定を細かく管理できるルーター、ファイアウォールを保守できるユーザー

2つのLANポートでネットワークを分離

小型PCの上流側をメインルーターに接続し、下流側には独立したサブネットを設定します。下流の端末は小型PCをゲートウェイとして使います。戻り経路を把握しやすい一方、アドレス割り当て、転送、外向きNATを別途設定する必要があります。

向いているケース:独立したテスト用ネットワーク、常設ゲートウェイ

まずはテスト用PC 1台に限定する

初回の導入で、ネットワーク全体のDHCPゲートウェイをいきなり変更しないでください。まず192.168.10.100だけをバイパスルーター経由にし、通常のWeb閲覧、DNS、LAN内アクセスが正常に動くことを確認してから、対象を広げます。

2. Xrayを直接実行する前の環境確認

V2Rayは、この種のプロキシツール全般を指す呼び名として使われることがありますが、XrayとV2Flyは別々のコアプロジェクトで、設定や機能を同一視できません。この記事ではXrayを使用します。v2rayNはデスクトップクライアント、v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。これらのサブスクリプション管理や画面上の設定だけでは、Linuxの透過プロキシは構成されません。

ルーターでは、まずCPUアーキテクチャとシステムCライブラリの要件を確認してください。Linux小型PCでは、サービス管理方式、ファイアウォールの仕組み、実行ファイルの配置場所を確認します。異なるアーキテクチャ向けの実行ファイルは流用できません。また、既存の管理スクリプトがある機器に、別のルールセットを重ねて適用するのは避けてください。

# アーキテクチャ、カーネル、現在のネットワーク状態を確認
uname -m
uname -r
ip -br address
ip route
timedatectl status

# 以下のコマンドは、Xrayがこのパスにインストール済みであることを前提とします
/usr/local/bin/xray version
/usr/local/bin/xray run -test -config /etc/xray/config.json

# この記事の例で使用するポートを確認
ss -lntup | grep -E ':(53|10808|12345)\b'
10808
ローカルSOCKSのテスト用ポート
12345
TCP透過プロキシの受け口ポート
53
従来型DNSで使用するTCP・UDPポート

これらのポート番号は設定例であり、性能測定の結果ではありません。すでに使用中のポートがある場合は、Xrayの設定とファイアウォールルールの両方を変更してください。システム時刻も正確に保つ必要があります。TLSハンドシェイクは証明書の有効期間を確認するため、時刻のずれが原因で接続に失敗することがあります。

3. 5つの手順でテスト用端末を接続

操作はアプリケーション層からネットワーク層へ進めます。まずコアから外部へ接続できることを確認し、次に端末の通信がバイパスルーターへ届くことを確かめてから、透過プロキシの受け口を設定します。ゲートウェイ、DNS、ファイアウォールを一度に変更すると、問題が起きたときに原因の切り分けが難しくなります。

  1. 現在の設定を記録する

    テスト用PCの現在のIPアドレス、ゲートウェイ、DNSを記録し、小型PCでip routeの出力を保存します。/etc/xray/config.jsonもバックアップしてください。リモートで作業する場合は、ローカルから管理できる経路を確保しておきます。

  2. 外向き接続を確認する

    /etc/xray/config.jsonに、127.0.0.1:10808だけで待ち受けるSOCKS受け口と、接続確認済みのプロキシアウトバウンドを設定します。まず設定をテストし、その後、小型PCから対象のアドレスへ接続します。

  3. ゲートウェイを設定する

    Windowsのテスト用PCで「設定」→「ネットワークとインターネット」→使用中のネットワークアダプターのプロパティ→「IP割り当て」→「編集」と進み、IPv4を手動に設定します。例ではIPアドレスを192.168.10.100、サブネットマスクを255.255.255.0、ゲートウェイを192.168.10.2にします。項目の位置はWindowsのバージョンによって多少異なります。

  4. TCPを接続する

    ポート12345に透過プロキシの受け口を追加し、ファイアウォールの対象をテスト用PCの送信元と、実際のLANインターフェースに限定します。まずTCPだけを処理し、LAN内宛ての通信は直接接続のままにします。UDPや小型PC自身の通信は同時に対象へ加えないでください。

  5. DNSを接続する

    小型PCのDNSサービスが問い合わせに応答することを確認してから、テスト用PCのDNSを192.168.10.2に変更します。UDP 53、TCP 53、ドメイン名の名前解決を確認し、最後にネットワークアダプターを再接続して設定が反映されたか確認します。

小型PC自身のデフォルトルートはメインルーターを向く必要があり、自分自身を向けてはいけません。1つのLANポートを同じサブネットで使う構成では、直接転送されたパケットがメインルーターから端末へ直接戻り、非対称経路になる場合があります。SNATを限定的に使うかどうかは、戻り経路とステートフルファイアウォールの要件に応じて判断してください。SNATは元の端末IPアドレスを隠すため、安易に有効化できる万能策ではありません。

4. 透過プロキシとファイアウォールの連携

透過プロキシは2つの要素で構成されます。ファイアウォールが条件に合うパケットをローカルの受け口へ送り、Xrayが元の宛先アドレスを読み取ってアウトバウンドを選択します。ポートを待ち受けるだけでは端末の通信は自動的に取り込まれません。対応する受け口がない状態でリダイレクトだけ設定しても、プロキシは機能しません。

接続方式仕組み適用範囲
明示的なSOCKS接続アプリケーションからローカルの受け口へ接続まず外向き接続を確認する用途に適し、透過的な通信振り分けは不要
TCP REDIRECTNATリダイレクトと元の宛先アドレスの取得を組み合わせるTCPを段階的に確認する用途に適します。UDPも取り込まれるわけではありません。
TPROXY透過ソケット、パケットマーク、ポリシールーティングTCPとUDPを処理できますが、カーネルとファイアウォールの両方で対応が必要です。

以下は、直接接続の動作確認に使う最小構成です。ローカルSOCKSとTCP透過プロキシの受け口を用意しますが、アウトバウンドはfreedomのみで、すべてのリクエストは直接接続されます。プロキシノード、DNSサービス、ファイアウォールルールは含まれません。これを完成済みのプロキシ設定と誤解しないでください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    },
    {
      "tag": "lan-tcp",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp",
        "followRedirect": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

TPROXYは、REDIRECTの名前を置き換えるだけで使えるものではありません。通常はパケットマークで専用のルーティングテーブルを選び、そのテーブルにローカル配送用のルートを設定します。カーネル側の受け口でも、対応する透過ソケットのオプションを有効にする必要があります。マーク値、ルーティングテーブル番号、ファイアウォールの優先度は、既存のシステムルールと重複しないようにしてください。この記事では、機器の環境に依存しないネットワーク全体向けのルールスクリプトは提供しません。

5. DNSの転送は独立して動作確認する

ゲートウェイとDNSは別々に設定する項目です。端末のゲートウェイをバイパスルーターに変更しても、DNS問い合わせまで同じ経路を使うとは限りません。端末が引き続きメインルーターに問い合わせる場合や、ブラウザーが暗号化DNSを使う場合もあります。従来のポート53をリダイレクトしても、HTTPSベースのDNS通信は自動的に転送されません。

まず小型PCに、信頼できるLANだけを対象とするDNSリゾルバーを用意し、問い合わせの上流経路を明示的に設定してください。Xray設定のdnsフィールドはコア内部の名前解決に使うもので、LANのアドレス上で汎用DNSサービスを公開する設定ではありません。コア内部の名前解決、端末からの問い合わせ、ルーティングルールをそれぞれ確認する必要があります。

確認項目確認方法確認のポイント
端末のDNS設定ネットワークアダプターに設定されたDNSアドレスを確認デフォルトゲートウェイだけを変更した状態になっていないか確認
UDPでの問い合わせdig @192.168.10.2 example.com Aサービスの待ち受け、送信元の許可、上流への到達性を確認
TCPでの問い合わせdig +tcp @192.168.10.2 example.com ATCP 53の設定漏れがないか確認
IPv6の名前解決dig @192.168.10.2 example.com AAAAIPv6の通信経路が想定どおりか確認

透過プロキシの受け口に届く通信には、宛先IPアドレスしか含まれていないことがよくあります。ドメイン名で通信を振り分ける場合は、その情報をどこから取得するか検討してください。スニッフィングで一部のHTTPやTLS通信から情報を取得できますが、すべての接続で使えるとは限りません。また、スニッフィングを有効にしても、ブラウザーのDNS動作が統一されるわけではありません。受け口の機能を踏まえて、IPルールとドメインルールを設計してください。

6. 転送、戻り経路、起動順序

透過プロキシに捕捉されなかったパケットも、バイパスルーター上で通常どおり転送される必要があります。LinuxのIPv4転送設定、FORWARDチェーンの許可ルール、上流側の戻り経路がすべて整っていなければなりません。転送を有効にしても、すべてのパケットが許可されるわけではありません。ファイアウォール全体を無条件に許可する設定にしないでください。

# IPv4転送が有効か確認
sysctl net.ipv4.ip_forward

# 逆方向パスフィルタリングの設定を確認。変更するかどうかは実際の構成に応じて判断
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

# ルールとポリシールーティングを確認。リモート接続中にルールを一括削除しないこと
sudo nft list ruleset
ip rule show
ip route show table all

# xray.serviceを作成済みのsystemd環境でのみ使用
systemctl status xray --no-pager
journalctl -u xray -n 80 --no-pager

厳格な逆方向パスフィルタリングは、ポリシールーティングや非対称経路でパケットを破棄することがあります。しかし、通信が切れたからといって全体で無効にするのは避けてください。まず、パケットの受信インターフェースと逆方向ルートを確認し、関連インターフェースに適切な設定を適用するか判断します。nftablesまたはiptablesを使う場合は、システム既存の管理方法に従い、複数のスクリプトが互いの設定を上書きしないようにしてください。

7. よくあるトラブルと復旧手順

切り分ける際は、端末1台、接続先1つ、プロトコル1種類に固定してください。まず明示的なSOCKS接続を確認し、次にTCPの透過プロキシ、最後にDNSとUDPを調べます。タイムアウトをすべてノードの問題と決めつけないでください。パケットがXrayに届いていない場合もあれば、コアから送信された後に戻りの通信がファイアウォールで破棄されている場合もあります。

症状まず確認する項目対処の方向
小型PCからのSOCKS接続も失敗するアウトバウンド設定、システム時刻、サービスログまずアプリケーション層の問題を解決し、端末のゲートウェイは変更しない
SOCKSは正常だが、透過プロキシ経由のアクセスに失敗する送信元の条件、受け口の待ち受け、ルールのカウンターパケットがポート12345の受け口に届いているか確認
IPアドレスへの直接接続はできるが、ドメイン名で失敗するDNSの待ち受けと上流、TCP/UDP 53名前解決サービスを個別に確認し、ノードを何度も変更しない
Webページは見られるが、UDPを使うアプリが失敗するTCPだけを取り込んでいないかUDPの設定を追加してから確認する。TCPの成功だけで代用しない
一部の通信がバイパスルーターを経由しないIPv6ルート、アプリ独自のプロキシ設定、DNSデュアルスタック全体の経路とアプリの動作を確認
再起動後、ネットワーク全体が切断されるアドレスの変更、サービスの起動、ルールの永続化アドレス、サービス、ルールの順に復旧

通信経路を確認するには、小型PCでtcpdump -ni eth0 host 192.168.10.100を実行できます。eth0は実際のインターフェース名に置き換えてください。パケットキャプチャにはドメイン名や通信メタデータが含まれることがあります。対象を絞って短時間だけ実行し、共有する前に機密情報を隠してください。ルールのカウンターと受け口のログを組み合わせると、ブラウザーのエラーだけを見るより障害箇所を特定しやすくなります。

確実に元へ戻せる手順を用意する

動作確認が終わるまでは対象をネットワーク全体に広げないでください。障害が起きたら、まずテスト用PCのゲートウェイを192.168.10.1に戻し、DNSも元の設定に戻します。次に今回追加したルールだけを解除し、ファイアウォール全体は消去しないでください。メインルーター経由の直接接続が正常に戻ったことを確認してから、バイパスルーターの設定を段階的に復旧します。

バイパスルーターの主な利点は、指定した端末の通信をまとめて処理できることです。ネットワーク設定の手間がなくなるわけではありません。安定運用には、受け口、アウトバウンド、DNS、戻り経路、再起動時の動作を明確にしておく必要があります。1台のPCやAndroid端末だけでプロキシを使うなら、まずクライアントでノードとプロトコルを確認するほうが、ネットワーク全体を取り込むより問題を切り分けやすいでしょう。基本用語は用語一覧、接続の問題は応用ガイドの接続トラブル対処をご覧ください。

v2rayN をダウンロード