TUNは、システムプロキシに対応していないアプリの通信も取り込めます。ただし、TUNを有効にしてもすべての通信がプロキシ経由になるわけではありません。この記事ではWindows版v2rayNを例に、仮想NIC、管理者権限、DNS、ルール設定の関係を解説し、有効化前の確認から接続テスト、問題発生時の切り戻しまで紹介します。ほかのデスクトップOSでは権限の仕組みが異なるため、Windowsと同じ管理者権限の操作をそのまま適用しないでください。
1. TUNモードとシステムプロキシの対象範囲
ブラウザーがシステムプロキシ経由で通信できても、ほかのアプリもプロキシを使うとは限りません。システムプロキシはアプリにプロキシの接続先を知らせる仕組みで、設定に従うかどうかはアプリの実装次第です。一方、TUNは仮想レイヤー3ネットワークインターフェースを作成し、OSのルーティングによって条件に合うIPパケットを処理プログラムへ転送します。その後、ルールに応じて直接接続、プロキシ経由、または遮断されます。
| 比較項目 | システムプロキシ | TUNモード |
|---|---|---|
| 通信の取り込み方 | アプリがプロキシ設定を読み取り、ローカルのプロキシポートに接続 | システムのルーティングでパケットを仮想NICに転送 |
| アプリ側の対応 | 通常、アプリがプロキシ設定に対応し、それに従う必要がある | 通常、アプリごとにプロキシを設定する必要はない |
| UDP通信 | システムのHTTPプロキシだけではすべてをカバーできない | 取り込めるが、カーネル、プロトコル、サーバー側の対応が必要 |
| 必要な権限 | 通常、NIC作成の権限は不要 | 通常、管理者権限または事前設定済みのサービスが必要 |
| 最終的な接続先 | アプリの設定とクライアントのルールで決まる | 取り込み対象とクライアントのルールで決まる |
「全通信を取り込む」は入口の対象範囲を指し、「全通信をプロキシ経由にする」は接続先の方針を指します。両者は別の設定です。TUNが動作していても、LAN内のアドレス、ローカルドメイン、ルールで指定された接続先は直接接続になる場合があります。逆に、全通信をプロキシ経由に設定しても、クライアントに届いていない通信は処理できません。
TUNを使ってもノードの帯域は増えず、サーバーが対応していないUDP通信が使えるようになるわけでもありません。プロキシが必要なのがブラウザーだけなら、システムプロキシのほうが設定も元に戻す操作も簡単です。システムプロキシを使わないアプリがある場合に、TUNを検討してください。
2. 仮想NICからプロキシカーネルへ通信が届く仕組み
TUNが受け取るのはIPパケットであり、ブラウザーに表示される完全なURLではありません。クライアントは接続先アドレス、利用可能なドメイン情報、DNSの処理結果などをもとにルールを照合します。ドメイン情報が保持されるかどうかは、DNSの取り込み、スニッフィング、アプリ独自の名前解決方式によって異なります。すべての接続からドメイン名を特定できるとは限りません。
v2rayNは設定・管理用の画面で、実際の通信処理は連携するカーネルが行います。TUNの処理とノードのプロキシ処理には別々のプロセスが使われる場合があり、実装はクライアントのバージョンによって異なります。問題が起きたら、画面上のスイッチだけで判断せず、TUNの起動ログとプロキシのアウトバウンドログを両方確認してください。
- NICは通信の入口：仮想NICが表示されても、インターフェースが作成された可能性を示すだけです。ルーティングやDNSまで有効になったとは限りません。
- ルーティングは通信を振り分ける：宛先ごとに直接接続するかプロキシ経由にするかはルールで決まり、ルールの順序も結果に影響します。
- アウトバウンドは接続を担う：VLESSやVMessなどのノード設定も引き続き有効である必要があります。TUNを使っても、期限切れのサブスクリプションや誤った認証情報は修正されません。
- ループ回避は安定動作に必要：クライアントからサーバーへの通信が再び自分自身に取り込まれないようにする必要があります。システムのデフォルトルートを手作業で変更せず、クライアントが生成した設定を優先してください。
3. 有効化前に権限・ポート・既存のネットワークソフトを確認
まずシステムプロキシで正常に通信できることを確認してから、TUNに切り替えます。これにより、「ノードが使えない」問題と「仮想NICで通信を取り込めない」問題を切り分けられます。サブスクリプションを追加したら、利用可能なサーバーを選び、実際にWebページを開いてください。遅延の数値が表示されるだけでは、DNS、TLS接続、ページ内リソースの読み込みまで正常とは判断できません。
「設定」→「パラメーター設定」でローカルの待ち受けアドレスとポートを確認します。ここでは 127.0.0.1:10808 を例にしていますが、既存の設定をこの値に変更する必要はありません。TUNは、すべてのアプリに10808への接続を求めるものではありません。このポートは主に、既存のローカルプロキシ入口と仮想NICの入口を区別するためのものです。
- 現在の設定を記録：使用中のサーバー、ルーティングモード、ローカルポート、DNSの設定を控えてください。設定のバックアップは管理された場所に保管し、画面を共有する前にサブスクリプションURLや認証情報を隠してください。
- 権限を確認：Windowsでインターフェースを作成したりルートを変更したりするには、通常、管理者権限が必要です。組織管理のデバイスでは、事前に許可を得てください。エンドポイントのセキュリティポリシーを回避してはいけません。
- ほかの通信取り込みを一時停止：テスト中は、ほかの仮想NICを使うプロキシやVPNを終了し、複数のプログラムが同時にデフォルトルートを変更しないようにします。会社のネットワークコンポーネントを安易にアンインストールしないでください。
- インストール状態を確認：OSとプロセッサーのアーキテクチャに合ったインストーラーを使い、連携するカーネルのファイルも残してください。ログにファイル不足が表示された場合は、スイッチを何度も切り替えるのではなく、まずインストールを修復します。
4. Windows版v2rayNでTUNを有効にする手順
コントロールの場所はバージョンによって異なりますが、メイン画面下部にある「TUNを有効にする」が一般的な入口です。サービスモードが用意されている場合、事前にインストールしたサービスが権限を担うこともあります。設定済みのサービスがない場合は、管理者として起動して動作を確認してください。権限の確認画面が繰り返し表示されても、許可が完了したとは限りません。
- 終了して管理者として起動：まずトレイメニューからv2rayNを終了します。次に、プログラムまたはショートカットを右クリックして「管理者として実行」を選び、Windowsの許可画面で承認してください。メイン画面を閉じただけでは、トレイに最小化されている場合があります。
- 動作確認済みのサーバーを選択：システムプロキシモードで正常にアクセスできたノードをそのまま使い、プロトコル、サブスクリプション、ルールを同時に変更しないでください。
- ルーティング方針を固定：「設定」→「ルーティング設定」で現在のルールを確認します。テスト中は、動作確認済みの方針を維持し、LAN内の通信を直接接続する必要があるか確認してください。
- システムプロキシの入口を切り分ける：システムプロキシを「システムプロキシを解除」に切り替えてから、「TUNを有効にする」をオンにします。これにより、ブラウザーにアクセスできた場合、従来のシステムプロキシ経由だった可能性と区別しやすくなります。
- 起動ログを確認：権限不足、NICの作成失敗、アドレスの競合、ポートの使用中などのエラーがないか確認します。エラーが出たら、最初に表示された明確な失敗原因に対処してください。スイッチを何度も続けて切り替えないでください。
- 動作を確認し、元に戻せるようにする：同じテストサイトにアクセスし、次にシステムプロキシを使わないアプリでも確認します。失敗した場合はTUNをオフにし、以前のシステムプロキシ設定に戻して、基本の接続が使えることを確認してください。
TUNの問題を調べるために、システムファイアウォールを長期間無効にしないでください。セキュリティソフトが連携プロセスをブロックしている場合は、プログラムのパス、入手元、組織のポリシーを確認してから、必要な通信だけを最小限の範囲で許可してください。
5. DNSとルーティング設定：通信を取り込めても確認が必要
DNSの問い合わせとアプリの通信は、関連していますが別々の経路です。名前解決に成功しても、アプリの通信がプロキシ経由になるとは限りません。通信がTUNに入っても、ドメイン名が必ずリモート側で解決されるわけではありません。特定のDNSアドレスに一律で置き換えるより、実際の振り分け方針に合わせて設定するほうが確実です。
アプリの通信入口
- システムプロキシ
- TUNの検証時はいったん解除
- TUNの状態
- 有効化して起動ログを確認
- ローカルポート
- 10808はこの記事での例
- ルーティング方針
- 動作確認済みの振り分けルールを維持
ノードの問題をNICの問題と誤認しないよう、変更は一度に1項目だけにします。
ドメイン名の名前解決経路
- 通常のDNS問い合わせ
- 通常はUDPまたはTCPの53番ポートを使用
- 暗号化DNS
- 実際の通信経路を別途確認
- 社内ドメイン
- 到達可能な社内DNSを維持
- IPv6
- アドレス、ルート、取り込み対象を確認
DNSの取り込み設定は現在のカーネル設定に合わせてください。別のカーネル用の項目をそのまま貼り付けないでください。
ブラウザーで暗号化DNSを有効にすると、名前解決の通信が通常の暗号化通信として見える場合があります。ポート53だけを確認しても、どこで名前解決されているかは判断できません。社内ドメインが社内DNSに依存している場合、すべてをパブリックDNSに転送すると名前解決に失敗することがあります。社内ドメイン用の経路を維持し、DNSサーバー自体にも想定した出口から接続できることを確認してください。
- LAN内へのアクセス：プリンター、共有フォルダー、ルーターの管理画面などは、通常、直接接続が必要です。既存のプライベートアドレス向けルールを優先し、テストのためにルール一式を安易に削除しないでください。
- IPv6の経路：IPv4だけを取り込んでいる状態で、アプリがIPv6を優先すると、IPv4とIPv6で異なる出口を使う場合があります。まずログとシステムルートを確認し、どちらを調整するか判断してください。
- ルールとカーネル：V2Ray、Xrayなどの連携カーネルでは、DNSやルーティングの設定項目をそのまま流用できるとは限りません。変更前に、実際に動作しているカーネルと設定形式を確認してください。
6. スイッチだけに頼らずTUNの動作を確認する方法
正常に動作しているかを確認するには、インターフェース、ルールの適用状況、実際のアプリ通信を合わせて調べる必要があります。接続元のIPアドレスを一度確認しただけでは、そのリクエストの結果しか分かりません。すべてのプロセスや接続先が同じ出口を使っている証明にはなりません。テストサイトが直接接続の対象なら、ローカル回線の出口が表示されても正常です。
- インターフェースを確認：Windowsのネットワークアダプター一覧で新しく追加された仮想インターフェースを探し、今回の起動によるものかログと照合します。インターフェース名はバージョンによって変わるため、特定の名前だけで判断しないでください。
- ルートを確認：コマンドプロンプトで以下の読み取り専用コマンドを実行し、IPv4とIPv6のルートを確認します。TUNは、より具体的なルートを使って通信を取り込むことがあり、デフォルトルートを直接置き換えるとは限りません。
- 通信を確認：対象のアプリを起動し、クライアントのログで宛先アドレス、適用されたルール、アウトバウンドの結果を確認します。該当する記録がない場合は、アプリ独自のトンネルや別のネットワークインターフェースへのバインドも確認してください。
- 有効・無効を比較：システムプロキシを解除した状態で、TUNの有効時と無効時に同じアプリへアクセスし、結果を記録します。比較後は必要な設定に戻してください。
ipconfig /all
route print -4
route print -6これらのコマンドはネットワーク状態を表示するだけで、ルートを変更しません。出力にPCのアドレスや内部ネットワーク情報が含まれることがあるため、そのまま公開しないでください。ログにプロキシのアウトバウンドが記録されていても、リクエスト自体が成功したか確認が必要です。「ルールに一致した」段階と「リモート接続が確立した」段階は異なります。
7. TUNが動かない・通信できないときのよくある質問
TUNを有効にするとネットにつながらない。DNSを変更する？ノードを替える？
まずTUNを無効にし、以前使えていたシステムプロキシの状態に戻してください。元のノードでアクセスできる場合は、TUNの起動ログ、管理者権限、ほかの仮想NICとの競合を優先して確認します。システムプロキシでも通信できない場合は、ノードと基本ネットワークを調べてください。DNS、ノード、ルーティングを一度に変更しないでください。
権限不足と表示される。スイッチをオンにしても動かないのはなぜ？
まずトレイからプログラムを完全に終了し、管理者として起動して権限を許可してください。組織管理のデバイスでは、仮想NICの作成が許可されているか確認します。サービス機能をインストール済みのバージョンでは、サービスが実行中かどうかも確認してください。画面上のチェックだけで権限が有効になったと判断しないでください。
Webページは開けるのに、ゲームや通話アプリが接続できないのはなぜ？
まずログで対象アプリの通信を探し、TUNに取り込まれているか、どのルールに一致したかを確認します。次に、ノードとサーバーが該当するUDP通信に対応しているか調べてください。遅延テストの成功だけでは、この確認の代わりになりません。アプリが特定のNICにバインドされている場合は、アプリ側のネットワーク設定も確認してください。
有効にしたら社内ネットワークやプリンターが見つからなくなった場合は？
LAN内の宛先が直接接続になっているか、社内ドメインが引き続き利用可能な社内DNSを使っているか確認してください。既知の社内アドレスで試して、DNSの問題とルーティングの問題を切り分けます。社内ネットワーク全体をプロキシサーバー経由にしないでください。組織のネットワークポリシーに関わる場合は、管理者に変更範囲を確認してください。
ウィンドウを閉じても影響が続く。元に戻すには？
ウィンドウを閉じただけでは、トレイに隠れている場合があります。メイン画面でTUNを無効にし、次にシステムプロキシを解除してから、トレイメニューで終了します。その後、インターフェースとルートが元に戻ったか確認してください。プログラムが異常終了した場合は、もう一度起動して正常に終了します。残留する場合はシステムを再起動し、正体の分からないネットワークアダプターを削除しないでください。
安定して設定するには、まずノード、次にTUNの入口、最後にDNSと通信の振り分けを確認します。変更は一度に1項目だけにし、ひとつ前の状態に戻せるようにしてください。これにより、「通信を取り込めない」「名前解決できない」「アウトバウンド接続に失敗する」という問題を切り分けやすくなり、再インストールやルールの場当たり的な変更を減らせます。