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

システムプロキシとTUNモードでは通信を取り込む位置が異なる

プロキシクライアントを有効にすると、ブラウザーから対象サイトへアクセスできます。しかし、ゲームランチャーやコマンドラインツール、一部のデスクトップアプリは直接接続したままです。これはTUNを使う代表的な場面です。問題はノードではなく、通信がクライアントに入っているかどうかにあることが多いでしょう。システムプロキシとTUNモードはいずれもV2RayまたはXrayにリクエストを処理させますが、通信経路に入る位置が異なります。

システムプロキシは、OSにHTTPまたはSOCKSプロキシのアドレスを書き込みます。この設定を読み取るアプリは、リクエストをv2rayNのローカル待受ポートへ送り、コアがルーティング規則に従ってプロキシ、直接接続、ブロックを判断します。ブラウザーやシステムのネットワーク設定に従う多くのデスクトップソフトは対象になりますが、独自のネットワークスタックを使うアプリ、UDPのみを送信するアプリ、システムプロキシを無視するアプリ、直接接続に固定されたプログラムは、この入口を迂回することがあります。

TUNモードでは仮想ネットワークアダプターを作成し、対応するルートをOSに追加します。ルーティング範囲に該当するパケットはまず仮想アダプターに入り、クライアントによってプロキシコアが処理できる接続へ変換されます。アプリ側でローカルプロキシポートを知る必要も、SOCKSアドレスを個別に入力する必要もありません。そのためTUNは、コマンドラインプログラム、ゲーム通信、UDPリクエスト、複数アプリの混在通信をまとめて取り込みたい場合に適しています。

比較項目	システムプロキシ	TUNモード
取り込みレイヤー	アプリがプロキシ設定を自ら読み取る	システムのルートがパケットを仮想アダプターへ送る
アプリ側の対応	アプリがHTTPまたはSOCKSプロキシに対応している必要がある	多くのアプリで個別のプロキシ設定が不要
UDP対応	アプリとプロキシの入口に依存	仮想アダプターで一括して取り込み、コアへ渡せる
必要な権限	通常は一般ユーザー権限で利用可能	アダプターの作成やルート変更時に権限昇格が必要な場合がある
トラブルシューティングの難易度	経路が短く、普段のWeb閲覧に向いている	アダプター、ルート、DNS、コアのログを同時に確認する必要がある

全通信の取り込みは、すべての接続をプロキシ経由にすることではない

「TUNで全通信を取り込む」と「すべての通信を強制的にプロキシへ送る」は別の話です。前者は通信の入口を示し、パケットがまず仮想アダプターに入ることを意味します。後者はルーティングの結果を示し、コアに入った後でプロキシのアウトバウンドへ送るかどうかを意味します。ルーティング規則が有効であれば、同じTUNアダプターで受け取った通信を、プロキシ、直接接続、ブロックに振り分けられます。

たとえば、LANアドレス、ルーターの管理画面、一部のローカルサービスは直接接続のままにできます。プロキシが必要なドメインやIPは現在のノードへ送り、広告ドメインや明らかに接続不要な宛先はブロックできます。v2rayNで選択したルーティングモード、ユーザー定義ルール、コア設定が最終的なアウトバウンドを決めます。TUNを有効にしたからといって、既存の振り分けロジックをすべて削除するのではなく、新しい入口でもルールが期待どおり機能するかを先に確認してください。

1つの接続は、おおむね次の経路を通ります。

アプリがドメインまたはIPへの接続を開始
→ OSのルートテーブル
→ TUN仮想ネットワークアダプター
→ DNS解決と通信の識別
→ V2Ray、Xray、または互換コアのルーティング規則
→ プロキシのアウトバウンド / 直接接続のアウトバウンド / ブロック

ここで見落としやすいのが、ルーティングの循環を防ぐことです。プロキシクライアント自身がサーバーへ接続する通信までTUNに戻すと、「クライアントがノードへ接続し、その接続が再びクライアントへ戻る」というループになります。成熟したクライアントは、除外ルート、インターフェースのバインド、プロセス単位の処理などでループを防ぎますが、ファイアウォール、ほかの仮想アダプター、手動ルートによって結果が変わることがあります。有効化後すべての接続がすぐタイムアウトする場合は、ログに重複接続、ルーティングループ、または接続先サーバーのアドレスが誤って取り込まれた形跡がないかを優先的に確認してください。

