ブラウザーは接続できるのに、コマンドラインツールやほかのアプリは直接接続してしまう場合、まずシステムプロキシとTUNで処理できる通信の範囲を確認しましょう。この記事ではWindows版v2rayNを例に、「ノードの確認、権限の取得、仮想ネットワークアダプターの有効化、ルーティングとDNSの確認、テストと復旧」の順で説明します。プロキシが必要な通信を適切な出口に流しつつ、LANへのアクセスも維持することがポイントです。「通信を処理する」ことと「すべての接続をプロキシ経由にする」ことは同じではありません。
システムプロキシとTUN：入口は異なり、出口はルーティングで決まる
システムプロキシは、OSにローカルプロキシのアドレスを登録する仕組みです。この設定に従うアプリは、v2rayNのローカル待ち受けポートにリクエストを送ります。一方、システムプロキシを無視するプログラムは、自ら接続します。ブラウザーでWebサイトを開けても、ターミナルツールやゲーム、バックグラウンドサービスもプロキシを経由しているとは限りません。
TUNはネットワーク層の入口です。クライアントが仮想ネットワークインターフェースを作成し、システムルーティングによって条件に一致するIP通信をそのインターフェースへ流します。その後、対応するコアがTCP、UDP、DNSや出口の選択を処理します。通常、アプリ側でプロキシアドレスを設定する必要はありません。ただし、既存のVPN、特定のネットワークアダプターにバインドされたアプリ、より優先度の高いルートによって、通信の処理結果が変わる場合があります。
システムプロキシ：まず基本動作を確認
おすすめ設定範囲が狭く、サブスクリプションのノード、ローカル待ち受け、ブラウザーでのアクセスを順に確認するのに適しています。あくまでトラブルシューティングの出発点であり、すべての環境における最終的な解決策ではありません。
適した用途：ブラウザーが中心の環境、HTTPまたはSOCKSプロキシに対応したアプリ
TUN：プロキシ設定を参照しないアプリの通信を処理
仮想ネットワークアダプターとルーティングで通信を受け取ります。権限、DNS、UDP、LAN向けの例外も確認が必要です。スイッチがオンかどうかだけでは判断できません。
適した用途：ターミナルツール、一部のデスクトップアプリ、通信を一元的に振り分けたい環境
選び方：入口を決めてからルーティング方針を選ぶ
システムプロキシで要件を満たせるなら、まずはそのまま使いましょう。特定のアプリがプロキシを迂回する場合にTUNを有効にします。TUNを有効にした後も通信の振り分けは可能です。該当するグローバルプロキシルールを選んだ場合に限り、一致した通信がプロキシ出口を経由します。
有効化前の確認：ノード、権限、3種類のポート
まずv2rayNでサブスクリプションを更新し、ノードを選択してアクティブサーバーに設定します。システムプロキシ経由で、実際に使うWebサイトへアクセスしてください。ノードが接続を確立できるだけでなく、実際のリクエストを完了できることを確認します。遅延テストに成功しても、すべての接続先へアクセスできるとは限らず、UDPが正常とも限りません。
以下の数値はポートの用途を見分けるための例です。設定をすべて同じ値にそろえる必要はありません。v2rayNのローカル待ち受けポートは「設定」→「パラメーター設定」に表示される値を確認してください。サブスクリプションノードのリモートポートはサービス提供元が決めるため、例に合わせて変更しないでください。
- 管理者権限：Windowsで仮想ネットワークアダプターを作成したり、ルートを追加したりするには、通常、管理者権限が必要です。v2rayNを終了し、「管理者として実行」で起動し直して、システムの許可確認に応じてください。
- 実行コンポーネント：TUNに必要なコンポーネントがインストールパッケージに含まれているか確認します。一般的なv2rayNのバージョンでは、sing-boxがTUNの入口を担います。ノードでXrayを使用していても、TUNが必ずXrayによって直接作成されるわけではありません。
- ネットワークの競合：ほかのVPNや、同種の仮想ネットワークアダプターによる通信処理をいったん停止します。最初から複数のデフォルトルートを重ねて、どのプログラムが通信を受け取っているか推測するのは避けてください。
- 復旧用の記録：現在のシステムプロキシの状態、ルーティングモード、DNS設定を記録します。初回テストでは変更する設定を1組に絞ると、元に戻しやすくなります。
v2rayNでTUNを有効にする：順番に設定して動作を確認
通常のプロキシが使えることを確認してから、TUNを有効にします。初回の切り分けではシステムプロキシを解除し、テスト対象のアプリがTUNだけを入口として使う状態にします。システムプロキシが有効なままでは、仮想ネットワークアダプターが通信を正しく処理していると誤認するおそれがあります。これはトラブルシューティングの方法であり、2つの入口を常に併用できないという意味ではありません。
- 終了して管理者権限で起動：タスクトレイからv2rayNを終了し、プログラムを右クリックして「管理者として実行」を選びます。メインウィンドウを閉じただけでは、バックグラウンドプロセスが残ることがあります。
- アクティブノードを確認：サーバー一覧でアクティブサーバーが変わっていないことを確認します。サブスクリプションを追加し直す場合は、「サブスクリプショングループ」→「サブスクリプショングループの設定」でURLを保存し、更新を実行します。
- ローカル設定を確認：「設定」→「パラメーター設定」を開き、ローカル待ち受けポートを記録します。使用中のバージョンにTUN設定画面がある場合は、まずデフォルトのスタックとMTUを使い、実験的な設定を一度に複数変更しないでください。
- システムプロキシを解除：メイン画面またはタスクトレイの「システムプロキシ」メニューから「システムプロキシを解除」を選びます。テスト対象のアプリに、個別のプロキシアドレスやプロキシ環境変数が設定されていないことも確認してください。
- TUNを有効化：メイン画面の「TUNを有効にする」スイッチをオンにします。使用中のバージョンで設定メニューに項目がある場合は、そのバージョンに表示されるTUNの設定を使ってください。ログにネットワークアダプターの作成、コアの起動、ルート設定のエラーがないか確認します。
- 実際のリクエストを確認：アプリ側にプロキシを設定していないプログラムで接続先にアクセスします。ルーティング、DNS、アクセスログを併せて、通信の出口を確認してください。その後、システムプロキシを併用するか判断します。
PowerShellでは、次の2つの読み取り専用コマンドでネットワークアダプターとIPv4ルートを確認できます。システム設定は変更されません。仮想インターフェース名に決まった文字列が含まれるとは限らないため、有効化前後の変化を比べてください。TUNの実装によっては、既存のデフォルトルートを置き換えず、より具体的な2つのルートを使う場合があります。
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
Sort-Object DestinationPrefix, RouteMetric |
Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric仮想インターフェースが表示されるのは最初の段階にすぎません。ログ上でインターフェースが正常でも、アプリのリクエストが対応する処理経路に入らない場合は、ルートの優先順位、アプリが物理ネットワークアダプターにバインドされていないか、ルールで通信が直接接続に設定されていないかを確認します。
ルーティングの振り分け：LANを維持し、プロキシ接続のループを防ぐ
「TUNで全通信を処理する」は入口の範囲を表し、「グローバルプロキシ」は出口の方針を表します。TUNを有効にしても、家庭内ストレージ、プリンター、イントラネットサービスは直接接続にできます。それ以外の接続先は、ドメイン名、IPアドレス、ルールセットに応じてプロキシへ振り分けます。すべての接続先をリモート側へ強制的に送ると、かえってLAN機器にアクセスできなくなることがあります。
設定方針：日常の振り分けと一時的な診断を分ける
日常の振り分け
- 必要に応じて、LANやプライベートアドレスは直接接続にする。
- プロキシが必要な接続先は、プロキシ出口に明示的に振り分ける。
- 直接接続用DNSとプロキシ用DNSを分けて設定する。
- ノードサーバーへの接続で、ループを防ぐ仕組みを維持する。
一時的な診断
- システムプロキシを解除し、TUNの入口を切り分ける。
- テスト対象に一時的なプロキシルールを設定する。
- ログでルールの一致状況と出口を確認する。
- テスト後は日常の振り分け設定に戻す。
まず指定した接続先がプロキシ経由で通信できることを確認してから、ルールの範囲を広げましょう。出口確認を一度行っただけで、すべてのアプリが正常だと判断しないでください。
| 接続先またはアドレス | 設定方針 | 理由 |
|---|---|---|
192.168.0.0/16 | LANの要件に応じて直接接続 | 家庭用ルーター、プリンター、ストレージ機器などで一般的です。 |
10.0.0.0/8 | 社内ネットワークまたはVPNを先に確認 | プライベートネットワークが企業のトンネル経由で提供されている場合があります。安易に物理ネットワークアダプター経由へ変更しないでください。 |
| 現在のノードサーバー | 適切な物理ネットワーク出口または除外ルールを維持 | プロキシ自身の通信が同じトンネルに再度送られると、接続ループが発生します。 |
| プロキシが必要な通信先 | プロキシ出口に明示的に振り分ける | 優先順位の高い直接接続ルールに先に一致するのを防ぎます。 |
VMessとVLESSはノードのプロトコルであり、「仮想ネットワークアダプターを経由するか」を切り替える設定ではありません。TUNでUDPを受け取っても、その後の通信経路がUDPの転送に対応している必要があります。ゲームや音声通話アプリが動作しない場合は、仮想ネットワークアダプターを何度も切り替えるのではなく、ノードのプロトコル、サーバー側の設定、ファイアウォールを確認してください。
DNSの連携：名前解決と通信経路を併せて確認
DNSはドメイン名をどのアドレスに変換するかを決め、ルーティングはその後の接続がどこから出ていくかを決めます。リモートDNSのアドレスを設定しただけで、問い合わせがプロキシを経由するとは限りません。Webサイトの出口が変わったように見えても、ブラウザー独自の暗号化DNS、システムDNS、ほかのアプリの名前解決が同じ経路を使っているとは限りません。
- 直接接続する通信：現在のネットワークに合ったリゾルバーを使い、問い合わせ経路を直接接続の方針と一致させます。イントラネットのドメイン名にはルーターや企業のDNSが必要な場合があり、パブリックDNSでは解決できないことがあります。
- プロキシ経由の通信：関連するDNSクエリもプロキシ出口経由で送信します。DoHを使う場合は、HTTPSアドレスを設定するだけでなく、リゾルバーへの接続が実際にどの出口を通るか確認してください。
- 起動時の名前解決：ノードやDoHサーバー自体がドメイン名を使う場合、初期の名前解決ができる状態にします。「プロキシを使うにはDNSが必要だが、DNSにはプロキシが必要」という循環依存を避けてください。
- DNSのリダイレクト：TUNに入った従来型のDNSクエリをコアに処理させます。対象となるDNS通信が主な範囲であり、アプリが独自に確立する暗号化DNS接続をすべて自動的に処理するものではありません。
- FakeDNS：仮想アドレスとの対応付けによってドメイン名の情報を保持します。対応した入口とルールの両方で処理する必要があります。TUNの初回設定で同時に有効にする必要はありません。有効にした場合は、終了後に残ったキャッシュを適切に削除してください。
たとえば、アプリがLAN内のルーターの53番ポートへドメイン名を問い合わせ、プライベートアドレス向けのルールでその通信が直接接続になると、DNSクエリがプロキシを迂回することがあります。これが想定外の漏えいに当たるかどうかは、通信の振り分け方針に照らして判断してください。イントラネットのドメイン名をLAN内のDNSで解決するのは通常の動作ですが、プロキシ対象の名前解決にローカルネットワークが使われている場合は、詳しく確認する価値があります。
対処法：名前解決の失敗と接続の失敗を切り分ける
まずログで接続先のアドレスを取得できているか確認し、次に接続がどの出口に振り分けられたかを見ます。名前解決できない場合はDNSを調べます。アドレス取得後に接続がタイムアウトする場合は、ルール、ノード、通信経路を調べてください。異なる2つの問題をどちらもTUNが原因だと決めつけないようにしましょう。
起動できない、ネットに接続できない、一部のアプリだけ通信できない：症状別の対処
設定を変える前に、エラー情報を保存してください。ログの「権限不足」「インターフェースの作成失敗」「ポートの競合」「接続タイムアウト」は、それぞれ異なる原因を示します。ノード、DNS、MTU、ネットワークスタックを一度に変更すると、原因を特定する手がかりが失われます。
TUNを有効にすると「ネットワークアダプターの作成に失敗しました」と表示される場合は？
まずタスクトレイから完全に終了し、管理者として起動し直します。セキュリティソフトが関連コンポーネントをブロックしていないか、インストールパッケージに必要なコンポーネントが含まれているか確認してください。それでも失敗する場合は、ログに記録された具体的なエラーを控えます。物理ネットワークアダプターを削除したり、すべてのルートを一括削除したりしないでください。
スイッチはオンなのに、どのWebサイトも開けない場合は？
まずTUNを無効にし、従来のシステムプロキシがまだ使えるか確認します。通常のプロキシが動作する場合は、TUNのログ、ノード接続のループ防止、DNSの起動時名前解決を重点的に確認してください。通常のプロキシも使えない場合は、ノードまたはネットワークの問題を優先して対処します。
Webページは見られるのに、ゲームや音声通話が接続できない場合は？
アプリがほかのネットワークアダプターにバインドされていないか確認し、UDPのリクエストがコアに届いているかログを確認します。ノードがUDPに対応しているか、サーバー側で転送が許可されているか、接続先が誤ったルールに一致していないかも調べてください。TCPのWebページが表示できても、UDPの動作確認にはなりません。
有効化後にプリンターやLAN内のストレージが見つからなくなった場合は？
まず、対象のプライベートネットワークに直接接続するルールがあるか確認します。ネットワークの検出にはブロードキャストやマルチキャストが必要な場合もあり、リモートプロキシだけで復旧できるとは限りません。まず機器の実際のLANアドレスにアクセスし、検出機能だけに問題があるのか判断してください。
TUNを無効にしてもインターネットに接続できない場合は？
まずシステムプロキシを解除し、仮想インターフェースとルートが削除されているか確認してから、DNSキャッシュをクリアします。プロセスの異常終了でネットワーク状態が残った場合は、作業中の内容を保存してからシステムを再起動してください。見覚えのないルート項目を手動で削除するのは避けましょう。
Windowsでは、ターミナルから次のコマンドを実行してDNSキャッシュをクリアできます。この操作で削除されるのはシステムキャッシュだけです。誤ったルートは修正されず、各アプリ独自のDNSキャッシュもすべて自動的に消えるわけではありません。必要に応じてブラウザーなどのテスト対象アプリを再起動してください。
ipconfig /flushdns動作確認と復旧：スイッチの状態だけで判断しない
継続して使える設定にするには、プロキシ対象へ接続できること、直接接続する対象が正常なこと、DNS経路が方針どおりであること、無効化後に元の状態へ戻せることを確認します。テストでは実際に使うアプリを選び、少なくともシステムプロキシを参照しないアプリを1つ含めてください。ブラウザーを繰り返し開くだけでは不十分です。
- 入口の確認：システムプロキシとアプリ側の手動プロキシを解除しても、指定したアプリからTUN経由でプロキシ対象へ接続できる。
- 出口の確認：出口確認とログを照合し、テスト対象が想定したルールに一致していることを確認します。振り分け先によって出口が異なっても問題ありません。
- LANの確認：ルーターの管理画面、ストレージ機器、業務に必要なイントラネットサービスにアクセスし、例外ルールが有効であることを確認します。
- DNSの確認：システムとアプリそれぞれの名前解決設定を確認します。検査結果が通信の振り分け方針と一致しているかを見て、リゾルバー名だけで判断しないでください。
- 復旧の確認：TUNを無効にし、通常のネットワーク接続が戻ることを確認してから、必要に応じてシステムプロキシを再設定します。復旧しない場合は、残ったネットワーク状態を先に解消してから、引き続き原因を調べてください。
TUNの役割は、クライアントが処理できる通信の範囲を広げることであり、あらゆるネットワーク制限を自動的に解消することではありません。入口、名前解決、ルール、出口の4つを順に確認すると、コアを何度も切り替えたり、サブスクリプションを繰り返しインポートしたりするより、原因を見つけやすくなります。基本的なサブスクリプションとシステムプロキシの設定は入門ガイドをご覧ください。ルーティングやDNSの仕組みを確認する場合は、ドキュメント全文をご参照ください。