この記事ではWindows版v2rayNを例に、システムプロキシは使えるものの、ターミナルや一部アプリがルールどおりに通信できない場合の設定方法を説明します。まずノードを確認し、管理者権限でTUNを有効化した後、通信の取り込み範囲、ルーティング、DNSを順に確認します。TUNは通信を処理経路へ渡す仕組みで、すべての接続がプロキシ経由になるわけではありません。macOSやLinuxでは、各OSの権限やネットワーク管理方法に合わせて設定してください。
TUN仮想NICとシステムプロキシの違い
システムプロキシは、対応アプリにローカルプロキシのアドレスを設定する方式です。ブラウザーでは通常利用できますが、一部のターミナルアプリやゲーム、自前で接続を確立するアプリは設定を参照しません。TUNはレイヤー3の仮想ネットワークインターフェースを作成し、システムルートを通じてIPパケットをローカルのネットワーク処理コンポーネントへ渡します。そのため、HTTPやSOCKSプロキシに対応していないアプリも幅広く扱えます。
「全通信を取り込む」は通信の入口の範囲を表し、「全通信をプロキシ経由にする」は出口の方針を表します。別々の設定です。TUNで受け取った接続も、ドメイン名や宛先IPなど、対応する条件に応じて直接接続、プロキシ経由、遮断に振り分けられます。LANやループバックアドレス、明示的に除外したルートはTUNを通らない場合もあります。スイッチがオンになっただけで、すべての通信が取り込まれたと判断しないでください。
| 比較項目 | システムプロキシ | TUNモード |
|---|---|---|
| 通信の入口 | アプリがローカルプロキシのポートに接続 | システムルートがIPパケットを仮想インターフェースへ送信 |
| アプリ側の要件 | システムプロキシに対応しているか、個別にプロキシを設定できること | 通常はアプリごとにプロキシアドレスを設定する必要がない |
| 必要な権限 | 現在のユーザーのプロキシ設定変更は、通常、昇格権限不要 | インターフェース作成やルート変更には、通常、昇格権限が必要 |
| UDPへの対応 | HTTPシステムプロキシでは通常のUDP通信を扱えない | TUNコンポーネント、プロトコル、サーバーの対応状況による |
| 確認ポイント | 待ち受けポート、アプリのプロキシ設定 | インターフェース、ルート、DNS、外向きの接続経路 |
有効化の前にノードとローカルポートを確認
まずTUNを無効にし、システムプロキシまたはアプリの手動プロキシ設定でノードをテストします。サブスクリプションを読み込めても、接続先に到達できるとは限りません。VMessやVLESSなどの接続パラメーター、トランスポート方式、TLS設定はサーバー側と一致させる必要があります。通常のプロキシ接続に失敗する場合は、先にノードを修正し、ノード側の問題と仮想NICの問題を切り分けてください。
ここに示すのはプロトコルで使われるポートとテスト例であり、性能測定値でも、v2rayNのデフォルト待ち受けポートの保証でもありません。「設定」→「パラメーター設定」でローカルの待ち受けポートを確認してください。画面の項目はバージョンによって異なります。対象ポートがHTTPプロキシを受け付けることを確認してから、以下のコマンドを実行してください。例では待ち受けアドレスを127.0.0.1、ポートを10808としています。
curl.exe --proxy http://127.0.0.1:10808 --head --connect-timeout 10 https://www.example.com/- HTTPレスポンスヘッダーが返れば、このリクエストのプロキシ経路が確立したことを示します。すべてのサイトやUDPが利用できるという意味ではありません。
- ローカルポートへの接続失敗が表示された場合は、コアが起動しているか、待ち受けポートが一致しているか、他のプロセスがポートを使用していないかを確認します。
- ハンドシェイクやリモート接続の失敗が表示された場合は、コアのログを確認し、ノード、システム時刻、サーバー側の設定を見直します。
- 現在のシステムプロキシ、ルーティングモード、DNS設定を記録します。ネットワークを制御する他のツールは終了し、元の状態に戻せるようにしておきます。
Windowsでv2rayNのTUNを有効にする手順
v2rayNは設定とプロセスを管理するインターフェースで、TUNの実際の通信処理は連携するコンポーネントが行います。スイッチの場所、ネットワークスタックの選択肢、起動方法はバージョンによって異なります。デスクトップ画面の項目をV2FlyやXray共通の設定フィールドとみなさないでください。現在のインストールパッケージに、そのバージョンで必要なTUNコンポーネントが含まれていることを確認してから、権限を昇格してください。
- 終了して管理者権限で起動します。通知領域からv2rayNを終了し、以前のプロセスが停止したことを確認します。プログラムまたはショートカットを右クリックし、「管理者として実行」を選択してください。現在のバージョンに管理者権限で再起動する機能がある場合は、それを使ってもかまいません。
- 利用可能なノードを選択します。サーバー一覧から通常のプロキシで接続確認済みのノードを選び、現在のルーティングモードを確認します。初回テストでは既存のルールを使い、ノード、DNS、ネットワークスタックを同時に変更しないでください。
- システムプロキシを解除します。メイン画面または通知領域のシステムプロキシメニューから「システムプロキシを解除」を選びます。入口が二重になることで確認項目が増えるのを避けるための手順であり、すべてのバージョンでTUN有効化に必須というわけではありません。
- TUNを有効にします。メイン画面で「Tunを有効にする」または同等のTUNスイッチを見つけてオンにします。画面によって大文字・小文字などの表記が異なる場合があります。項目が見つからない場合は、OS、インストールパッケージ、使用中のバージョンのドキュメントを確認してください。出所不明のネットワークアダプター用ドライバーはインストールしないでください。
- 起動ログを確認します。権限不足、インターフェース作成失敗、ルート設定失敗がないことを確認してください。その後、システムのネットワークインターフェースとルートを確認し、プロキシを指定せずにリクエストを送信します。
ルーティングとDNS：取り込んだ通信の経路を確認
安定した設定には、接続をどの出口へ振り分けるか、ドメイン名をどの経路で名前解決するか、という2点の確認が必要です。TUNで接続を取り込んだ後も、ローカルネットワークへのアクセスを維持し、プロキシサーバー自身の接続が再びプロキシ入口に入ってループしないよう、ルーティング方針を設定します。使用中のTUN方式に合わせてクライアントが生成した設定を優先し、別のコア用JSONを貼り付けないでください。
初回の通信取り込み設定
- システムプロキシ
- 解除して切り分けテスト
- TUNスイッチ
- 有効にした後、起動ログを確認
- ローカルアドレス
- ループバックとLANへのアクセスを維持
- プロキシノード
- 確認済みのノードをそのまま使用
クライアント操作の確認項目であり、インポート可能なコア設定フィールドではありません。
DNS確認の基本項目
- 従来型の問い合わせ
- UDP/TCP 53の処理経路を確認
- 暗号化DNS問い合わせ
- アプリ内のDoH設定を個別に確認
- 名前解決の出口
- 選択した経路からDNS上流へ接続できることを確認
- IPv6
- IPv6のルートと名前解決結果も確認
従来型DNSだけを取り込んでも、アプリ内の暗号化DNSが同じ方針で処理されるとは限りません。
LANアドレスは実際のネットワーク構成に合わせて設定してください。たとえば192.168.1.0/24は家庭用ルーターで使われることがありますが、企業ネットワークでは別の範囲が使われる場合があります。例のネットワークを1つ追加しただけで、すべての社内ネットワークが対象になると考えないでください。ルーティングテーブルを確認し、プリンター、ファイルサーバー、内部DNSの宛先範囲に合わせて設定します。
- ドメイン名ルールでは、名前情報がどこから得られるかを確認します。アプリが接続前に独自に名前解決することがあります。ドメイン名に基づくルールを使う場合は、現在のTUN方式でドメイン名情報をどのように保持・復元するか確認してください。すべての接続にドメイン名が付いてくるとは限りません。
- DNS上流は、確立できない接続に依存させないでください。プロキシノードのアドレス自体に名前解決が必要な場合、「ノードに接続してからでないとノードの名前を解決できない」という起動時の依存関係を避けてください。
- IPv4とIPv6を個別に確認します。Webサイトが表示できても、両方のアドレスファミリーが想定した経路を通っているとは限りません。IPv6の取り込みルートがないと、アプリの通信が別の出口へ流れる場合があります。
- ルールを変更したら再読み込みします。クライアントで設定を保存して再読み込みした後、新しい接続でテストしてください。既存の長時間接続は、変更前に確立した経路を使い続ける場合があります。
TUNの動作確認：インターフェース、ルート、実際の接続
タスクバーのアイコンや仮想NICの名前だけで判断しないでください。インターフェースが作成されていること、対象への経路が想定したルートを通ること、接続ログに正しい出力先が記録されていることの3点を照合します。インターフェース名はコンポーネントやバージョンによって異なるため、すべてのPCで同じ名前になるとは限りません。デフォルトルートより具体的なネットワーク範囲が使われる場合もあるので、0.0.0.0/0のルートだけを探さないでください。
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
curl.exe --noproxy "*" --head --connect-timeout 10 https://www.example.com/最初の3つのコマンドはPowerShellで実行します。最後のコマンドでは--noproxy "*"を指定してcurlの明示的なプロキシ設定を避け、システムルートにリクエストを渡します。TUNを回避する指定ではありません。リクエストに成功しても、確認できるのは対象に現在到達できることだけです。ログも確認し、直接接続とプロキシのどちらを通ったか判断してください。
| テスト対象 | 操作 | 判定基準 |
|---|---|---|
| プロキシを設定していないアプリ | アプリ個別のプロキシ設定を解除し、新しいリクエストを送信 | コアのログに該当する接続と想定した出力先が記録される |
| LAN上のサービス | 実際のゲートウェイ、プリンター、社内サイトにアクセス | ローカルサービスに接続でき、リモートプロキシへ誤送信されない |
| ドメイン名の名前解決 | アプリのキャッシュを消去してからテスト用ドメインにアクセス | DNSログ、接続先、適用ルールが一致する |
| UDPを使うアプリ | 実際に必要な音声通話やその他のUDP機能を使う | サーバーと選択したプロトコルが対応し、ログに連続した失敗がない |
pingはICMPを使用するため、TCPやUDPのプロキシテストとは異なります。対象がpingに応答しないだけではTUNの障害と判断できません。ブラウザーでWebサイトを開けても、音声通話、ゲーム、すべてのUDP通信が正常とは限りません。実際に使用するアプリの通信プロトコルごとにテストしてください。
TUNを有効にできない、通信できない、仮想NICが競合するときの対処法
「権限とコンポーネント」「インターフェースとルート」「DNS」「リモート接続」の順に確認します。変更する項目は一度に1つにし、問題が起きた時刻付近のログを保存してください。仮想マシンのネットワーク、企業のリモートアクセスソフト、他の仮想NICは共存できる場合があります。問題が起きたら、まず競合している通信制御機能を無効にし、すべてのネットワークアダプターをまとめて削除しないでください。
スイッチをオンにするとすぐオフに戻る場合は？
まず管理者権限で起動しているか確認し、次にログでインターフェース作成、ファイル不足、権限エラーを調べます。現在のパッケージに必要なコンポーネントが含まれ、セキュリティポリシーによって隔離されていないことも確認してください。失敗するたびにネットワークスタックを切り替えるのではなく、最初に記録された起動エラーを特定します。
有効にした後、すべてのWebサイトが開けません。DNSの問題ですか？
必ずしもそうとは限りません。まずTUNを無効にし、以前のローカルプロキシ経路を再テストします。ここでも失敗するなら、先にノードを確認してください。通常のプロキシが使える場合は、TUNのルートとDNSログを照合します。名前解決のタイムアウトが発生した場合は、DNS上流への到達性、問い合わせの出口、ノードのドメイン名を起動時に解決できるかを重点的に確認します。
Webサイトは見られますが、音声通話やゲームに接続できない場合は？
アプリが実際にUDPを使用しているか、現在のプロキシプロトコルとサーバーがその通信に対応しているかを確認します。ログに該当する宛先が記録されているか確認し、ファイアウォールも調べてください。TCPのWebサイト閲覧に成功してもUDPのテストにはなりません。ローカルの待ち受けポートを変えるだけでは、サーバー側の非対応を解決できません。
有効にしたら社内ネットワークやプリンターに接続できなくなった場合は？
まずTUNを無効にして復旧するか確認し、対象の社内ネットワーク範囲と現在のルートが重複していないか調べます。実際のネットワーク範囲に合わせて、直接接続またはバイパスのルールを追加してください。企業のリモートアクセスを引き続き使う場合は、組織のネットワークポリシーに従ってルートを調整し、管理対象のネットワーク設定を上書きしないでください。
ウィンドウを閉じた後もネットワークに接続できない場合は？
まず、ウィンドウを閉じただけなのか、プログラムを終了したのかを確認します。通知領域のプロセスは動作し続けている場合があります。メイン画面を開き直してTUNを無効にし、システムプロキシを解除してから通知領域のアイコンで終了してください。プロセスが異常終了した場合は、再起動後に一度正常終了します。それでも設定が残る場合は、ルート情報を保存してからシステムを再起動してください。
TUNを終了し、再現可能な設定を記録する
テスト後は、OS、クライアントのバージョン、使用中のノードのプロトコル、TUNの状態、ルーティングモード、DNS上流、障害時に最初に記録されたエラーを簡潔に記録します。サブスクリプションURL、接続資格情報、ユーザーを特定できる完全な設定は公開しないでください。「有効にしたら使えない」とだけ書くのではなく、どの操作で挙動が変わったか分かる記録を残してください。
- まずTUNを無効にし、関連プロセスやインターフェースが停止したことがログに表示されるまで待ち、通常のネットワーク接続が戻ったか確認します。
- システムプロキシを引き続き使う場合は、システムプロキシモードを別途設定します。クライアントを終了する場合は、システムプロキシを解除した状態にしてください。
- LANと普段使うサイトへの接続を再テストし、他のツールがデフォルトルートを使用していないか確認します。
- 基本のネットワーク接続が安定したことを確認してから、カスタムの振り分けルールやその他の詳細設定を1つずつ有効にします。複数のルールセットを一度に読み込み、互いに上書きし合う状態は避けてください。
TUNを使うと通信の入口を広くカバーできますが、最終的な動作はルーティング、DNS、外向き接続の可否によって決まります。各フィールドの詳細は設定フィールドの説明をご覧ください。クライアントが生成したTUN設定を、すべてのコアに共通するconfig.jsonと誤解しないでください。