ルーター・旁路由でXrayコアを直接動かす構成ガイド｜宅内全体でプロキシを共有

まず旁路由の役割をネットワーク内で決める

旁路由でコアを直接動かす構成は、デスクトップクライアントを別の機器へ単純に移すものではありません。プロキシの入口を1台のパソコンからLANの転送経路へ移し、端末が通常のTCP、UDP、DNSリクエストを送信すると、ゲートウェイまたは旁路由がトラフィックを識別してXrayのインバウンドへ渡し、ルーティング規則を適用したうえで、ダイレクトまたはプロキシのアウトバウンドから送信します。テレビ、タブレット、パソコンなどのLAN機器は個別にノード設定を管理する必要がなく、この旁路由を確実に経由すれば、同じ接続経路と振り分け規則を共有できます。

一般的なトポロジーは2種類あります。1つ目は、旁路由を指定機器のデフォルトゲートウェイにする構成です。メインルーターはダイヤルアップ接続、無線接続、DHCPを引き続き担当し、一部の端末だけ静的アドレスやDHCPオプションでゲートウェイを旁路由に指定します。2つ目は、メインルーターを端末のデフォルトゲートウェイとして使い続け、ポリシールーティングで選択したトラフィックを旁路由へ転送する構成です。前者は経路が明確で、デバッグ時にパケットの通過箇所を確認しやすい一方、後者は端末側の変更を抑えられる反面、メインルーターに十分なポリシールーティング機能が必要です。

構築前に、設定を書くのではなく実際の経路を図にしてください。少なくとも、メインルーターのアドレス、旁路由のアドレス、LANのサブネット、上流DNSアドレスを記録します。また、旁路由が固定したLANアドレスを1つだけ持ち、再起動後にDHCPで別のアドレスを割り当てられないことも確認します。LANに複数のサブネットやゲストネットワークがある場合は、旁路由へのアクセスを許可するサブネットと、分離を維持するサブネットを明確にします。

コア、設定、実行ディレクトリの配置

コアを直接動かすための最小構成は、Xray実行ファイル、メイン設定、地理ルールデータ、実行ログ、起動管理です。ディレクトリ配置に唯一の正解はありませんが、役割は分けるべきです。実行ファイルは通常システムのプログラムディレクトリに置き、設定は永続化された設定ディレクトリ、ルールデータは読み取り専用のデータディレクトリに配置し、ログはローテーション可能な場所へ書き込みます。一時ディレクトリに唯一の設定を保存するのは避けてください。ファームウェアの更新、再起動、容量整理で内容が削除される可能性があります。

/etc/xray/
├── config.json
├── conf.d/
│   ├── 10-inbounds.json
│   ├── 20-outbounds.json
│   ├── 30-dns.json
│   └── 40-routing.json
/usr/share/xray/
├── geoip.dat
└── geosite.dat
/var/log/xray/
├── access.log
└── error.log

初回検証には単一ファイルの設定が適しています。読み込み順が分かりやすく、構文エラーの調査も1つの入口だけ確認すれば済むためです。長期運用では設定を分割し、インバウンド、アウトバウンド、DNS、ルーティングを個別に管理できますが、現在の起動方法がディレクトリ読み込みに対応しているか、複数ファイルの結合時に配列とオブジェクトをどう扱うかを確認してください。任意のファイル名が自動的に読み込まれるとは限りません。コアが読み込むのは、起動パラメータで指定された場所です。

アウトバウンドには少なくとも2種類を残します。1つはプロキシ用、もう1つはダイレクト用です。プロキシアウトバウンドのプロトコル、アドレス、ポート、ユーザー識別子、トランスポート方式、セキュリティ層、サーバー名、flowなどのパラメータは、サーバー側と一致させる必要があります。VMessとVLESSは異なるプロトコルであり、アドレスだけを置き換えてフィールドを混用することはできません。サブスクリプションから設定する場合は、まずデスクトップ側で対象ノードに接続できることを確認し、そのパラメータをコア設定へ変換します。サブスクリプションURL自体は、Xrayがそのまま実行できる完全なゲートウェイポリシーではありません。通常はノード情報を提供するだけで、LANの例外、DNS経路、透過インバウンド規則までは旁路由のために決めてくれません。

