ブラウザーは接続できるのにデスクトップアプリがつながらない場合は、まずアプリがシステムプロキシに対応しているか確認し、それからTUNを検討しましょう。この記事ではWindows版v2rayNを例に、権限の準備、仮想NICによる通信の取り込み、ルーティングとDNSの関係、設定後の確認方法と元に戻す手順を説明します。macOSは権限設定やネットワーク拡張の仕組みが異なるため、各プラットフォームのビルドに対応した方法を使い、Windowsの管理者権限での操作をそのまま適用しないでください。
システムプロキシとTUN：通信を取り込む位置の違い
システムプロキシは、アプリにローカルプロキシの接続先を提供します。システムプロキシ設定を参照するブラウザーやデスクトップアプリは通信をそこへ送りますが、独自に接続したり、個別のネットワーク設定を使ったりするアプリは、そのまま直接通信する場合があります。つまり、「システムプロキシを設定した」だけでは、PC上のすべてのアプリがプロキシ経由になるわけではありません。
TUNはOS内にレイヤー3の仮想ネットワークインターフェースを作成し、ルーティングによって条件に合うIPパケットを処理エンジンへ送ります。アプリがHTTPプロキシやSOCKSプロキシに対応していなくても、通信を取り込める場合があります。ここでいう「全通信」とは取り込み対象の範囲を指し、すべての接続がリモートノードへ送られるという意味ではありません。最終的に直接接続、プロキシ経由、ブロックのどれになるかはルールで決まります。
v2rayNは管理用のインターフェースです。プロトコル接続とTUNのデータ処理は、実際に起動しているコアとその設定に依存します。ビルドによって連携する処理方式が異なる場合があるため、画面に表示されたノードの種類だけでTUNのバックエンドを判断することはできません。VLESSとVMessはプロキシプロトコル、TUNは通信の入口です。互いに置き換えるものではなく、TUNを有効にするためにサブスクリプション内の全ノードを別のプロトコルに変更する必要もありません。
有効化前の準備：ノード、ポート、権限を確認
まずTUNを無効にした状態で、ノードが正常に動作することを確認します。通常のプロキシ接続に失敗している場合、TUNを有効にしても問題の範囲が広がるだけで、無効なサブスクリプション、誤ったサーバーアドレス、セキュリティ層の設定不一致は解決しません。現在のルーティングとDNS設定を画面キャプチャで保存し、ローカルの待ち受けアドレスも控えておくと、元に戻して再テストしやすくなります。
- ノードを確認：インポート済みのノードを選んで使用中のサーバーに設定し、ブラウザーで実際にアクセスできるか確認します。遅延テストが一度成功しただけでは、Webサイト、DNS、UDPが使えるとは限りません。
- 待ち受けポートを確認：「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。項目の分類はバージョンによって異なります。PC上のプロキシポートとサーバー側のポートを混同しないでください。また、TUNを使うために待ち受けアドレスをすべてのネットワークインターフェースに変更する必要はありません。
- 権限を準備：Windowsでは、仮想NICの作成やルートの変更に管理者権限が必要になることがあります。v2rayNを通常の方法で終了し、プログラムを右クリックして「管理者として実行」を選び、システムの確認に従って許可します。
- 競合を避ける：初回テストでは、デフォルトルートを変更するほかのトンネルや通信最適化ツールを一時停止します。会社の端末がネットワークポリシーで管理されている場合は、事前に許可を得てください。エンドポイント保護を回避しようとしないでください。
ローカルポートに全環境共通の指定値はありません。上記の10808はテスト例です。現在の設定で別の値を使っている場合は、コマンド、アプリ内プロキシ設定、ログの確認に実際のポートを指定してください。通常、PC上のTUNで通信を取り込むために、ルーターの受信ポートを開放する必要はありません。
v2rayNでTUNを有効にする：順番に一つずつ操作
バージョンによってスイッチの表示は「TUNを有効にする」や「TUNモード」など異なり、設定ページの項目も変更される場合があります。以下では機能ごとに説明します。特定バージョンのボタン位置を固定のものと考えず、メイン画面のTUNスイッチと「設定」内のTUN項目を探してください。
- 通常のプロキシ接続を基準にする。TUNを無効にし、現在のノードで実際にアクセスできるか確認します。失敗する場合は、ノードやサブスクリプションの問題を先に解決してください。
- 必要な権限で再起動する。Windowsでは管理者として実行し、ローカルポートを使用中の古いプロセスがバックグラウンドに残っていないか確認します。管理者権限にするのは1つのプロセスだけにし、プログラムを二重に起動しないでください。
- TUNの設定を確認する。「設定」を開き、使用中のバージョンにあるTUN設定ページへ進みます。初めて使う場合はネットワークスタック、MTU、インターフェースの各項目を既定値のままにし、自動ルーティングの設定が目的の通信範囲に合っているか確認します。複数の詳細項目を同時に変更しないでください。
- ルーティング方針を決める。目的に合ったルールモードを選び、必要なLAN向けの直接接続ルールを残します。プリンター、NAS、社内ネットワークにアクセスする場合は、該当するネットワーク範囲やドメインを特に確認してください。
- メイン画面でTUNを有効にする。コアのログを確認し、権限不足、設定の解析失敗、ポート競合などのエラーがないことを確認します。その後、システムに該当する仮想インターフェースとルートが作成されているか調べます。
- TUN単独で動作を確認する。TUNの起動後、v2rayNのシステムプロキシを解除または無効にし、もともとシステムプロキシを使わないアプリでテストします。通常のプロキシ接続の成功をTUNの成功と取り違えないようにしてください。
有効化直後にネットワークが切れた場合は、まずTUNを無効にしてください。ノード、ネットワークスタック、DNSモードを立て続けに切り替えるのは避けます。基準の設定に戻して最初のエラーを確認し、そのうえで次の変更を決めましょう。仮想NICが存在していても、インターフェースの作成に一度成功したことを示すだけで、処理エンジンが動作中とは限りません。
DNSとルーティング：通信経路と名前解決経路を確認
アプリがドメイン名へアクセスすると、通常は先にDNSで名前を解決し、その後、宛先IPに接続します。TUNが接続を取り込んでも、すべてのDNS問い合わせが同じ経路を通るとは限りません。従来型DNSではUDPまたはTCPの53番ポートが一般的ですが、アプリ内の暗号化DNSはHTTPS経由で送信されることがあります。53番ポートの通信を処理しただけで、ブラウザーの名前解決経路も変わったとは判断できません。
DNSの確認項目
- システムの名前解決
- 現在のネットワークインターフェースのDNS参照先と、クライアント側の取り込み設定を確認
- 上流サーバーへの到達性
- DNSサーバーへの接続に、まだ確立していないプロキシが必要か確認
- アプリ側の名前解決
- ブラウザーのセキュアDNSは個別に確認し、システム設定に従うと決めつけない
- キャッシュの影響
- 変更後は新しい接続で再試行し、必要に応じてシステムキャッシュを消去
システムDNS、ブラウザーの名前解決、クライアント側DNSを一度に変更しないでください。一か所ずつ変更して結果を確認します。
ルーティングの確認項目
- LAN
- 実際のネットワーク範囲に合わせて直接接続を残す（例：192.168.1.0/24）
- リモート接続
- ノードサーバーへの接続が再びTUNに取り込まれるループを防ぐ
- IPv6
- IPv4だけでなく、通信の取り込み範囲と振り分けルールを確認
- ルールの優先順位
- 先行するルールが対象の接続に先に一致していないか確認
ネットワーク範囲の例はすべての環境に適用できる設定ではありません。社内ネットワークなどで別のアドレスを使っている場合は、実際のルートとネットワーク設計に従ってください。
リモートノードのドメイン名を使う場合は、DNSのループにも注意が必要です。DNSサーバーへの接続にプロキシが必要なのに、そのプロキシを確立するには先にノードのドメイン名を解決しなければならない場合、起動時に処理が止まることがあります。クライアントが用意する適切な既定設定を使い、起動に必要なドメイン名を先に解決できるようにしてください。すべてのDNS問い合わせを特定の送信先へ無条件に流すのは避けましょう。
設定によってはFakeDNSやfake-ipなどの仕組みを使い、ドメイン名を一時的に合成アドレスへ割り当て、処理エンジン側で宛先を元に戻します。この種のアドレスには、ほかのツールから直接アクセスできないことがあります。モードを切り替えた後、古いDNSキャッシュが一時的な不具合を引き起こす場合もあります。現在のコアが対応しているか、設定とどう関係するか確認できるまでは、チュートリアルに載っているという理由だけで有効にしないでください。
- ドメイン名を解決できない：ノードを変える前に、DNS問い合わせ、上流サーバーへの到達性、キャッシュを確認。
- 名前解決はできるが接続がタイムアウトする：ルーティングルール、ノードの送信経路、宛先プロトコルへの対応を確認。
- LAN内の名前だけ解決できない：社内DNS、検索ドメイン、LAN向けの直接接続ルールを確認。
- 一部のアプリだけ不調：アプリ独自のプロキシ、暗号化DNS、使用するネットワークインターフェースの指定を確認。
有効化後の確認：スイッチの状態だけで判断しない
確認するポイントは3つです。通常のプロキシが使えるか、TUNが対象アプリの接続を取り込んでいるか、その接続が想定した送信先ルールに一致しているかを調べます。まずシステムプロキシを無効にした状態で対象アプリをテストし、ログとあわせて判断してください。ルールで直接接続が指定されている場合、外部から見えるIPアドレスが変わらなくても正常なことがあります。
| 確認項目 | 操作方法 | 確認ポイント |
|---|---|---|
| 通常のプロキシ接続を確認 | TUNを無効にし、明示的にローカルプロキシを指定して同じ宛先へアクセス | まずノード、待ち受けポート、リモート接続の問題を切り分ける |
| TUN単独での通信取り込み | TUNを有効にしてシステムプロキシを無効にし、同じ宛先へアクセス | ログに対象の接続と想定した送信先が記録されているか確認 |
| LANへのアクセス | アクセス可能と確認済みのルーター管理画面または社内サービスに接続 | 広範囲なルールがLAN向けの直接接続ルールを上書きしていないか確認 |
| DNSとデュアルスタック | ドメイン名の解決結果を確認し、IPv4とIPv6の接続をそれぞれ調べる | 一方のアドレスファミリーだけを確認して、すべて正常と判断しない |
| UDPを使うアプリ | 実際にUDPを使う機能をテスト | TCPのWebページが表示できても、UDPの通信が可能とは限らない |
Windowsでは、以下のコマンドでルートと名前解決の結果を確認できます。プロキシのテストコマンドを使うには、ローカルの10808番ポートでSOCKSサービスが実際に待ち受けている必要があります。ポートやプロトコルが異なる場合は、現在の待ち受け設定に合わせてください。例に使った宛先はコマンドの書き方を示すものです。一度アクセスできただけでネットワーク全体を診断できるわけではありません。
route print
ipconfig /all
nslookup example.com
curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/
curl.exe --noproxy "*" https://example.com/2つ目のcurlコマンドで迂回するのはアプリケーション層のプロキシ設定であり、システムのルーティングではありません。そのため、引き続きTUNを通る可能性があります。物理ネットワークの直接接続を確認するには、TUNを無効にしてから実行してください。ログを共有する際は、サブスクリプションURL、アカウント情報、ノードの認証情報を伏せてください。診断に必要なのは通常、エラーの種類、対象の接続、適用されたルールであり、設定全体ではありません。
よくある質問とネットワークの復旧
スイッチをオンにするとすぐオフになる場合、まずどこを確認すればよいですか？
起動ログの最初のエラーを確認してください。Windowsでは古いプロセスを終了してから、管理者として実行します。それでも失敗する場合は、権限の拒否、仮想インターフェースの作成失敗、設定の解析エラーを切り分けます。原因調査の代わりに、システム保護を恒常的に無効にしないでください。
ブラウザーは使えるのに、ゲームや音声通話がつながらないのはなぜですか？
まず対象の接続がTUNに取り込まれ、想定したルールに一致しているか確認します。次に、ノードとサーバー側が該当するUDP転送に対応しているか調べてください。Webページの閲覧で主に確認できるのはTCPです。音声通話やゲームで使われるUDP経路が正常とは限りません。また、ランチャーと実際のアプリ本体が別の宛先へ接続する場合もあります。
有効化後、プリンターや社内サービスが見つからなくなった場合は？
まずTUNを無効にし、サービスに元からアクセスできていたか確認します。その後、実際に使っているネットワーク範囲、社内DNS、直接接続ルールを調べます。サービスがブロードキャストやマルチキャストに依存している場合、公衆ネットワーク向けのプロキシルールを追加しても解決しません。必要に応じて、クライアントが対応する方法で該当インターフェースやネットワーク範囲を除外してください。
TUNを無効にしてもインターネットに接続できない場合は？
まず停止したローカルポートを参照しているシステムプロキシを解除し、クライアントを通常の方法で終了してください。システムのDNSとルーティングが元に戻っているか確認します。WindowsでDNSを変更した後は、ipconfig /flushdnsを実行してキャッシュを消去できます。それでも不調が続く場合は、ネットワークに再接続するかシステムを再起動してください。仮想NICをすべて削除するのは避けましょう。
安定して使うには、ネットワークスタックを頻繁に切り替えるより、動作確認済みの設定を記録しておくと役立ちます。使用中のノード、ルーティングモード、DNSの方式、システムプロキシの状態、ほかのトンネルソフトの有無を記録してください。問題が起きたら記録をもとに一つずつ戻すと、すべての設定を一度にリセットするより原因を特定しやすくなります。
- 一時停止：TUNを無効にし、仮想ルートが削除されたことを確認してから、通常のシステムプロキシを使うか判断します。
- 完全に終了：不要になったシステムプロキシを解除してからv2rayNを終了し、アプリが停止済みのローカルポートへ接続し続けないようにします。
- 調査を続ける：個人情報を伏せたエラーログを保存し、一度に変更する設定は一つだけにして、同じ宛先で再テストします。