TUNモードの設定方法：仮想ネットワークアダプターで全通信を取り込む仕組みと設定手順

TUNモードが解決するのは「ノードに接続できるか」だけではありません

通常のシステムプロキシは、HTTPまたはSOCKSプロキシのアドレスをOSに登録します。システムプロキシ設定を参照するブラウザーやアプリは、リクエストをローカルのインバウンドポートへ送ります。一方、設定を無視するアプリ、独自のネットワークスタックを使うアプリ、UDP接続を直接作成するアプリは、既定のネットワークアダプターから直接接続し続けることがあります。この場合、ノード自体は正常でも、アプリが通信をクライアントへ渡していません。

TUNモードが変えるのは通信の入口です。クライアントは仮想的なレイヤー3ネットワークアダプターを作成し、システムのルーティングテーブルに通信を取り込むルールを書き込みます。アプリが送信したIPパケットはいったん仮想アダプターへ入り、v2rayNまたはv2rayNGからXrayコアへ渡されます。コアはドメイン、宛先IP、ポート、プロトコルに応じてルールを照合し、最終的に直接接続、プロキシ、ブロックのいずれかへ振り分けます。

「全通信を取り込む」とは、すべてのデータを無条件にリモートノードへ送ることではありません。LANアドレス、クライアント自身の接続、システム予約済みネットワーク、明示的に設定した直接接続ルールは、通常プロキシを迂回します。正しいTUN設定ではプロキシループを避ける必要があります。コアがサーバーへ接続する通信まで同じプロキシ経路に再び入ると、接続タイムアウト、CPU使用率の上昇、ネットワークの完全な切断につながることがあります。

• システムプロキシ：導入が簡単で、プロキシ設定に従うブラウザーや一般的なデスクトップアプリに適しています。
• TUNモード：対応範囲が広く、システムプロキシを参照しないTCPアプリや、多くのUDPアプリも処理できます。
• ルーティング分岐：コアに入った通信の行き先を決めるもので、TUNを有効にするかどうかとは別の階層です。
• ノードプロトコル：VMess、VLESSなどはクライアントとサーバー間の通信を担いますが、ローカルアプリにプロキシを自動利用させるものではありません。

有効化する前に権限、コア、既存のネットワークコンポーネントを確認

仮想ネットワークアダプターの作成やシステムのルーティングテーブル変更には、高い権限が必要です。Windowsのv2rayNでは通常、管理者権限でTUNを起動します。macOSとLinuxでは、初回のネットワークインターフェース作成やルート書き込み時にシステムの許可を求められます。Androidのv2rayNGは、システムが提供するVPNサービスで仮想インターフェースを構築し、初回起動時に接続許可が表示されます。

以下の数値はこの記事で使用する参考環境を示すもので、プロトコル互換性に必要な最低バージョンではありません。バージョンによってメニュー名が変わる場合でも、確認順序は同じです。まずコアが起動できること、次に仮想ネットワークアダプターが存在すること、最後に既定のルートとDNSが切り替わっていることを確認します。

1. まず通常のシステムプロキシモードで同じノードに接続し、サーバーアドレス、ポート、ユーザーID、TLSまたはREALITYのパラメータが有効であることを確認します。
2. 仮想ネットワークアダプターを作成したり、既定のルートを変更したり、DNSを引き継いだりする他のネットワークアプリを終了し、2組のルールが同時に有効にならないようにします。
3. 現在使用しているLANのネットワーク範囲を記録します。たとえば家庭用ルーターでは 192.168.1.0/24 がよく使われ、この範囲は通常、直接接続として残します。
4. ローカルポートの競合を確認します。10808 が別のプロセスに使用されている場合は、クライアントのパラメータ設定でポートを変更し、コアを再起動します。
5. 動作するノードを1つ、基準として残します。サブスクリプションに複数のノードがある場合、TUNの切り分け中に頻繁にノードを切り替えないでください。

v2rayNデスクトップ版でTUNを有効にする手順

まずサブスクリプションを更新し、通常のプロキシで接続確認済みのノードを選択します。VMessとVLESSはいずれもTUNのプロキシ出力として使用できます。TUNはノードの項目を変更せず、サブスクリプションの再生成も必要ありません。インポートしたノードが通常モードで接続できない場合は、先にノード設定を修正してから仮想ネットワークアダプターを確認します。