v2rayNでTUNモードを有効にする

v2rayNはバージョンによってボタンの位置が変わることがありますが、基本的な手順は同じです。まず通常のプロキシ接続を安定させ、次にネットワークアダプターを設定できる権限でTUNを起動します。ノードを検証する前に、サブスクリプション、ルーティング、DNS、TUNを同時に変更しないでください。障害が起きたとき、どの手順が原因か分からなくなります。

サブスクリプションを取り込み、ノードを更新する。
v2rayNに完全なサブスクリプションURLを追加し、サブスクリプションを更新して利用可能なノードを選択します。まずシステムプロキシで普段使うWebサイトを開き、接続ログを確認してください。ノードのアドレス、ポート、UUID、トランスポート方式、TLSなどのパラメーターが正常に機能することを確認します。
ルーティングモードを確認する。
現在、グローバル、LANと一般的な直接接続アドレスの迂回、カスタムルールのどれを使っているか確認します。初めてTUNを有効にする場合は、結果を判断しやすいルールを残し、LANのサブネットが誤ってリモートへ送られないようにしてください。
仮想ネットワークアダプターの作成に必要な権限を付与する。
v2rayNを完全に終了し、管理者権限で再起動してから、画面上のTUNスイッチを使います。一部のバージョンにはサービスモードが用意されています。クライアント画面の案内に従ってインストールと起動を完了してください。サービスが正常なら、普段の切り替えで同じ権限設定を何度も行う必要はありません。
TUNを有効にして状態を確認する。
メイン画面、トレイメニュー、またはステータスバーにあるTUNモードを有効にします。クライアントが対応するコアを起動し、仮想ネットワークアダプターを作成してルートを書き込みます。起動済みと表示されるまで待ち、その後OSのネットワークアダプターに対応する仮想インターフェースが表示されるか確認します。
通信を種類ごとにテストする。
まずブラウザー、次にシステムプロキシを読み取らないアプリ、最後にUDPが必要なケースをテストします。リアルタイムログも確認し、リクエストが期待するプロキシまたは直接接続ルールに一致していることを確認してください。Webページが開くかどうかだけで判断してはいけません。

v2rayNでは複数のコアを管理できます。TUNを実際に処理する互換コアは、クライアントのバージョン、現在の設定、選択した機能によって異なります。ログにTUNパラメーターがコアでサポートされていないと表示された場合、スイッチを何度も切り替えるのではなく、まずクライアントと対応するコアのバージョンが一致しているか確認し、設定に旧バージョンのフィールドが残っていないか確認してください。

正常に有効化できた後も、システムプロキシを同時に有効にする必要があるとは限りません。TUNはルーティング層から対象通信を取り込めるため、システムプロキシも有効にすると、一部のアプリはローカルプロキシポートを経由し、ほかのアプリは仮想アダプターを経由することがあります。2つの入口は共存できますが、トラブルシューティングでは主な入口を1つに絞ると、ログから接続経路を確認しやすくなります。

v2rayNGでAndroid端末の通信を取り込む

v2rayNGはAndroidのシステムが提供するVPNインターフェースを通じて通信を取り込み、その役割はデスクトップの仮想ネットワークアダプターに近いものです。バージョンによっては「TUN」という名前の総合スイッチがなく、接続ボタンを押した後にVPN接続の権限を求めます。システムのステータス領域に接続済みと表示され、通信がv2rayNGに入っていれば、アプリはすでにこの仮想ネットワーク入口を使っています。