起動管理には3つの条件があります。システムネットワークの初期化後に起動すること、プロセス終了時に再起動できること、設定エラー時に読みやすいログを残すことです。設定を変更したら、まずコアに備わる設定テストを実行し、その後でサービスをリロードします。構文エラー1つで家庭内ネットワーク全体の経路を止めないためです。構築中のログレベルはwarningまたはinfoに設定できます。安定後は、フラッシュストレージへの継続的な書き込みを避けるため、詳細すぎるアクセスログを長期間残さないようにします。

構成要素	主な役割	構築時の確認事項
Xrayコア	インバウンドを受け付け、ルーティングを実行し、アウトバウンド接続を確立する	アーキテクチャを一致させ、起動パラメータを明確にする
ノード設定	VMess、VLESSなどのリモート接続パラメータを記述する	サーバー側と項目ごとに一致させる
透過転送ルール	LANトラフィックを透過インバウンドへ送る	本機、LAN、予約済みアドレスを除外する
DNS設定	ドメイン解決の経路とルール照合に使う情報を決める	転送ループと意図しない漏えいを防ぐ
サービス管理	起動順序、再起動、ログを制御する	ネットワーク準備後に起動する

透過プロキシ方式：REDIRECT、TPROXY、TUN

透過プロキシの目的は、端末でHTTPやSOCKSのプロキシアドレスを手入力せずに済むようにすることです。ゲートウェイはファイアウォールとポリシールーティングで接続を捕捉し、Xrayの透過インバウンドへ送ります。方式によって対応プロトコル、カーネル要件、運用の複雑さが異なるため、実際のトラフィックに合わせて選択してください。すべてを同時に重ねる必要はありません。

REDIRECT：TCPを中心としたシンプルな経路

REDIRECTは、ゲートウェイのファイアウォールでTCP接続の宛先を書き換え、本機のリスニングポートへ送ります。設定が比較的分かりやすく、TCPゲートウェイ経路の初期検証に適しています。一方、主にTCP転送を解決する方式のため、UDP、リアルタイム通信、元の宛先情報に依存する一部の用途には力不足です。家庭内ネットワークで少数の指定機器からWebサービスへアクセスするだけなら、この方式から始められます。TCPとUDPをより広く引き受ける必要がある場合は、TPROXYまたはTUNを検討します。

TPROXY：元の宛先を保持するポリシー転送

TPROXYはTCPとUDPを引き受ける際に元の宛先アドレスを保持でき、通常はパケットマーク、独立したルーティングテーブル、ローカルルートと組み合わせます。ファイアウォールが条件に合うパケットへマークを付け、ポリシールーティングがそのマークに基づいてパケットを本機の透過インバウンドへ戻し、Xrayが元の宛先を読み取ってアウトバウンドを決定します。関連するカーネルモジュールを利用でき、送信元機器や宛先サブネットを細かく制御したいゲートウェイ環境に適しています。

TPROXYの難しさはノードのフィールドではなく、転送ループを閉じることにあります。Xrayがプロキシサーバーへ接続するために発生させたトラフィックを、再びXrayの透過インバウンドへ送ってはいけません。旁路由自身が必要とする接続を除外しないと、プロキシアウトバウンドが透過ルールに再捕捉され、ループが発生します。LANアドレス、マルチキャスト、ブロードキャスト、ループバック、リンクローカルアドレス、プロキシ対象外の管理ポートも除外してください。プロキシサーバー自体のアドレスもダイレクトにする必要があります。そうしないと、リモートサーバーへ接続するパケットが同じインバウンドへ戻ってしまいます。

TUN：仮想ネットワークインターフェースで一括制御

TUN方式は、仮想ネットワークインターフェースでレイヤー3のトラフィックを受け取り、Xrayが接続を対応するアウトバウンドへ送ります。ファイアウォールによるリダイレクト規則の複雑さを一部減らせ、TCPとUDPもより統一的に処理できます。ただし、TUNにしただけでゲートウェイ構築が自動的に完了するわけではありません。システム側で宛先トラフィックを仮想インターフェースへルーティングし、DNS、MTU、LANの迂回、カーネル自身のトラフィックも処理する必要があります。機器の性能に余裕がない場合、TUNのプロトコルスタック処理と同時接続数がCPUやメモリの負荷を高めます。

