v2rayNのTUNモード設定方法｜仮想NICで全通信を処理する仕組みと手順

TUNとシステムプロキシの違い：入口が異なってもルールによる振り分けは行われる

システムプロキシは、127.0.0.1:10808のようなローカルのプロキシアドレスをアプリに提供します。アプリがこの設定を参照すると、プロキシの入口にリクエストを送ります。ブラウザーは通常システムプロキシを利用できますが、コマンドラインのプログラムでは環境変数や個別のプロキシオプションが必要な場合があります。そのため、「ブラウザーはつながるのにターミナルはつながらない」からといって、ノードの障害とは限りません。

TUNはレイヤー3の仮想ネットワークインターフェースです。条件に合うIPパケットはシステムルーティングによってこのインターフェースに送られ、TUNを管理するコンポーネントが接続を処理して出力先を選びます。アプリ側でHTTPやSOCKSプロキシを意識する必要はありません。v2rayNは設定・管理用のインターフェースであり、実際の受信、解析、転送は起動されたコアコンポーネントが行います。一般的なバージョンではsing-box関連のコンポーネントがTUNを処理しますが、詳細は使用中のバージョンのログで確認してください。TUNを有効にしても、Xrayがネイティブに仮想NICを作成するわけではありません。

有効化前の確認：ノード、権限、ローカルポート

まずv2rayNで、接続できることを確認済みのサーバーを選びます。サブスクリプションはサーバー設定を配布する方法、VMessやVLESSなどはノードで使うプロトコル、TUNはローカルの通信を取り込む入口です。それぞれ役割が異なります。もともと接続できないノードが、TUNに切り替えるだけで使えるようになることはありません。

1. メイン画面のサーバー一覧から対象のサーバーを選び、右クリックメニューでアクティブサーバーに設定します。次にシステムプロキシを使い、普段安定してアクセスできるHTTPSページを開けることを確認します。
2. 「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートを記録します。ページ構成や項目名はバージョンによって異なるため、現在の画面に表示されている値を確認してください。以下の10808は例です。
3. システムルーティングを変更しているほかのVPNや仮想NICツールを、いったん終了します。通常のネットワークアダプターはそのままにし、システムデバイスをまとめて無効化しないでください。
4. 作業内容を保存し、タスクトレイで動作しているバックグラウンドプロセスも含め、v2rayNを終了します。プログラムを右クリックして「管理者として実行」を選び、システムのアクセス許可を求める画面で確認します。

管理者として起動してもコンポーネント不足のメッセージが表示される場合は、インストールパッケージが正しく展開されているか、コアファイルがセキュリティソフトによって隔離されていないか、ログに記載されたファイルパスが存在するかを確認してください。出所不明のダウンロードサイトから、名前の似たドライバーファイルを追加しないでください。再インストールが必要な場合は、当サイトのダウンロードページからOSに合ったパッケージを選んでください。

TUNを有効にする：通信を取り込む入口は一度に一つずつ変更

v2rayNは世代によって画面の構成が異なります。よくある設定場所は、メインウィンドウ下部の「TUNを有効にする」スイッチと、「設定」→「パラメーター設定」内のTUN設定です。使用中のバージョンでTUN設定が独立したメニューになっている場合は、同じ名前の項目を開いてください。別バージョンの画面を参考に、存在しない項目を変更しないようにしましょう。

1. アクティブサーバーを確認します。テスト時に別の接続が使われないよう、メイン画面で選択されているサーバーとログの出力設定を確認してください。
2. システムプロキシを解除します。システムプロキシのメニューから「システムプロキシを解除」を選び、ブラウザーに手動で設定したプロキシも一時的に無効にします。これにより、古いローカルプロキシではなくTUNをテストできます。
3. TUNのデフォルト設定を維持します。初回はプロトコルスタック、MTU、ルーティングモード、DNSを同時に変更しないでください。デフォルト設定のほうが、使用中のバージョンの設定生成ロジックと整合しやすくなります。
4. 「TUNを有効にする」をオンにします。コアの起動を待ち、仮想インターフェースの作成やルートの追加に関するログが出るか確認します。すぐに終了する場合は、スイッチを何度も切り替えず、最初のエラーから対処してください。
5. 新しい接続を開始します。開いているウェブページのタブやターミナルの接続をいったん閉じ、改めてアクセスします。確立済みの長時間接続は、設定の切り替え後すぐに経路が変わるとは限りません。

リモートノードのアドレスまでTUNに戻して送らないようにしてください。管理プログラムは通常、インターフェースのバインドやバイパスルートでループを防ぎますが、複数のネットワークツールを同時に使うと、この仕組みが崩れることがあります。同じノードアドレスへの接続がログに繰り返し記録され、タイムアウトや異常な通信量を伴う場合は、まずTUNを無効にしてルーティングの競合を調べてください。

DNSの設定：名前解決の失敗と接続の失敗を切り分ける