利用可能な設定を取り込む。
サブスクリプションURLでノードを更新するか、完全なVMess、VLESS設定を取り込みます。ノードを選択したら、まずアドレス、ポート、トランスポートパラメーターを確認してください。設定ミスを仮想ネットワークの障害と誤認しないためです。
接続をタップし、システムの権限を確認する。
初めてVPNインターフェースを確立するとき、システムに接続確認が表示されます。権限を許可すると、v2rayNGが仮想インターフェースを確立し、ほかのアプリのパケットを受信できるようになります。以前に権限を拒否した場合は、接続を停止して再度開始し、システムのVPN管理状態も確認してください。
アプリの対象範囲とルーティングを設定する。
バージョンによってアプリ単位のプロキシや迂回機能がある場合は、すべてのアプリを対象にするか、指定したアプリだけを仮想インターフェースへ入れるかを先に決めます。ルーティング規則はコアに入った後のプロキシと直接接続の方向を決め、アプリの対象範囲はどのプログラムをこの経路に入れるかを決めます。
バックグラウンド実行の制限に対処する。
v2rayNGに必要なバックグラウンド通信を維持することを許可し、画面ロック後にシステムが接続を終了しないようにします。画面点灯中は正常なのに、ロックしてしばらくすると切断される場合は、ノードを頻繁に変更する前にバッテリー設定とバックグラウンド制限を確認してください。

v2rayNGはXrayコアを使用し、Xrayのプロトコルやトランスポート機能が必要な設定に適しています。v2flyNGはv2flyコアを使用し、設定の取り込み、システム仮想ネットワークの確立、ルーティングに基づく通信処理という流れは同じです。画面が似ているからといって設定機能を混用できるわけではありません。サブスクリプションに特定のコア専用フィールドが含まれている場合は、そのフィールドを認識できるクライアントを選んでください。

DNS設定がドメイン振り分けの正確さを左右する

TUNを有効にした後、接続を確立できるかどうかはノードだけでなく、DNSリクエストを誰が処理するかにも左右されます。アプリがドメインへアクセスするとき、ルーティング規則はgeosite、完全なドメイン、ドメインサフィックスなどの情報を必要とする場合があります。コアに入る前にドメインがシステムでIPへ解決されると、コアから見えるのは宛先IPだけになることがあります。この場合、ドメインルールが機能するかどうかは、スニッフィング、DNSマッピング、具体的な設定によって決まります。

よくある問題の1つは、DNSリクエストがクライアントに入っていないことです。WebリクエストはTUNを通るのに、名前解決は従来のネットワークインターフェースへ送られるため、解決結果とプロキシの出口が一致しなかったり、一部のドメインがタイムアウトしたり、ルールへの一致が不安定になったりします。別の問題は、クライアントDNS、システムの暗号化DNS、ほかのネットワークツールなど、複数のDNS取り込み機能を同時に有効にすることです。転送が重複したり、問い合わせがループしたりする可能性があります。

DNSは次の順序で整理することをおすすめします。

仮想ネットワークアダプター、ルート、DNSを同時に変更するほかのネットワークツールを停止し、v2rayNまたはv2rayNGだけを残します。
クライアントの現行バージョンがサポートするDNS設定を使い、古い設定のフィールドを新しいコアへそのままコピーしないでください。
ドメイン振り分けが必要な場合は、コアがドメイン情報を取得できることを確認し、ログで実際に一致したドメインまたはIPを確認します。
直接接続するドメインとプロキシ経由のドメインに適切な解決経路を選び、プロキシ対象ドメインが解決後に誤って直接接続の出口へ送られないようにします。
DNSを変更した後はTUN接続を再確立し、仮想アダプターのアドレス、ルート、名前解決設定をまとめて更新します。

「スニッフィングを有効にする」ことも、多ければよいわけではありません。スニッフィングは一部の接続からドメインを復元し、ドメインルールの一致を助けますが、完全なDNS設計の代わりにはならず、すべてのプロトコル通信に適用できるわけでもありません。特定のアプリで接続異常が起きた場合は、ログを照合して、DNSに結果がないのか、宛先IPへ到達できないのか、ルールが誤った出口へ送っているのかを判断してください。

TUN有効化後にインターネットへ接続できない場合の確認手順

TUNの障害は、ローカルの入口からリモート側へ段階的に確認します。いきなり十数個のノードを交換すると、変数が増えるだけです。まず仮想アダプターが作成されているかを確認し、次にルートとDNS、最後にノードとサーバー側の状態を判断してください。