3方式は次の順で判断できます。少量のTCPトラフィックだけを検証するならREDIRECT、元の宛先を保持してTCPとUDPを正確に処理するならTPROXY、仮想インターフェースの対応が成熟していて一括制御したいならTUNを検討します。主経路を1つ選んだら規則も単一に保ち、同じパケットがTUNのルートに捕捉された後、ファイアウォールでTPROXYへ送られるような重複を避けてください。

DNSは旁路由構築の要となる経路

「ノードは使えるのにWebページが開かない」問題の多くは、アウトバウンド接続の失敗ではなく、DNS経路とルーティングポリシーが一致していないことが原因です。端末はまずドメインをDNSリゾルバーへ渡し、アドレスを得てから接続を確立します。DNSクエリが旁路由を迂回すると、Xrayからは宛先IPしか見えず、ドメインルールを活用できない場合があります。一方、すべてのクエリを誤って同じ経路へ転送すると、名前解決のタイムアウト、出口に合わない結果、クエリループが起きることもあります。

まず、LAN端末へDNSを提供する機器を決めます。メインルーターが応答を続け、上流へのクエリだけを旁路由へ転送する方法もあれば、指定端末が旁路由のアドレスを直接DNSに使用する方法もあります。どちらの場合も、LAN内のデフォルト経路は1つに明確化するのが理想です。端末がメインルーターと旁路由の2つのDNSアドレスを同時に取得しても、記載順どおりに固定して使うとは限りません。実際のクエリが2つのリゾルバー間で切り替わり、同じドメインに異なる結果が返る可能性があります。

次に、ローカルドメインとパブリックドメインを分けます。ルーターの管理名、家庭内機器名、LAN内のプライベートゾーンは、ローカルレコードを認識できるリゾルバーに渡し、パブリックDNSへ送らないでください。パブリックドメインは、ルールに応じてダイレクトDNSまたはプロキシDNSを選択できます。Xrayのルーティングでドメイン情報が必要な場合は、透過インバウンドがドメインを取得できるようにするか、DNSの応答結果とコアのキャッシュが確実に関連付けられるようにします。

domainStrategyは、ルーティングでドメインとIPを照合する方法を決めます。ドメインルールだけに依存する場合、接続ごとに再解決する必要はありません。geoipルールをドメイン接続の判定に参加させる場合に限り、必要に応じた名前解決を検討します。過剰な名前解決はDNSの往復を増やし、本来ドメインで処理すべきトラフィックを早い段階でIP判定に変えてしまうこともあります。まず「ドメイン優先かIP優先か」を決め、その後で戦略を選択してください。複数の戦略名を性能スイッチのように何度も切り替えるものではありません。

FakeDNSは一部のTUN接管シナリオに適しています。端末へ予約済みアドレスを返し、内部でドメインと仮想アドレスの対応を保存することで、後続の接続から元のドメインを復元できます。ただし、DNSクエリと接続の両方が同じマッピング状態を通る必要があります。LANに旁路由を迂回する機器がある場合、実IPへ直接アクセスするアプリを使う場合、旁路由が頻繁に再起動する場合は、慎重に有効化してください。一般的なゲートウェイ構築では、まず実際の名前解決を使って基本経路を安定させ、その後に仮想マッピングを評価するとよいでしょう。

ルーティングの振り分けはLANの例外から始める

旁路由の第一原則は、LANへの到達性を守ることです。プライベートアドレス、ループバックアドレス、リンクローカルアドレス、マルチキャスト、ブロードキャストをリモートプロキシへ送ってはいけません。プリンター、ストレージ、テレビへのキャスト、ルーターの管理画面は、いずれもローカル接続に依存します。これらの例外を無視すると、インターネットは正常なのに、家庭内機器の検出、ファイル共有、管理画面が使えなくなるという症状が現れます。

第2段階では、宛先に応じてダイレクトとプロキシを決めます。ルールの順序は非常に重要です。Xrayのルーティングは通常、上から順に最初に一致した結果を実行します。より具体的なルールを前に、広いルールを後ろに置き、最後に明確なフォールバックを設定してください。分かりやすい3段構成は、LANと予約済みアドレスをダイレクト、明確にダイレクトが必要なドメインとアドレスをダイレクト、それ以外をプロキシアウトバウンドへ送る形です。geositeとgeoipのデータを使う場合は、ルールデータファイルをコアが読み取れる場所に置き、更新後に主要ルールを再検証します。

