v2rayN TUNモードの仕組みと有効化手順：全通信を正しく引き受ける方法

TUNモードとシステムプロキシの適用範囲

システムプロキシとは、OSにHTTPまたはSOCKSプロキシのアドレスを登録する仕組みです。たとえばv2rayNでは、ローカルの混合ポートとして 127.0.0.1:10808 がよく使われます。ブラウザーやシステムプロキシ設定に従うデスクトップアプリはこのポートへリクエストを渡しますが、独自に接続を確立するアプリ、常にダイレクト接続を使うアプリ、システムプロキシを参照しないアプリは迂回することがあります。そのため、システムプロキシを有効にしても、すべてのプロセスの通信がXrayコアへ入るとは限りません。

TUNモードでは仮想レイヤー3ネットワークアダプターを作成し、OSのルーティングによって宛先トラフィックをそのアダプターへ送ります。クライアントはIPパケットから接続情報を復元し、ルーティングルールに基づいてプロキシ、ダイレクト接続、ブロックのいずれかを選択します。アプリ側でプロキシアドレスを個別に設定する必要がないため、ゲームプラットフォームやコマンドラインツール、独自のネットワークスタックを使うソフトウェアも一括して取り込みやすくなります。

2つのモードは単純な優劣ではありません

• システムプロキシ：変更範囲が小さく、有効化・終了も簡単です。ブラウザー、オフィスソフト、プロキシ設定に対応したアプリに適しています。
• TUNモード：より広い範囲の通信を取り込めますが、仮想ネットワークアダプターの作成、ルートの追加、昇格した権限が必要です。個別にプロキシを設定できないアプリや、通信を一元的に振り分けたい場合に適しています。
• 全通信：通信がまずTUNの取り込み経路に入ることを指します。すべての宛先が必ずリモートプロキシを通るという意味ではなく、最終的な出力先はルーティングルールで決まります。
• ローカルループバック：127.0.0.0/8、LANアドレス、クライアント自身の接続は適切に除外する必要があります。プロキシをさらにプロキシへ送るループを防ぐためです。

TUNが必要かどうかは、まずシステムプロキシを無効にして対象アプリをテストすると判断しやすくなります。システムプロキシの切り替えにまったく影響されない一方で、通信を統一ルールの対象にする必要がある場合は、TUNが適しています。普段ブラウザーだけを使うなら、「全通信」という表示だけを理由に仮想ネットワークアダプターやルーティング層を追加する必要はありません。

バージョン・ノード・ポートを有効化前に確認

切り分けは、いきなりTUNを何度も切り替えるのではなく、ノードが利用可能かどうかから始めます。まず通常のシステムプロキシモードでノードを選択し、アクセス可能なテストページを開いてください。v2rayNコアのログに認証失敗、TLSハンドシェイク失敗、接続タイムアウトがないことも確認します。ノード自体が使えない場合、TUNを有効にしても問題の範囲が広がるだけです。

以下の数値は、v2rayN 7.15.xのデスクトップ環境で確認する際の目安です。マイナーバージョンによってメニュー名や自動生成されるサブネットが変わる場合はありますが、ポートの競合、デフォルトルート、DNSの取り込みを確認する方法は同じです。

1. サーバー一覧で、動作確認済みのVMessまたはVLESSノードをダブルクリックし、アクティブサーバーにします。
2. 「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートが他のプロキシアプリと重複していないことを確認します。ログに address already in use と表示された場合は、まずポートを使用しているプロセスを終了するか、未使用のポート番号へ変更してください。
3. システムの日付、時刻、タイムゾーンを正しく設定します。TLSおよびReality接続には妥当なシステム時刻が必要で、大きなずれがあるとハンドシェイクに失敗します。
4. 現在のネットワーク状態として、使用中のネットワークアダプター、デフォルトゲートウェイ、DNSアドレスを記録します。異常終了した場合に、残っているのがルート、DNS、仮想ネットワークアダプターのどれかを判断しやすくなります。
5. 仮想ネットワークアダプターを作成したり、デフォルトルートを変更したりする他のネットワークツールは一時的に終了します。複数の取り込みルールが優先度を奪い合うのを防ぐためです。

v2rayN TUN設定の重要パラメーター

