この記事では、Windows版のv2rayNを使って操作します。まずノードとローカルプロキシを確認し、管理者権限でTUNを有効にした後、ルーティング、DNS、対象アプリを検証します。「全通信を取り込む」とは、TUNに入る通信の範囲を広げることです。すべての接続がプロキシ経由になるわけではなく、実際の対象範囲はルーティング、除外設定、IPv6の構成によって異なります。
1. TUNとシステムプロキシの違い：通信の入口が変わっても、ルーティングは必要
システムプロキシは、プロキシのアドレスをOSの設定に登録し、アプリ側がそれを使う仕組みです。ブラウザーは通常この設定に従いますが、一部のコマンドラインツールやゲーム、独自のネットワーク機能を持つアプリは自動では利用しません。そのため、ブラウザーでサイトにアクセスできても、ほかのアプリが同じプロキシ経由で通信しているとは限りません。
TUNはIPパケットを受け取るレイヤー3の仮想ネットワークインターフェースです。有効にすると、クライアントがOSのルーティングと連携し、条件に合うパケットをTUNへ送ります。TUNを動かすコアが接続を処理し、ルールに照らして出力先を選びます。すべてのアプリにHTTPプロキシのポートを通知する仕組みではありません。
| 比較項目 | システムプロキシ | TUNモード |
|---|---|---|
| 通信の入口 | アプリがローカルプロキシに接続 | OSがルートに一致するパケットを仮想インターフェースへ送信 |
| アプリ側の対応 | アプリがシステム設定に従うか、プロキシを個別に設定する必要がある | 通常、アプリ側にプロキシ設定の項目は不要 |
| 権限 | 現在のユーザーのプロキシ設定変更には、通常、昇格権限は不要 | インターフェースの作成やルートの設定には、通常、昇格権限が必要 |
| 出力先の選択 | プロキシコアのルーティングルールで決定 | 実際に動作するコアのルーティングルールで決定 |
つまり「グローバル」には、少なくとも2つの意味があります。より多くのアプリをプロキシの処理経路に取り込むことと、処理経路に入った接続をすべてプロキシ経由にすることです。TUNが主に解決するのは前者です。LANへの直接接続、宛先の除外、ほかの仮想NIC専用のルートなどによって、一部の接続がTUNを通らない場合があります。
2. 有効化前の確認：ノード、コア、ローカルポート
まず通常のプロキシモードが正常に動作することを確認してから、TUNを有効にします。TUNを有効にしても、サブスクリプションの不具合、誤ったVLESSパラメーター、不一致のTLS設定は解決しません。ノード自体が接続できない状態で仮想NICを追加すると、より多くのアプリに影響が広がるだけです。
- 接続先サーバーを確認：サーバー一覧から、接続できることが分かっている項目を選び、現在のサーバーに設定します。サブスクリプションの更新が完了したのは一覧の取得に成功したというだけで、サーバーに接続できることを意味しません。
- ローカルの待ち受けを確認：「設定」→「パラメーター設定」でローカルの待ち受けポートと関連項目を確認します。画面のバージョンによって分類名が異なる場合があるため、現在表示されている項目を基準にしてください。
- TUNを動かすコアを確認：v2rayNはクライアントであり、単一のコアではありません。TUN機能は通常sing-boxが処理します。通常のプロキシにXrayを使っていても、TUNのインバウンドがXrayによって作成されるとは限りません。必要なコアファイルがそろっていることを確認し、起動ログで実際のプロセス情報を確認してください。
- 現在のネットワーク環境を記録：使用中のVPN、社内ネットワークツール、仮想マシンのネットワークアダプターを控えておきます。初回の検証では、デフォルトルートを変更するソフトを複数同時に起動しないでください。
要点：再現可能なプロキシの基準を先に作る
まずローカルプロキシを明示したリクエストでノードを検証し、次にプロキシを指定しない同じリクエストでTUNを検証します。同じ宛先を使って2回テストすれば、「ノードに接続できない」のか「通信がTUNに入っていない」のかを切り分けられます。
3. Windowsでの有効化手順：管理者権限で起動し、ログを確認
初回設定は、できるだけPCの前で行ってください。リモートデスクトップだけに頼ってルートを変更するのは避けましょう。ネットワークが切断されると、リモート接続も切れる可能性があります。以下は、メイン画面にTUNスイッチがあるv2rayNでの操作手順です。現在のバージョンで設定場所が異なる場合は、パラメーター設定のTUN関連画面を確認してください。画面上の名称を、バージョンを問わず共通の手順とみなさないでください。
- 設定を保存して、クライアントを終了します。まずTUNを無効にし、タスクトレイのメニューからv2rayNを終了します。古いプロセスが待ち受けポートを使用したり、実行状態を保持したりするのを防ぎます。
- 管理者として再起動します。v2rayNのプログラムを右クリックし、Windowsの「管理者として実行」を選択してシステムの許可を与えます。現在のインストール方法で正式にサポートされている昇格手段がある場合も、許可が完了していることを確認してください。
- 接続先ノードとルーティングモードを選択します。動作確認済みのノードを使います。内容を把握しているルールセットを使い、初回テストでは見知らぬルールセットを同時に読み込まないでください。
- テストのためにシステムプロキシを解除します。メイン画面またはタスクトレイのシステムプロキシ項目から、システムプロキシを解除します。ブラウザーがシステムプロキシ経由でアクセスできてしまい、TUNが通信を取り込んでいない問題を見落とすのを防ぐためです。すべての環境で必須の操作ではありません。
- メイン画面のTUNスイッチを有効にします。コアの起動を待ち、インターフェースの作成、ルートの設定、起動失敗に関するログを確認します。スイッチがオンになっても、クライアントに状態が記録されたというだけで、通信経路が使えることの証明にはなりません。
- インターフェースを確認し、新しいリクエストを送ります。Windowsのネットワークアダプター一覧に仮想インターフェースが追加されていることを確認してから、TUNで通信を取り込みたいアプリを起動します。すでに確立済みの長時間接続は初回の検証に適しません。いったん切断してから再接続してください。
管理者権限で解決できるのは、インターフェースやルートの設定権限の問題です。サーバー側がUDPに対応するかどうかは変わらず、すべてのプロトコルパラメーターが自動的に互換になるわけでもありません。ログに未対応の項目が表示された場合は、権限設定を重ねるのではなく、クライアントが生成した設定と対応するコアの組み合わせを確認してください。
4. 通信が取り込まれているか確認：ブラウザーだけで判断しない
以下のコマンドはWindows PowerShellで実行します。1つ目のコマンドは、ローカルのSOCKS待ち受けが127.0.0.1:10808であることを前提としています。実際のポートが異なる場合は必ず置き換えてください。curl.exeを使うのは、実行ファイルを明示し、コマンドエイリアスによる引数の解釈の違いを避けるためです。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/
Get-NetAdapter
route print
Resolve-DnsName example.com- 1つ目のコマンドでノードの基準を確認：
socks5hを指定すると、宛先ドメインの名前解決をSOCKSプロキシ側に任せます。ローカルで別のプロキシプロトコルだけを待ち受けている場合は、実際の待ち受け方式に合わせてコマンドを変更してください。この結果だけでノードが使えないと判断しないでください。 - 2つ目のコマンドでアプリの明示プロキシを除外：
--noproxy "*"を指定すると、curlはアプリケーション層のプロキシ設定を使いません。ただし、OSのTUNルートを迂回するわけではありません。TUNを有効にした状態で、リクエストが完了するか確認します。 - 3つ目と4つ目のコマンドでシステム状態を確認：仮想インターフェースの有無とルートの変化を確認します。TUNはデフォルトルートの分割など、ほかの方法で通信を取り込むことがあります。元のデフォルトルートが残っているという理由だけで失敗と判断しないでください。
- 5つ目のコマンドで名前解決を確認：現在のシステムでの名前解決結果またはエラーを確認できます。ブラウザー独自の暗号化DNSも同じ経路を使うとは限りません。
example.comはコマンド構文の例にすぎません。対象に直接接続できる場合、リクエストが成功してもプロキシ経由の出力が選ばれた証拠にはなりません。そのリクエストの宛先、時刻、コアのルーティングログを照合し、どのルールに一致したかを確認してください。必要に応じて、TUNを無効にした状態と有効にした状態で、同じ検証用の宛先に接続して比較します。
要点：TUNによる通信の取り込みとプロキシ経由の接続を個別に確認
まず新しい接続がTUNに入っていることを確認し、次にログで想定した出力先が選ばれていることを確認します。直接接続ルールに一致した場合、外部IPアドレスが変わらなくても、仮想NICが動作していないとは限りません。
5. ルーティング、DNS、UDP：混同しやすい3つのポイント
TUNで通信を取り込んだ後も、接続ごとにルールとの照合が必要です。LANのアドレス、必要なローカルサービス、プロキシサーバーへの接続には、適切な直接接続または除外ルートを設定します。プリンターに接続できなくなったり、プロキシの出口への接続が再びTUNに送られてループしたりするのを防ぐためです。クライアントが生成する対応済みの設定を優先し、別の環境向けの項目を現在の設定ファイルにそのまま追加しないでください。
| 確認する項目 | 具体的なリスク | 確認・対処のポイント |
|---|---|---|
| LANアドレス | ルーターの管理画面、共有フォルダー、プリンターへの通信が誤ってプロキシに送られる | 実際のLANサブネットを確認します。例：192.168.1.0/24。これは例であり、PCのネットワーク情報の代わりにはなりません。 |
| DNSリクエスト | 名前解決とアクセスの経路が一致せず、タイムアウトや現在の出口に適さないアドレスが返る | TUNのDNS設定、リゾルバーへの到達性、ブラウザー独自の暗号化DNSの使用状況を確認 |
| IPv6 | IPv4だけを処理すると、一部の接続がIPv6経由で外部に出る可能性がある | IPv6アドレス、ルート、TUNの対応範囲も確認します。IPv4の宛先を1つテストするだけでは不十分です。 |
| UDP | Webページは開くが、音声通話、ゲーム、QUIC接続に失敗する | TUN、選択した出力先、サーバーまでの経路が、対象のUDP通信に対応しているか確認 |
DNSの横取りは、従来型のDNSリクエストをコアのリゾルバーに送る場合によく使われます。ただし、宛先ポート53だけを確認しても、DoHなどの暗号化DNSは把握できません。アプリがHTTPSで独自に名前解決している場合、その通信は通常のHTTPSと同じように見えます。調査では「どこが名前解決を行うか」と「DNSリクエストがどこから送信されるか」を分けて記録してください。
設定形式も混同しないようにしてください。TUNはクライアントがコアの機能を利用するためのモードであり、V2Ray JSONの共通トップレベル項目としてtunがあるわけではありません。sing-box、Xray、V2Flyでは設定形式と対応範囲が異なります。設定を手動で管理する前に、ログで実際に読み込まれているコアを確認し、そのコアに対応する設定項目を調べてください。基本構造はJSON設定マニュアルを参照できますが、異なるコア向けの設定をそのまま貼り付けないでください。
- ルーティングを検証するときは、一度に変更するルールを1つに絞り、一致した出力先を記録します。
- DNSを検証するときは、クエリを再実行してください。古いキャッシュや既存の接続が設定変更を見えにくくすることがあります。
- UDPを検証するときは、対象アプリで実際に通信してください。HTTPリクエストの成功は、音声通話やゲームの検証にはなりません。
6. よくあるトラブルと無効化後の復旧確認
コアの起動、通信経路、個別アプリの順に確認します。問題が発生した時刻の前後のログを保存し、権限エラー、インターフェース作成の失敗、アドレスの競合、DNSのタイムアウト、出力先への接続エラーに注目してください。ログを共有する前に、サブスクリプションのURL、認証情報などの機密情報を削除してください。
TUNをオンにしても、すぐにオフに戻る場合
まずコアの起動ログを確認します。権限不足の場合はクライアントを終了し、管理者として再起動してください。設定項目のエラーの場合は、対応するコアと生成設定を確認します。アドレスやインターフェースの競合が表示された場合は、ほかのトンネルをいったん停止してから再試行してください。インターフェースの作成を何度も繰り返さないでください。
有効にした後、どのサイトにもアクセスできない場合は、まずDNSを変更するべきですか？
まずTUNを無効にして元のネットワークが復旧することを確認し、ローカルプロキシを明示した方法で現在のノードをテストします。ノードが使えることを確認したら、TUNのログとルートを調べ、最後にDNSを確認します。ドメインの名前解決がタイムアウトする場合は、リゾルバーのアドレスと対応する出力先を確認してください。ノード、ルーティング、DNSを一度に変更しないでください。
Webは見られるのに、ゲームや音声通話が接続できない場合
まずアプリを完全に終了してから再接続し、以前のセッションを使い続けないようにします。次に、そのアプリが直接接続ルールに一致していないか、サーバーまでの経路がUDPに対応しているか、ファイアウォールが該当プロセスをブロックしていないか確認してください。TUNがパケットを受信できても、接続先がそのアプリに必要な通信を転送できるとは限りません。
v2rayNを終了した後もネットワークが正常に戻らない場合
まずクライアントを再起動し、TUNを正常に無効にしてから、システムプロキシを解除して終了します。Windowsのプロキシ設定がローカルの待ち受けアドレスを指していないか確認し、仮想インターフェースとルートの状態も確認してください。それでも復旧しない場合は、作業内容を保存してからPCを再起動します。企業管理下の端末では、アダプターをまとめて削除せず、先に管理者へ相談してください。
安定して使うために維持するものはシンプルです。動作確認済みのノード、内容を把握したルール、使えるDNS設定、そしてTUNを正常に無効化する手順をそろえてください。クライアントやコアの更新後は、同じテストを再実行するほうがスイッチの状態だけを見るより確実です。ブラウザーだけにプロキシが必要なら、通常はシステムプロキシで十分です。プロキシ設定に従わないアプリがある場合にTUNを有効にしてください。