第3段階では、送信元機器ごとに振り分けます。旁路由は送信元アドレスに基づいて接管対象を決められます。たとえばテスト用パソコンとテレビだけを透過プロキシに通し、他の機器は元のゲートウェイ経路を維持できます。送信元アドレスのポリシーには安定したアドレスが必要なので、端末が偶然取得したアドレスに頼らず、DHCPでリースを固定することを推奨します。全LANを一度に接管するより、まず1台のテスト機器を追加し、TCP、UDP、DNS、LANアクセスを確認してから範囲を広げる方が安全です。

ポートルールは補助として使うべきです。一般的なWebポートだけではすべてのアプリをカバーできず、現在のアプリはTCPとUDPを切り替えることもあります。「数個のポートだけをプロキシする」ことを完全な振り分け方案と考えると、ページは開くのにメディアや通話が失敗する事態になりがちです。より安定するのは、送信元機器、宛先ドメイン、宛先アドレス、プロトコルを組み合わせて判定し、識別できないトラフィックには明確なフォールバックを設ける方法です。

ループ、通信断、性能ボトルネックを防ぐ

透過プロキシで最も注意すべきなのはトラフィックループです。Xrayがプロキシサーバーへ接続するために送信したトラフィックを、再びXrayの透過インバウンドへ送ってはいけません。一般的な対策には、プロセスの実行ユーザーで迂回させる方法、パケットマークで迂回させる方法、プロキシサーバーのアドレスをダイレクト集合に追加する方法があります。どれを選ぶかはシステムのファイアウォール機能によりますが、結果は検証可能でなければなりません。ログに同じ宛先への接続確立が繰り返し現れず、コネクショントラッキングテーブルも急増しないことを確認します。

旁路由自身のシステムサービスにも明確なポリシーが必要です。時刻同期、ソフトウェア更新、上流DNSクエリは本機から発生するため、それぞれをプロキシ経由にするか決めます。最も安全な出発点は、旁路由本機のトラフィックをダイレクトに保ち、転送トラフィックだけを接管することです。ルールが安定してから、特定の本機サービスにプロキシ経路を追加します。本機からの全出力をいきなり透過接管すると、起動依存関係が増えます。時刻同期、DNS、Xrayのいずれかがまだ準備できていないと、システムサービス同士が待ち続ける可能性があります。

MTUの問題は、小さなページは表示できるのに大容量ファイルや特定サイトで停止するという形で現れます。透過経路、トンネル、上流ネットワークはいずれもカプセル化のオーバーヘッドを増やします。接続のハンドシェイクは正常なのに大きなパケットの転送で止まる場合は、すぐにノードのプロトコルを変えるのではなく、パスMTUとTCP MSSを確認してください。調整はネットワークインターフェースと実際の経路から始め、複数箇所で値を重複して小さくしないようにします。

性能面では、機器に表示されるポート速度が透過プロキシのスループットを意味するわけではありません。暗号化処理、ルール照合、コネクショントラッキング、TUNのプロトコルスタック、ログ書き込みがすべてリソースを消費します。テスト時はCPUの単一コア使用率、空きメモリ、接続数、温度を同時に観察してください。単一コアが長時間フル稼働しているなら、ルールや同時接続を増やしても速度は向上しません。低消費電力の機器には、簡潔なルール、必要最小限のログ、安定したプロトコルパラメータが適しています。

固定手順で稼働確認を行う

旁路由の構築は層ごとに検証し、各段階で1つの問いだけに答えるのが適しています。途中の手順を飛ばすと、どの「アクセスできない」問題にもゲートウェイ、DNS、ファイアウォール、Xray、リモートノードが同時に関係する可能性があり、調査コストが急激に上がります。