1. 仮想ネットワークアダプターが表示されない

スイッチを押すとすぐオフに戻る、またはログにインターフェースの作成失敗が表示される場合は、まずクライアントを完全に終了し、十分な権限で起動します。続いて、同名の無効な仮想アダプターがシステムに残っていないか、セキュリティポリシーがクライアントによるネットワークデバイスの作成を妨げていないか確認します。クライアントが実行中のまま、使用中のインターフェースを手動で削除しないでください。

2. 有効化するとすべての接続がタイムアウトする

まずTUNを無効にし、システムプロキシで現在のノードを確認します。通常のプロキシでもタイムアウトするなら、問題はノード、サブスクリプションのパラメーター、または基礎ネットワークにあり、TUNを調整し続けるべきではありません。通常のプロキシが正常なら、TUNを再び有効にし、ログでノードサーバーのアドレスが仮想アダプターへ戻されていないか確認します。また、デフォルトルートがほかのネットワークツールに上書きされていないことも確認してください。

3. Webページは開くが、ゲームや音声通信に接続できない

この場合は通常、UDPを確認します。使用しているプロトコル、トランスポート経路、アウトバウンドがUDP通信に対応していることを確認し、アプリのパケットがTUNに入っているかを確認します。Webが使えることは、TCPとDNSの一部経路が正常だと示すだけで、UDPが同じ経路で転送されている証拠にはなりません。

4. ドメインには接続できないが、IPへ直接アクセスすると応答がある

DNSを重点的に確認します。ログに名前解決のタイムアウト、問い合わせループ、DNSアウトバウンドへの到達不能がないか確認してください。DNSを取り込むほかのプログラムを停止し、TUNを再接続してから、直接接続用ドメインとプロキシ用ドメインを個別にテストします。特定のルールグループだけが失敗する場合は、そのグループがdomain、geosite、解決後のIP条件のどれを使っているかを確認します。

5. LAN内のデバイスにアクセスできない

プライベートアドレスが直接接続に設定されているか確認し、ローカルファイアウォールが仮想アダプターを厳しい制限が必要な新しいネットワークとして認識していないか確認します。一般的なLANの範囲は、ルーティング規則で明確に処理する必要があります。プリンター、ルーター、共有デバイスへアクセスする場合は、まずLAN内IPでテストし、その後デバイス名の名前解決を確認します。

6. TUNを無効にしてもネットワークが復旧しない

まずクライアントを通常の手順で終了し、ルートのクリーンアップを実行させてから、現在の物理ネットワークインターフェースを再度有効にします。システムプロキシが停止済みのローカルポートを指していないか確認し、デフォルトゲートウェイとDNSが普段のネットワークに戻っていることも確認してください。プロセスを強制終了すると一時設定の削除が間に合わないことがあるため、クライアントの停止・終了操作を優先します。

システムプロキシ、TUN、ルーティングモードの選び方

普段のWeb閲覧、サブスクリプションの更新、システムプロキシに明確に対応したソフトウェアには、まずシステムプロキシを選ぶとよいでしょう。経路が短く、必要な権限も少なく、ログも読みやすいからです。システムプロキシに従わないデスクトップアプリ、コマンドラインのダウンロード、ゲーム、UDP通信にはTUNへ切り替えます。

端末全体を対象にする必要がある場合は、まずTUNで通信を一元的に取り込み、その後ルーティング規則で振り分けます。「全通信の取り込み」を単純に「すべてプロキシへ送る」と考えてはいけません。適切な設定では通常、LANへの直接接続を残し、プロキシが必要な対象のドメインやルールセットを指定し、接続できない宛先もログから経路を追えるようにします。

設定変更では、1つずつ変える原則に従います。まずノードを検証し、次にTUNを有効化します。その後アダプターを確認してDNSを調整し、ルールへの一致を観察してから複雑な振り分けを追加します。v2rayN、v2rayNG、v2flyNGはいずれも、接続入口、宛先アドレス、アウトバウンドの選択、エラー原因をログに出力します。ログと実際のテストを照合するほうが、ノードを何度も切り替えるより問題を見つけやすくなります。