v2rayN 7.xでは、「設定」→「パラメーター設定」からTUN関連の設定を開き、保存後にメイン画面へ戻って「TUNモード」を有効にします。バージョンによってはスイッチがメインウィンドウ上部やトレイメニューに配置されていますが、結果は同じです。TUNインバウンドに対応したコアを起動し、仮想ネットワークアダプターを作成してルートを書き込みます。

パラメーターを一度に変更しすぎないでください。初回テストでは自動ルートとインターフェースの自動検出を維持し、競合が確認された項目だけを変更するのがおすすめです。基本経路が確立してからMTU、厳格ルーティング、DNSポリシーを調整すると、どの設定が接続異常の原因かを早く特定できます。

有効化後の確認手順

1. パラメーターを保存してメイン画面に戻り、利用可能なノードを1つ選択した状態にします。
2. TUNモードを有効にし、システムの権限要求を許可して、ステータスバーにコアが正常に動作していると表示されるまで待ちます。
3. コアのログを確認します。TUNインターフェースの作成とルートの追加を示す情報が表示され、permission denied や route add failed が連続していないことを確認してください。
4. ブラウザーの手動プロキシ設定を無効にしてからテスト先へアクセスし、リクエストがルールどおりに通ることを確認します。
5. ダイレクト接続に設定したドメインと、プロキシに設定したドメインを1つずつテストし、TUNによる取り込みとルーティングの振り分けが同時に機能していることを確認します。

Windows・macOS・Linuxの権限の違い

TUNではネットワークインターフェースとシステムルートを操作するため、通常のユーザー権限では不足することがあります。3つのデスクトップOSで目的は同じですが、認証方法は異なります。権限が足りない場合、スイッチが自動的に元へ戻る、仮想ネットワークアダプターが現れない、インターフェース作成時にログが直接エラーになるといった症状が見られます。

Windowsで推奨する操作手順

1. 古いv2rayNプロセスを完全に終了してから現在のバージョンを起動し、2つのコアが同時に 10808 を待ち受けないようにします。
2. まずノードに接続してシステムプロキシをテストし、その後TUNを有効にします。権限確認が表示されたら許可してください。
3. 仮想インターフェースは存在するのに通信がない場合は、システムのルーティング情報を開き、物理ゲートウェイを指す、より高い優先度のデフォルトルートがないか確認します。
4. TUNを終了した後、仮想インターフェースと一時ルートが削除されたことを確認してから、関連ドライバーの再インストールやリセットを検討します。

macOS・Linuxで追加確認する項目

• macOSで複数のネットワークサービスを使っている場合は、実際に外部へ接続しているのがWi-Fiか有線ネットワークかを確認します。インターフェースの自動検出結果は、実際の出口と一致していなければなりません。
• Linuxのデスクトップ環境では、NetworkManagerやsystemd-resolvedがDNSを管理していることがあります。TUNがルートを取り込んでいるのにドメインへ接続できない場合は、名前解決経路を個別に確認してください。
• スリープ復帰後、ネットワーク切り替え後、有線からWi-Fiへ切り替えた後は、元のデフォルトインターフェースが無効になることがあります。その場合はTUNをいったん無効にして再度有効にし、クライアントに出口を再検出させます。
• コンテナや仮想マシンのネットワークでは、独立したプライベートサブネットを使うことがよくあります。TUNのアドレスと重複する場合は、デフォルトルートを追加するのではなく、先にTUNのサブネットを変更してください。

TUN有効化後にルーティングテーブルで起きること

新しいデフォルトルート1本で元のゲートウェイを上書きすると、プロキシコア自身の通信までTUNへ戻され、ループが発生する可能性があります。実際の実装では通常、物理出口を維持しながらIPv4のデフォルト空間を、たとえば 0.0.0.0/1 と 128.0.0.0/1 の2つの、より具体的なルートに分割します。プレフィックスが長いため、これらは元の 0.0.0.0/0 より優先され、通常のアプリ通信はTUNへ入ります。一方、コアからリモートサーバーへの接続は除外ルールによって実際のゲートウェイを通ります。

以下は構造を理解するための簡略化した出力例であり、すべての端末で同じインターフェース名やゲートウェイが使われるわけではありません。重要なのは、「元のデフォルトゲートウェイが残っていること」と「より具体的な取り込みルートがTUNを指していること」の2点です。