基本ルーティングを検証する。透過ルールを無効にし、テスト端末のゲートウェイを旁路由に設定して、メインルーター、LAN機器、インターネットへアクセスできることを確認します。
コアのアウトバウンドを検証する。Xrayの明示的なSOCKSまたはHTTPインバウンドを使って単体テストを行い、プロキシノードのパラメータがサーバー側と一致していることを確認します。
透過入口を1つだけ有効にする。まずテスト端末だけを接管し、パケットカウンターとXrayのアクセスログが対応していることを確認します。
LANの例外を追加する。ルーターの管理画面、ファイル共有、機器の検出、その他のローカルサービスが引き続き利用できることを確認します。
DNSを接続する。端末が実際に問い合わせるアドレス、旁路由から上流へのクエリ、接続のアウトバウンドが一致していることを確認します。
TCPとUDPをテストする。Web閲覧、ダウンロード、メディア、リアルタイム接続を個別に確認し、1つのWebページだけで成功と判断しないでください。
再起動をシミュレーションする。旁路由を再起動し、アドレス、ポリシールーティング、ファイアウォール規則、Xrayサービスが正しい順序で復旧することを確認します。
対象機器を段階的に増やす。固定アドレスの機器を毎回1グループずつ追加し、障害時の入口として旁路由を経由しない管理用機器を1台残します。

ログの判断も層ごとに行います。Xrayが接続を受け取っていない場合は、端末のゲートウェイ、ファイアウォールのヒット、ポリシールーティングを先に確認します。接続は受け取っているのにアウトバウンドがない場合は、ルーティングタグとルール順を確認します。アウトバウンド確立後にタイムアウトする場合は、ノードパラメータ、リモート到達性、システム時刻を確認します。ドメインだけが失敗してアドレスへの直接アクセスが正常なら、DNS経路に戻って調査します。プロトコル、セキュリティ層、ルーティング項目を無作為に変更するより、固定した手順の方が効果的です。

デスクトップクライアントとの使い分け

旁路由でコアを直接動かす主な価値は集中管理です。複数の機器でノード、DNS、ルーティング規則を共有する場合、ゲートウェイ設定を1つ保守するだけで済みます。明示的なプロキシを設定しにくいLAN機器にも、デフォルトゲートウェイ経由で一貫した経路を提供できます。その代わり、障害の影響範囲は広がります。旁路由のサービス、DNS、転送規則に問題が起きると、複数の機器が同時に影響を受ける可能性があります。そのため、これは通常のクライアントインストールというより、ネットワーク基盤に近い構成です。

v2rayNは、1台のWindows、macOS、Linuxデスクトップでの日常利用やノード検証に適しています。グラフィカルインターフェースでサブスクリプションのインポート、サーバー切り替え、ログ確認、システムプロキシの調整を簡単に行えます。パソコンごとにノードを選びたい場合や、異なるネットワーク間を頻繁に移動する場合は、デスクトップクライアントの方が適用範囲を明確にできます。Android機器では、コアの要件に応じてv2rayNGまたはv2flyNGを選び、端末上で接続を管理できます。

2つの方式を併用することもできます。旁路由は固定機器と基本的な振り分けを担当し、デスクトップ側にはノード検証や一時的なポリシーのためにv2rayNを残します。併用時は二重接管を避けてください。パソコン上のv2rayNでシステムプロキシやTUNを有効にし、デフォルトゲートウェイでも透過プロキシを使うと、同じ接続が2段階で転送される可能性があります。ノードをテストする際は、そのパソコンを一時的に旁路由の透過ルールから除外するか、ローカルの接管を無効にして、有効な経路を1つだけ残します。

比較項目	旁路由でのコア直接運用	デスクトップクライアント
設定範囲	複数のLAN機器を一括してカバー	機器ごとに個別管理
透過接管	ファイアウォール、ポリシールーティング、またはTUNが必要	通常はシステムプロキシまたはローカルTUNを使用
障害の影響	複数の機器に影響する可能性がある	通常は現在の機器に限定される
ノードのデバッグ	設定ファイルとログに依存	グラフィカルインターフェースで直接操作できる
適した用途	固定ネットワーク、DNSと振り分けの一元管理	持ち運ぶパソコン、個別ポリシー、すばやい切り替え

プロキシが必要なパソコンが1～2台だけなら、まずデスクトップクライアントを使う方が通常は保守しやすいでしょう。家庭内ネットワークに固定機器が複数あり、DHCP、静的ルート、ファイアウォール、DNSを管理できるようになってから、安定したノードを旁路由へ移行することを検討します。構築完了の基準は「すべてのトラフィックをプロキシへ送る」ことではありません。経路を説明でき、LANに到達でき、DNSと振り分けが一致し、再起動後に自動復旧できることが重要です。