1. 起動権限：v2rayNを完全に終了します。Windowsでは管理者権限で再起動し、macOSまたはLinuxではシステムに表示されたネットワーク設定変更の許可を承認します。
2. インバウンドパラメータを確認：「設定」→「パラメータ設定」を開き、ローカル混合ポートが使用されていないことを確認します。この記事の例では 10808 を使用します。
3. TUNパラメータを確認：「設定」→「パラメータ設定」→「TUNモード設定」の順に開きます。まずは既定のスタックとMTUを維持し、複数の詳細項目を同時に変更しないでください。
4. ルーティングモードを選択：メイン画面で必要なルールを選択します。初回確認ではプロキシ対象が広いルールを使い、取り込みに成功したことを確認してから、ドメインとIPによる分岐に戻します。
5. TUNを有効化：メイン画面の「TUNモード」スイッチをオンにします。ステータスバーにコアの稼働が表示され、システムのネットワーク一覧に新しい仮想インターフェースが現れるはずです。
6. 接続を確認：ブラウザー、コマンドラインアプリ、以前プロキシを通らなかったアプリをそれぞれテストします。ブラウザーだけ成功する場合は、システムプロキシのスイッチだけでなく、ルーティングテーブルとDNSを確認します。

有効化後は、ウェブページだけで結果を判断しないでください。ターミナルで一度ドメインを名前解決し、IPルールで振り分けられる対象へアクセスしながら、v2rayNのログにインバウンド記録が出るか確認します。TUNからの新しい接続がログに現れれば、データはコアに入っています。ログがまったくない場合は、権限、仮想インターフェース、システムルートに問題がある可能性が高いです。

Androidのv2rayNGで通信を取り込む手順

v2rayNGはAndroidのVPNサービスを通じて仮想ネットワークインターフェースを作成します。接続ボタンで起動するのはローカルHTTPプロキシだけではありません。Xrayコアを使用する場合、アプリの通信は仮想インターフェースに入り、ルーティングモジュールへ渡されるため、システムプロキシ設定を参照しないアプリもルールで処理できます。

1. 設定をインポート：サブスクリプションリンクでサーバー一覧を更新するか、完全なVMess、VLESS設定をインポートします。ノードを選択したら、まず実接続による遅延テストを1回実行します。
2. 動作モードを確認：「設定」→「モード」を開き、LANにローカルプロキシポートを提供するだけでなく、VPNによる取り込み方式になっていることを確認します。
3. VPNパラメータを確認：「設定」→「VPN設定」を開き、まず既定のMTUを維持します。現在のネットワークで一部ページの読み込みが止まる場合は、少しずつ下げて調整します。
4. アプリごとのルールを設定：すべてのアプリに同じルーティングを適用する場合は、不要なアプリ除外を無効にします。指定したアプリだけを取り込む場合は、包含モードまたは除外モードを明確に選択します。
5. 接続を開始：メイン画面に戻って接続をタップし、システムのネットワーク接続許可を承認します。ステータスバーに接続状態が表示されてから、対象アプリをテストします。
6. ログを確認：メインメニューからログを開き、DNSクエリ、ルールのヒット、プロキシ出力を確認します。何度も再接続する場合は、アプリがリストに含まれていないのではなく、ノードの失敗や基盤ネットワークの切り替えが原因であることが多いです。

Androidでは通常、アクティブにできるVPNサービスは1つだけです。別のネットワークツールが接続中だと、v2rayNGが仮想インターフェースを作成できなかったり、接続直後にシステムによって終了させられたりします。省電力設定によって画面消灯後にバックグラウンドプロセスが制限されることもあります。画面ロック後に通信が切れる場合は、v2rayNGのバックグラウンド実行とバッテリー使用に関する設定を確認します。

• 1つのアプリだけ失敗する：アプリごとのプロキシリストと、そのアプリが独自DNSや特殊なUDP経路を使っていないか確認します。
• すべてのアプリが失敗する：まずノード、システムの許可、現在のWi-Fiまたはモバイルネットワークが利用可能か確認します。
• 接続後にLAN機器へアクセスできない：プライベートアドレスが誤ってプロキシ出力へ送られていないか確認します。
• モバイルネットワークは正常でWi-Fiだけ異常：Wi-FiのDNS、IPv6、MTUの違いを重点的に確認します。