対象ネットワーク          ゲートウェイまたはインターフェース
0.0.0.0/0         192.168.1.1
0.0.0.0/1         tun0
128.0.0.0/1       tun0
192.168.1.0/24    ローカル物理ネットワークアダプター
127.0.0.0/8       ローカルループバック

DNSもルーティングの方向と連動させる必要があります。ドメインを先にローカルネットワークで解決し、その後の接続をプロキシ経由で行うと、出口に適さないアドレスが返ることがあります。逆に、すべてのDNSをプロキシ経由にすると、LAN内ホスト名を解決できない場合があります。より安定した方法は、プロキシ対象ドメインにはリモート名前解決を使い、LAN内や明示的にダイレクト接続するドメインにはローカル名前解決を使うことです。また、DNS問い合わせ自体が指定した出力先を迂回しないようにします。

TUNとXrayのルーティングをどう連携させるか

TUNが解決するのは「通信をどのようにクライアントへ入れるか」であり、Xrayのルーティングが解決するのは「入った後、どの出力先から出すか」です。TUNを全プロキシのスイッチとして扱うと、振り分けルールの役割を見落としてしまいます。日常的な設定では少なくとも、プロキシ、ダイレクト接続、ブロックの3種類を区別し、優先度の高い特殊ルールを汎用ルールより前に置く必要があります。

たとえば、LANアドレスや機器の管理ページは先にダイレクト接続へ送ります。プロキシが必要なドメイン群はプロキシ出力先へ振り分け、広告や明確にアクセス不要なドメインはブロック出力先へ送ります。その他の通信は最後にデフォルトポリシーで処理します。ルールは上から順に照合され、先に一致した接続は後続のルールを実行しません。

推奨するルールの優先順位

1. クライアント自身とノードのアドレス：コアの接続が再びTUNへ入らないよう、実際の物理出口を通す必要があります。
2. ループバックとLAN：127.0.0.0/8、一般的なプライベートアドレス帯、ローカル機器のドメインは通常ダイレクト接続にします。
3. ブロックルール：明確に拒否したいドメインやプロトコルにはblock出力先を使い、不要な接続を減らします。
4. プロキシルール：ドメイン群、宛先アドレス、ポート、プロトコルなどで照合し、現在のプロキシ出力先へ送ります。
5. デフォルトルール：最後に、一致しなかった項目をdirectとproxyのどちらへ送るか決め、出力先がない接続の発生を防ぎます。

ルールを変更した後は、ドメインへのリクエストと直接IPへのリクエストを分けてテストします。ドメインだけ失敗する場合は、まずDNSとドメインルールを確認してください。ドメインとIPの両方が失敗する場合は、ノード、ルーティングテーブル、権限を優先して確認します。LAN内の特定機器だけにアクセスできない場合は、プライベートアドレス帯が誤ってプロキシ出力先へ送られていないか確認します。

よくある障害と段階的な復旧方法

TUNの障害は、「権限とインターフェース、ルーティング、DNS、MTU、振り分けルール」の順に確認します。一度に変更するのは1項目だけにし、調整のたびに接続を再確立してください。ノード変更、DNS変更、MTU低下、ルールの並べ替えを同時に行うと、通信が復旧しても本当の原因を特定できません。

最小限のトラブルシューティング項目

• システムプロキシモードでノードが利用可能だと確認できているか。
• TUN仮想インターフェースが正常に作成され、ログに権限エラーが出ていないか。
• 元の物理デフォルトゲートウェイが残り、取り込みルートが正しいインターフェースを指しているか。
• IPアドレスへ直接アクセスした場合と、ドメイン経由でアクセスした場合の結果が異なるか。
• LAN、ループバックアドレス、ノードサーバーのアドレスが正しく除外されているか。
• MTUを1500にした後、大容量ファイルの転送とログインリクエストが復旧したか。
• TUNを無効にしてクライアントを終了した後、一時ルートとDNS設定が解除されているか。

基本経路が安定していることを確認してから、厳格ルーティング、詳細なDNSルール、追加の振り分け条件を段階的に有効にします。ブラウザーだけでプロキシを使う環境では、通常システムプロキシのほうが保守しやすいでしょう。複数のデスクトップアプリがプロキシ設定を参照しない場合は、TUNと明確なdirect・proxy・blockルールを組み合わせることで、制御可能な全通信の取り込みを実現できます。