v2rayNはデスクトップ向けクライアントです。TUNを使うと、システムプロキシを参照しないアプリの通信も取り込めます。この記事ではWindowsでの操作を中心に、「ノードの接続確認、権限の確認、仮想NICの有効化、ルーティングの検証」の順で設定し、DNSやLAN、終了後の復旧についても解説します。ほかのデスクトップOSでは権限の付与方法が異なるため、Windowsの管理者権限による手順をそのまま適用しないでください。
1. TUN仮想NICとシステムプロキシの違い
システムプロキシは、アプリにプロキシの接続先を知らせる仕組みです。ブラウザーなどシステム設定に従うソフトはリクエストをローカルのプロキシポートに送りますが、独自に接続したりシステム設定を無視したりするソフトは、そのまま直接接続する場合があります。そのため、「ブラウザーではアクセスできるのに、コマンドラインツールではできない」場合も、ノードの障害ではなく、通信経路の違いが原因かもしれません。
TUNはシステムのネットワーク層に仮想インターフェースを作成し、ルーティングによって条件に合うIPパケットを処理カーネルへ渡します。通常、アプリごとにプロキシアドレスを設定する必要はありません。ここでいう「全通信の取り込み」は対象範囲を指し、すべての接続がリモートノードを経由するという意味ではありません。TUNに取り込まれた通信も、ルールに応じて直接接続、プロキシ接続、遮断に振り分けられます。
v2rayNは画面表示、設定の生成、プロセス管理を担い、実際の通信転送はカーネルが行います。一般的なデスクトップ版ではsing-boxでTUNを実現しますが、組み合わせはバージョンや設定によって異なります。「TUNを有効にした」だけで、Xrayの機能がすべて自動的に有効になるわけではありません。VMessとVLESSはノードのプロトコル、REALITYは通信を保護する方式です。いずれも仮想NICのドライバーではなく、TUNに切り替えるためにサブスクリプションを再生成する必要もありません。
| 比較項目 | システムプロキシ | TUNモード |
|---|---|---|
| 通信の取り込み位置 | アプリのプロキシ設定 | システムルーティングと仮想インターフェース |
| アプリ側の設定 | プロキシ設定の参照または手動設定が必要 | 通常、アプリごとの設定は不要 |
| UDP対応 | 接続方法やアプリによる。HTTPプロキシだけではすべてをカバーできない | カーネル、ノード、サーバーすべての対応が必要 |
| 必要な権限 | 通常、仮想NICの作成は不要 | インターフェースの作成とルーティング変更の権限が必要 |
2. 有効化する前にノード、権限、ローカル接続先を確認
まずTUNを無効にし、システムプロキシを使ってノード経由でHTTPSサイトを開けることを確認します。ノード自体が使えない状態で仮想NICを追加すると、切り分ける要因が増えるだけです。サブスクリプションの追加方法はサブスクリプション設定ガイドを参照してください。接続できない場合は、まずトラブル対処のログ確認方法を試します。
- 現在の設定を記録：使用中のノード、ルーティングモード、ローカルの待ち受けポート、カスタムDNSを控えます。サブスクリプションURLやノードの認証情報を含む設定は、公開せずローカルに保存してください。
- ほかの通信制御を終了：ほかのVPN接続や、デフォルトルートを変更するツールを一時的に無効にします。会社のリモート接続で制約がある場合は、ネットワーク設定を変更してよいか事前に確認してください。
- 権限を確認：Windowsではv2rayNを完全に終了し、プログラムを右クリックして「管理者として実行」を選びます。権限の確認ダイアログが表示されたら許可してください。ウィンドウを閉じてもタスクトレイに最小化される場合があるため、トレイのメニューから終了します。
- 実行ファイルを確認：ログにTUN関連のカーネルやドライバーが見つからないと表示された場合は、OSのアーキテクチャに合った完全版の配布パッケージを使用してください。不明な配布元からDLLだけを入手して追加するのは避けてください。
この3つの数値は、ローカルの接続先、名前解決、Webサイトへの接続を区別するためのものです。すべてをファイアウォールで開放する必要があるわけではありません。特に、トラブルシューティングのためにローカルの待ち受けアドレスを 127.0.0.1 から 0.0.0.0 に変更しないでください。TUNでローカルアプリの通信を取り込むために、プロキシ接続先をLANに公開する必要はありません。
3. v2rayNでTUNを有効にする手順
設定画面の項目はデスクトップ版によって場所が異なります。一般的には「設定」→「パラメーター設定」から「TUNモード設定」を探します。メイン画面に「TUNを有効にする」スイッチがある場合もあります。以下は機能名を目印に操作してください。該当する項目が見つからない場合は、現在のバージョンとOSを確認し、別バージョンの画面を見て不明な項目を変更しないでください。
- 接続確認済みのノードを選択。使用中のノードが正しいことを確認し、システムプロキシ経由でWebページを開けることも確認します。
- 通信経路を一本化。まずシステムプロキシを「システムプロキシを解除」に切り替え、クライアントのカーネルは起動したままにします。この時点でプロキシ接続先にアクセスできなくなるのは想定どおりです。次の手順でTUNに通信を渡します。
- TUNの初期設定を維持。初回の有効化では、プロトコルスタック、MTU、インターフェース名、DNSポリシーを同時に変更しないでください。まずは現在のバージョンのデフォルト設定で、再現可能な状態を作ります。
- 「TUNを有効にする」をオン。ログにインターフェースの作成、カーネルの起動、ルーティングの初期化に関する情報が出るか確認します。スイッチがオンになっただけでは設定完了とは限らないため、実際に接続を試してください。
- 仮想インターフェースを確認。Windowsの「設定」→「ネットワークとインターネット」→「ネットワークの詳細設定」でネットワークアダプターを確認します。次の読み取り専用コマンドを使う方法もあります。
- 動作確認後に調整。Webページと対象アプリの両方が接続できることを確認してから、カスタムルーティングを一つずつ戻します。変更のたびにテストし、複数の条件をまとめて変更しないでください。
Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
Sort-Object RouteMetric |
Select-Object -First 20 DestinationPrefix, InterfaceAlias, NextHop, RouteMetric上記のコマンドはPowerShellで実行し、アダプターとルーティングの情報を読み取るだけです。インターフェース名はカーネルによって異なり、ルーティングの取り込みに複数の、より具体的なプレフィックスを使うこともあります。0.0.0.0/0のルートがあるかどうかだけで成功を判断せず、インターフェースの状態、起動ログ、実際の接続記録をあわせて確認してください。
4. ルーティングとDNSをあわせて設定
TUNで通信を取り込んだ後も、適切なルールによる振り分けが必要です。LAN機器、社内ネットワーク、ノードサーバーへの接続には、それぞれ正しい経路を設定してください。すべてのアドレスを機械的にプロキシへ送ると、ルーティングループが発生することがあります。一般的なバージョンではプロキシの外向き通信に使うインターフェースや迂回経路が処理されますが、カスタム設定、複数の仮想NIC、複雑なポリシールーティングによって経路が崩れる場合もあります。
ルーティングの確認項目
- LAN
- プライベートIPアドレスと実際の社内ネットワークを直接接続にする
- プロキシ対象
- 現在のルールセットに従ってプロキシ経由にする
- デフォルトの出口
- ルールに一致しない通信の処理方法を明確にする
- ノードへの接続
- ノードサーバーへの通信が再びプロキシに入り、ループしないようにする
まず組み込みルーティングを使い、必要な社内ネットワークの範囲だけ追加します。
DNSの確認項目
- 直接接続での名前解決
- 現在のネットワークから到達できる名前解決経路を選ぶ
- プロキシ経由の名前解決
- 指定した出口からDNSサーバーに接続できることを確認する
- 初回の名前解決
- ノードのドメイン名を、まだ確立していないプロキシ接続に依存させない
- IPv6
- 名前解決の結果と実際のIPv6ルーティング能力を一致させる
切り分け中はデフォルトのDNS設定を維持し、動作確認後に変更します。
DNSでよくある問題は循環依存です。ノードへの接続には、まずノードのドメイン名を解決する必要があります。その名前解決リクエストまでノード経由に設定すると、接続が成立しません。何度もパブリックDNSを切り替えるのではなく、ノードのドメイン名を最初に解決できる経路を用意してください。暗号化DNSを使う場合も、DNSサーバーのドメイン名を最初に解決する手段が必要です。
- LANの例：プリンターのIPアドレスが
192.168.1.50の場合、ネットワーク範囲192.168.1.0/24がローカル接続になることを確認します。プリンター名だけを登録し、名前解決後のIPアドレスを考慮しない設定では不十分です。 - アプリ独自のDNS：ブラウザーのセキュアDNSは、独立したHTTPSリクエストを使う場合があります。ポート53のDNS通信を取り込む設定だけで対応できるとは限りません。切り分け中はブラウザーの設定を記録し、必要に応じて一時的にシステムのDNSを使用してください。
- IPv6の例：ドメイン名からAAAAレコードが返されても、利用可能なIPv6の出口がないネットワークでは、しばらく待ってから接続が切り替わる場合があります。まず通信経路がIPv6に対応しているか確認し、その後クライアントのIPv6設定を変更してください。システムのネットワークアダプターだけを変更するのは避けます。
5. スイッチだけでなく、TUNの動作を確認
「通信を取り込めているか」と「正しく振り分けられているか」の両方を確認します。まずシステムプロキシが解除され、対象アプリにも手動のプロキシ設定がないことを確かめてから、利用可能なサイトにアクセスしてください。ブラウザーに元のプロキシ設定が残っていると、サイトが開けてもTUNが機能している証拠にはなりません。
- HTTPS接続をテスト：アクセス可能なHTTPSサイトを開き、クライアントのログに該当する接続が表示されるか確認します。ページのキャッシュで通信できているように見えることもあるため、必要なら未アクセスのページを開いてください。
- 対象アプリをテスト：もともとシステムプロキシを参照しないアプリを起動し、接続結果とログを確認します。アプリが仮想マシンやコンテナ内で動作している場合、ホスト側のTUNが独立したネットワークまで取り込むとは限りません。
- 振り分けをテスト：直接接続するはずの社内アドレスと、プロキシ経由にするはずのドメインにアクセスし、ログのルールと出口を比較します。外部IPアドレスの確認結果が示すのは、その確認リクエストの経路だけであり、すべてのアプリの通信を表すものではありません。
- UDPをテスト：対象アプリでUDPが必要な場合に限り、UDP通信を確認します。TCPのWebページが開けてもUDPが使えるとは限りません。サーバーのポリシーやノードの通信方式によって制限される場合があります。
curl.exe --noproxy "*" -I --connect-timeout 10 https://example.com/1回の遅延テストだけで速度を判断しないでください。ノード一覧の遅延は特定の方法で測定した値であり、動画の通信速度やゲームの往復遅延とは異なります。比較時はノード、ネットワーク、接続先を固定し、システムプロキシとTUNだけを切り替えると、違いがどの層で発生するか判断しやすくなります。
6. TUN有効化後に接続できない場合のFAQ
TUNをオンにするとすぐネットにつながらなくなります。まず何を変更すればよいですか？
まずTUNを無効にし、元のシステムプロキシに戻してノードを確認します。すぐに復旧する場合は、管理者権限、仮想インターフェースの作成失敗、ルーティングの競合を重点的に確認してください。復旧しない場合は、ノードとローカルカーネルを先に調べます。条件は一度に一つだけ変更し、ネットワークアダプターをすべて削除するのは避けてください。
ログに「access denied」と表示されます。プログラムを再起動すれば直りますか？
権限が不足している可能性があります。まずタスクトレイから完全に終了し、管理者として実行してください。それでもエラーが出る場合は、拒否された操作がインターフェースの作成、ルーティングの変更、ファイルの読み取りのどれかを確認します。管理対象の端末ではセキュリティポリシーも確認し、ファイアウォールをすべて無効にして試すのは避けてください。
Webページは開けますが、プリンターや社内ネットワークに接続できません。
プライベートIPアドレスが直接接続になっているか確認し、会社で実際に使用しているネットワーク範囲も調べてください。社内ネットワークによっては、追加のルートや専用DNSが必要です。一般的なプライベートIPの範囲を許可するだけでは足りない場合があります。まずTUNを無効にして比較し、組織のネットワーク要件に沿ってルートを追加してください。
ログにDNSタイムアウトが出続け、ノードを変えても改善しません。
現在のバージョンのデフォルトDNS設定に戻し、ローカルネットワークとDNSの出口に接続できるか確認します。ノードのドメイン名で初回の名前解決が循環していないかを調べ、ブラウザーのセキュアDNSとIPv6も確認してください。pingに失敗しただけではDNSやプロキシの障害とは判断できません。接続先がICMPに応答しない場合もあります。
スリープから復帰すると接続できなくなります。再インストールが必要ですか？
まずTUNを一度オフにしてからオンにし、カーネルに物理インターフェースを再検出させます。Wi-Fiの切り替え、有線LANの抜き差し、スリープによって使用する出口のインターフェースが変わることがあります。解決しない場合はクライアントを通常の手順で終了してから再起動し、ネットワーク切り替え前後のログを残してください。すぐに再インストールする必要はありません。
7. TUNが適した用途と安全な終了手順
ブラウザーだけでプロキシを使うなら、設定が少ないシステムプロキシで通常は十分です。システム設定を参照しないデスクトップアプリを複数使う場合、通信を一括で振り分けたい場合、またはアプリでUDPが必要な場合はTUNを検討してください。TUNで広がるのは通信を取り込む範囲であり、ノードの帯域が増えるわけではありません。サーバーへの接続不可、サブスクリプションの期限切れ、プロトコル設定の誤りが自動的に解決することもありません。
- 通常の終了手順：まずTUNを無効にし、カーネルが関連ルートを削除するまで待ってから、タスクトレイからv2rayNを終了します。引き続きシステムプロキシを使う場合は、該当するモードを再度有効にしてください。
- 異常終了した場合：クライアントを再起動し、TUNを一度有効にしてから無効にして、設定をクリーンアップします。あわせてWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」に手動プロキシが残っていないか確認してください。
- 復旧しない場合：ログを保存してシステムを再起動し、物理ネットワークを確認します。インターネットで見つけたルート一括削除コマンドをそのまま実行すると、社内ネットワークや必要な接続まで削除されるおそれがあります。
- 設定後の記録：使用できるノード、ルーティングモード、DNSポリシー、テスト結果を記録します。今後のアップデートやネットワーク変更で問題が起きたときに、基準として一つずつ比較できます。
判断基準はシンプルです。システムプロキシを解除した状態で対象アプリが想定どおり接続できること、直接接続する対象はそのまま直接接続されること、終了後にシステムネットワークが正常に戻ること。この3点を確認してからカスタムルールを少しずつ追加すると、最初から複雑な設定を組むより管理しやすくなります。