ルーティング、DNS、MTUが取り込み後の動作を左右する

TUNはデータを処理経路へ送るだけで、最終的な結果はルーティングルールによって決まります。一般的なルールはドメイン、宛先IP、ポート、ネットワーク種別で照合します。プライベートアドレスとローカルアドレスは通常直接接続し、プロキシが必要なドメインはプロキシ出力へ、広告や危険なドメインはブロック出力へ送ります。ルールの順序は重要です。範囲が広すぎる前方ルールは、後続の詳細なルールを覆い隠します。

DNSはTUNのトラブル対応で最も見落とされやすい部分です。アプリがドメインを要求すると、クライアントはルーティング判断に使えるドメインまたはIP情報を取得する必要があります。別のローカルサービスにクエリを横取りされたり、到達不能なアドレスが返されたり、名前解決結果のアドレスファミリーがルールと一致しなかったりすると、「クライアントは接続済みなのに、一部のドメインだけ開けない」状態になります。

MTUを一度に大幅に下げるのは避けます。1500、1460、1400の順にテストし、変更するたびに再接続します。同じノード、同じネットワーク、同じダウンロード対象で比較してください。MTUが大きすぎると断片化や経路上のパケット損失が起こり、小さすぎるとパケット数と処理負荷が増えます。

推奨する振り分けの優先順位：
1. ローカルアドレスとクライアントプロセス → 直接接続
2. LANおよびプライベートアドレス → 直接接続
3. 明示的にブロックするドメインまたはIP → ブロック
4. プロキシが必要なドメインとアドレス範囲 → プロキシ
5. その他の通信 → 現在のポリシーに従って処理

よくある競合を現象別に切り分ける

TUNのトラブル対応を「クライアントの再インストール」から始める必要はありません。入口、名前解決、ルーティング、出力の4層に分けてログを確認するほうが効果的です。毎回1つの変数だけを変更し、変更前後の接続時間、ログのキーワード、失敗する範囲を記録します。

TUNを長期利用しやすいケース

TUNは、複数のプログラムをまとめて取り込みたい場合、UDPを処理したい場合、または機器ごとにプロキシアドレスを設定できない場合に適しています。各アプリへSOCKSポートを個別に入力する手間を減らせますが、障害の影響範囲も広がります。誤った既定ルート1つで端末全体がネットワークから切断され、広すぎるプロキシルール1つでLANアクセスが遠回りになることもあります。

• 有効化を推奨：システムプロキシを参照しないプログラム、プロキシが必要なUDP、統一した振り分けが必要な複数アプリ、頻繁に切り替えるコマンドラインツール。
• 有効化しなくてもよい：プロキシが必要なのはブラウザーだけで、ブラウザーがシステムプロキシ設定に安定して従っている場合。
• ルールによる振り分けを推奨：LAN機器、中国本土向けの直接接続サービス、プロキシ対象へ同時にアクセスし、出口の範囲を管理したい場合。
• 一時的な無効化を推奨：ローカルネットワーク、ルーター設定、DNSの障害を調査中で、まず最も単純な物理ネットワーク経路を復旧したい場合。

保守しやすい設定では、3つの境界を明確に保ちます。クライアント自身の接続は直接接続、LANと予約済みアドレスも直接接続、プロキシが必要な対象はVMessまたはVLESSの出力へ送ります。サブスクリプションの更新がサーバー一覧の置き換えだけなら、通常TUNとルーティングルールを再設定する必要はありません。新しいサブスクリプションでプロトコル項目やコアの要件が変わった場合は、まず通常のプロキシモードでノードを確認します。

設定後は、固定したテスト項目を残すことをおすすめします。ブラウザーでのアクセス、ターミナルでのドメイン名前解決、LAN機器へのアクセス、UDPアプリ1つ、大容量ファイルのダウンロードです。5項目で、システムプロキシ、DNS、プライベートネットワーク、UDPの取り込み、MTUをそれぞれ確認できます。今後のバージョンアップやルーティングルール変更時も、同じ順番で再テストできます。