DNSはドメイン名をIPアドレスに変換し、その後ルーティングによって接続経路が決まります。TUNで通信を取り込む場合、DNSリクエストにも利用可能な経路が必要です。リモートDNSへの接続にプロキシが必要で、そのプロキシノードのドメイン名も同じリモートDNSでしか解決できない場合、起動時に依存関係の循環が起きることがあります。

• ノードのドメイン名解決：起動時に利用できる名前解決経路を確保してください。証明書の検証やサーバー側の設定で元のドメイン名が必要になる場合があるため、サブスクリプション内のサーバードメインを一時的なIPアドレスに安易に置き換えないでください。
• 直接接続するドメインの名前解決：解決結果が直接接続の経路と合うようにしてください。特に社内サービス、プリンター、社内ドメインでは注意が必要です。
• プロキシ経由のドメイン解決：リモートDNSサーバーへの接続にプロキシを使う設定の場合、まずノードへの接続が確立できることを確認してください。
• ブラウザーのセキュアDNS：ブラウザーが独自に暗号化DNSを使っている場合があります。そのため、ブラウザーとターミナルで結果が異なっても、システムDNSのキャッシュ破損とは限りません。

「設定」→「DNS設定」、または使用中のバージョンの「パラメーター設定」にあるDNS項目を開き、まず現在の値を記録してから、直接接続とリモート名前解決に関する設定を確認します。項目はコアやバージョンによって異なります。独立したコア向けのJSON設定を、GUIの任意の入力欄に貼り付けないでください。初回はそのバージョンで用意されているデフォルト設定を使いましょう。

# Windows PowerShell：ネットワークアダプターの状態とDNS設定を確認
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-DnsClientServerAddress -AddressFamily IPv4

# システムの名前解決経路を確認。調査対象のドメイン名に置き換える
Resolve-DnsName example.com

# DNS設定の変更後にWindowsのDNSキャッシュをクリア
ipconfig /flushdns

Resolve-DnsNameはシステムの名前解決経路を確認するコマンドで、ブラウザー内蔵のリゾルバーの結果を示すものではありません。キャッシュを消去した後は、新しい接続を開始し、必要に応じてテスト対象のアプリを再起動してください。名前解決はできてもHTTPS接続がタイムアウトする場合は、DNSを何度も変更せず、ノード、ルーティング、ファイアウォールを調べましょう。

通信の取り込みを検証：インターフェース、ルーティング、アプリを照合

スイッチがオンになっただけでは十分ではありません。有効化前後のネットワークインターフェースとルーティングを比較し、プロキシを設定していないターミナルからリクエストを送信して、最後にv2rayNのログを確認します。仮想インターフェース名やインターフェース番号は、バージョンや環境によって異なります。特定の名前だけを探さないでください。

# Windows PowerShell：IPv4ルートとインターフェース番号を確認
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table DestinationPrefix, NextHop, InterfaceIndex, RouteMetric

# 現在のターミナルがプロキシ環境変数を引き継いでいるか確認
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# curlの明示的なプロキシを使わず、新しいHTTPS接続をテスト
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/

ここでの--noproxy "*"は、curlがアプリケーション層のプロキシ設定を使わないようにするオプションであり、OSのTUNルーティングを迂回するものではありません。テスト対象のドメインに直接接続するルールが適用されている場合、コマンドが成功しても、現在の経路が使えることを示すだけで、リモートノードを経由した証明にはなりません。プロキシ経由の通信をテストするときは、実際にアクセスが必要で、プロキシルールが適用される宛先を選び、接続ログで出力先を確認してください。

MTUが原因と思われる場合は、元の値を記録したうえで、TUN設定のMTUだけを1400に変更して比較テストし、TUNを再起動します。この値はトラブルシューティングの目安であり、すべてのネットワークに最適とは限りません。改善しなければ元の値に戻してください。DNS、プロトコルスタック、ノードを同時に変更すると、どの変更が影響したのか判断できません。

よくある質問と無効化後のネットワーク復旧

通常の終了時は「TUNをオフにしてからプログラムを終了」の順に操作すると、管理プログラムが一時インターフェースやルートを削除しやすくなります。スリープからの復帰、Wi-Fiの切り替え、社内VPNへの接続後にだけ問題が起きる場合は、発生条件を記録してからTUNを再起動し、再テストしてください。ネットワークの切り替えで物理的な出口が変わると、古いインターフェースのバインドや接続を再確立する必要があります。

• 問い合わせ前に、v2rayNのバージョン、Windowsのバージョン、TUN関連のコアバージョン、最初のエラーが発生した時刻を記録してください。
• 再現手順も記録します。システムプロキシを解除したか、ほかのVPNを終了したか、どのドメインやアプリで失敗したかをまとめてください。
• ログを共有する前に、サブスクリプションのURL、ユーザー識別情報、パスワード、ノードの認証情報を削除し、エラーの種類と必要なネットワーク状態は残してください。