この記事では、Windows版v2rayNの操作方法を解説します。ブラウザーは接続できるのに、コマンドラインやほかのアプリではプロキシが使われない場合に役立ちます。まずノードの接続を確認し、管理者権限でTUNを有効にします。仮想NIC、ルート、接続ログを照合して通信の取り込みを確認しましょう。接続できなくなった場合は、決められた手順で元に戻し、ノード・DNS・ルート規則を一度に変更しないでください。
システムプロキシとTUN：通信の取り込みとプロキシ経由は別
システムプロキシは、OSがアプリに提供するプロキシ設定です。ブラウザーは通常この設定を読み込みますが、一部のコマンドラインツール、ゲーム、バックグラウンドサービスは独自のネットワーク設定を持ち、従わないことがあります。TUNはレイヤー3の仮想ネットワークインターフェースを作成し、ルートを使って条件に合うIPパケットをプロキシのコアへ転送します。各アプリがHTTPプロキシやSOCKSプロキシに対応している必要はありません。
概要にある「全通信」は取り込み対象を示すもので、すべてのパケットが必ずプロキシサーバーを経由するという意味ではありません。LANの除外設定、インターフェースのバインド、IPv6の設定、特定のシステム通信によって対象範囲は変わります。TUNに取り込まれた通信も、ルールに応じて直接接続、プロキシ経由、ブロックに振り分けられます。TUNを有効にしても、「LANを迂回する」ルート設定が自動的に全通信プロキシへ切り替わるわけではありません。
| 比較項目 | システムプロキシ | TUNモード |
|---|---|---|
| 接続位置 | アプリがプロキシ設定を読み込む | システムルートと仮想NIC |
| 主な対象 | 設定に従うブラウザーなどのアプリ | ルートに取り込まれたTCP・UDP通信 |
| Windowsの権限 | 現在のユーザーのプロキシ設定変更は通常、昇格不要 | 通常は管理者権限が必要 |
| 通信の振り分けルールへの影響 | 自動では変更されない | 自動では変更されない |
| 主な確認箇所 | プロキシアドレス、ローカル待ち受けポート | NIC、ルート、DNS、コアのログ |
判断の目安：一部のアプリだけプロキシを使わない場合はTUNを検討
ブラウザーとほかの対象アプリが想定どおり接続できるなら、システムプロキシのままで問題ありません。ブラウザーは正常でも、システムプロキシを使わないアプリで接続に失敗する場合は、まずそのアプリが手動プロキシに対応しているか確認し、必要に応じてTUNを使うか判断しましょう。
有効化する前に：設定を記録し、ノードを確認
v2rayNはクライアントの操作画面で、実際の通信転送はコアが行います。ノードがVMessまたはVLESSであることだけでは、TUNが使えるかどうかは決まりません。使用中のクライアントが対応するTUNバックエンドと関連コンポーネントを備えている必要があります。バージョンによってはsing-boxがTUN接続を担当します。「TUNスイッチ」を、すべての通信をXrayの単一設定に渡す機能と捉えないでください。
以下では、近年のWindows版で一般的な項目名を使って説明します。デスクトップ版によってボタンの位置やTUN設定の項目名が異なる場合があります。まず「ヘルプ」→「バージョン情報」で使用中のバージョンを記録し、画面上の項目と照らし合わせてください。同じ項目が見つからない場合は、古いスクリーンショットをそのまま参考にしたり、コア設定を独自に追加したりしないでください。
- 設定を保存する。現在の設定フォルダーをバックアップするか、サブスクリプショングループ、使用中のノード、ルーティングモード、DNSの現在値を記録します。バックアップにはサブスクリプションURLや認証情報が含まれる場合があるため、安全な場所に保管してください。
- 基本接続を確認する。TUNはまだ有効にせず、利用可能なノードを選択して、システムプロキシ経由で実際のWebページを開きます。遅延の数値が正常なだけでは不十分です。実際のリクエストが完了することを確認してください。
- ローカルポートを記録する。「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートと待ち受け方式を確認します。この記事では記録例として
127.0.0.1:10808を使用します。実際の値は現在の設定を確認してください。 - ほかの通信取り込み機能を停止する。ほかのVPN、仮想NICを使う通信制御ツール、ネットワーク高速化機能を一時的に終了します。会社の管理下にある端末では、管理ルールを先に確認し、組織のネットワーク保護サービスを無断で停止しないでください。
- インストール先を確認する。完全なインストーラーまたは展開済みフォルダーを使用し、起動ファイルだけをコピーしないでください。現在のユーザーに設定ファイルやログへの書き込み権限があることも確認します。
Windowsでの有効化手順と設定の比較
初回の有効化では、通信を取り込む方法だけを変更し、動作確認済みのノードとルーティング設定は維持します。サブスクリプションの更新、プロトコルの切り替え、DNSの変更、TUNの有効化を同時に行うと、失敗の原因を特定しにくくなります。
- クライアントを正しく終了する。メインウィンドウを閉じるだけでなく、タスクトレイのメニューからv2rayNを終了します。以前のプロセスが終了したことを確認してください。
- 管理者として再起動する。v2rayNの起動ファイルを右クリックし、「管理者として実行」を選択して、Windowsの権限確認に応じます。今回の起動で管理者権限を取得できない場合は、権限の問題を先に解決してください。TUNスイッチを何度もクリックしないでください。
- 使用中のノードを確認する。メイン画面で選択中のサーバーとルーティングモードを確認します。ノードが選択されているだけで、接続確認も済んでいると判断しないでください。
- システムプロキシを解除する。メイン画面またはタスクトレイの「システムプロキシ」メニューから「システムプロキシを解除」を選択します。最初の確認では接続方式を一つに絞ると、問題の切り分けが容易になります。システムプロキシを解除しても、コアが終了するわけではありません。
- TUNを有効にする。メイン画面の「TUNを有効にする」スイッチをオンにします。画面に権限の再取得やコアの再起動が表示された場合は、指示に従ってください。その後、ログに権限エラー、NICの作成エラー、設定の読み込みエラーがないか確認します。
- まずはTUNの標準設定を使う。詳細設定を確認する場合は、「設定」→「パラメーター設定」のTUN関連ページを開きます。バージョンによっては「TUNモード設定」という項目名です。項目が見当たらない場合は、使用中のバージョンの標準値を維持し、別バージョンの設定を流用しないでください。
基準：システムプロキシで接続確認
- 実行権限
- 現在のユーザー
- システムプロキシ
- システムプロキシを自動設定
- TUNを有効にする
- オフ
- ローカルアドレス
- 127.0.0.1
- ポートの記録
- 10808（説明用の例）
ポート番号だけでプロトコルは判断できません。実際のHTTPまたは混合待ち受けポートに合わせてください。
目的：TUNのみを個別に確認
- 実行権限
- 管理者
- システムプロキシ
- システムプロキシを解除
- TUNを有効にする
- オン
- 使用中のノード
- 確認済みのノードを維持
- ルーティングモード
- 現在のモードを維持
ローカルプロキシの待ち受けはそのまま利用できます。TUNは仮想NIC経由で通信を取り込むため、システムNICのポートを10808に変更する必要はありません。
初回起動時にWindowsファイアウォールの確認が表示されたら、プログラムのパスと適用するネットワークの範囲を確認してください。スイッチを有効にするためにファイアウォール全体を無効にしたり、ローカルの待ち受けアドレスを0.0.0.0に変更したりしないでください。待ち受け範囲を広げても仮想NICの権限問題は解決せず、同じネットワーク上の端末からローカルプロキシへ接続されるおそれがあります。
有効化を確認する：NIC、ルート、実際のリクエスト
「スイッチがオン」は画面上の状態が変わったことしか示しません。仮想インターフェースの有無、ルートの変化、対象リクエストがコアに届いたかをあわせて確認してください。以下のコマンドはWindows PowerShellで実行します。有効化の前後で実行し、結果を比較してください。インターフェース名はバージョンや設定によって異なるため、チュートリアルのスクリーンショットと一致しなくても問題ありません。
Get-NetAdapter -IncludeHidden |
Select-Object Name, InterfaceDescription, Status
route print -4
route print -6
curl.exe --noproxy "*" -I --connect-timeout 10 https://example.com/- NICの確認：有効化の前後でTUN仮想インターフェースが追加または有効化されたかを比較します。以前からある仮想NICが表示されるだけでは、今回の通信取り込みが成功した証拠になりません。
- ルートの確認：IPv4ルートにTUN宛ての項目が追加されたかを確認します。実装によってはデフォルトルートの分割など別の方式を使うため、新しい
0.0.0.0/0が必ず表示されるとは限りません。 - リクエストの確認：
--noproxy "*"を指定すると、curlは明示的なプロキシ設定を使いません。システムルート経由の接続を確認するのに適しています。この指定でTUNを迂回することはありません。HTTPレスポンスを受信できればリクエストの完了は確認できますが、それだけではプロキシ経由で外部へ接続したかどうかは判断できません。 - 振り分けの確認：コアのログで接続先アドレスと出站タグを照合し、テスト対象が直接接続かプロキシ経由かを確認します。現在のログレベルで接続が表示されない場合は、一時的に1段階上げ、確認後に元へ戻してください。ログを共有する前に、機密情報を削除します。
直接接続する対象と、ルールでプロキシ経由にする対象をそれぞれテストしてください。出口IPの変化から分かるのは、そのリクエストの出口が変わったことだけで、すべてのアプリが通信を取り込まれた証明にはなりません。UDPも実際に使うアプリでテストしてください。Webページが開けても、ゲームや音声通話で使うUDP通信が正常とは限りません。
判断の目安：2種類以上の証拠を確認してから成功と判断
仮想インターフェースとルートの変化で接続経路が確立したことを確認し、接続ログでルールの選択が想定どおりか確かめます。スイッチ、遅延の数値、出口IPだけを見るより、両方を確認するほうが確実です。
DNS、IPv6、LANアクセスの注意点
TUNがパケットを受信しても、DNSが必ず想定どおりに動作するとは限りません。システムのキャッシュ、ブラウザーのセキュアDNS、クライアントのDNSルール、コアによるDNSの取り込みによって、経路が分かれることがあります。「IPアドレスには接続できるのに、ドメイン名では開けない」場合は、まずログの名前解決エラーを確認し、次にクライアントのDNS設定を見直してください。すべてのDNSアドレスを同じパブリックDNSに置き換えるのは避けましょう。
- DNSの取り込み：一般的にはUDPまたはTCPの53番ポートへの問い合わせを処理します。ブラウザーの暗号化DNSは別の接続方式を使うため、同じ53番ポートのルールで制御されるとは限りません。
- IPv6：IPv4とIPv6ではルートテーブルが異なります。IPv4だけを処理していると、一部のアプリがIPv6経由で別の経路を通ることがあります。
route print -6とクライアントのIPv6設定を確認してから、変更が必要か判断してください。 - LAN：プリンター、ファイル共有、ルーターの管理画面には通常、直接接続が必要です。
192.168.0.0/16、10.0.0.0/8、172.16.0.0/12など、実際に使っているネットワーク範囲を確認し、LAN全体を無理にプロキシ経由にしないでください。 - FakeDNS：ドメイン名と仮想アドレスを対応付ける仕組みで、TUNを有効にするための必須機能ではありません。基本接続を確認する前に追加で有効にすると、アドレスの対応付け、キャッシュ、通信の振り分けを同時に調べる必要があります。
DNSの設定を変更した後、Windowsに古い名前解決結果が残っている可能性がある場合は、以下のコマンドを実行してから再テストしてください。このコマンドで消去されるのはWindows DNSクライアントのキャッシュだけです。ブラウザー独自のキャッシュは消去されず、上流DNSやルート設定の誤りも修正されません。
ipconfig /flushdnsよくあるトラブル：問題の場所に応じて対処する
スイッチをオンにするとすぐオフに戻る場合は？
まず同じ時刻のコアログを確認します。権限不足やインターフェース作成の失敗が記録されている場合は、終了してから管理者として再起動してください。コンポーネント不足のメッセージが表示された場合は、設定を残したまま完全なインストーラーで修復します。ノードを何度も切り替えないでください。通常、ノードの設定ではローカルのNIC作成エラーを解決できません。
TUNを有効にしたらネット接続がすべて切れた場合、まずDNSを変更すべきですか？
まずTUNを無効にし、システムプロキシを元の状態に戻して、基本接続が正常か確認します。次にほかの通信制御プログラムを終了し、TUNだけを有効にします。ログに名前解決のタイムアウトがある場合はDNSを調べます。ノードへの接続タイムアウトなら、ノードへの到達性、インターフェースの選択、ルートのループを確認してください。
Webページは開くのに、ゲームの接続に失敗する場合は？
対象への接続がログに記録されているか確認し、ノードの接続先とサーバーが必要なUDP転送に対応しているかを調べます。TUNがUDPを受信できても、サーバーがUDPを転送できるとは限りません。ゲームの接続失敗には特定のポート、地域制限、アプリ独自の制限が関係することもあります。グローバルモードを有効にするだけで解決すると判断しないでください。
有効化後にプリンターや社内ネットワークへ接続できなくなった場合は？
接続できない宛先の実際のIPアドレスとネットワーク範囲を記録し、プロキシルールに誤って含まれていないか確認します。個人のLANは必要に応じて直接接続に戻してください。専用VPNを使う社内ネットワークでは、まずTUNを無効にして確認します。2つのデフォルトルートを重ねたり、用途が分からないまま企業用NICを削除したりしないでください。
Webページの文字は表示されるのに、画像のアップロード、動画、大容量ファイルの転送が頻繁に止まる場合は、MTUも確認します。まず現在の値を記録し、使用中のバージョンに該当する項目がある場合のみ、1項目ずつ変更して比較してください。たとえば1500を一時的に1400に変更し、同じ作業を試します。この数値はトラブルシューティング用のテストであり、すべての環境に最適な値ではありません。改善しない場合は元に戻し、一時的なネットワークの揺らぎを設定の効果と誤認しないようにしましょう。
無効化と復元：システムの通信経路を確認
TUNが不要になったら、まず「TUNを有効にする」をオフにし、コアの終了または切り替えが完了するまで待ってから、必要なシステムプロキシの状態に戻します。メインウィンドウを閉じただけではタスクトレイのプロセスが動作している場合があり、通信の取り込みを停止したことにはなりません。
- TUNを無効にした後、NICの状態とルートテーブルをもう一度確認します。仮想アダプターが残っていても問題ありませんが、通信を誤って取り込むルートが残っていないことを確認してください。
- ブラウザーでプロキシを引き続き使う場合は、「システムプロキシ」で「システムプロキシを自動設定」を有効にします。すべて直接接続する場合は、「システムプロキシを解除」を選択してください。
- クライアントが異常終了してネット接続が切れた場合は、まず元のクライアントを再起動し、TUNを正しい手順で無効にします。Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、停止済みの待ち受けポートを指す手動プロキシ設定が残っていないか確認してください。
- 復旧しない場合はログを保存してシステムを再起動し、ほかのVPNや仮想NICソフトウェアを確認します。ネットワークのリセットやNICの一括削除は行わないでください。固定IP、社内ネットワーク、リモート管理に影響するおそれがあります。
TUNはアプリの通信をコアへ取り込む方法、サブスクリプションは利用可能なノード、ルーティングは直接接続とプロキシの振り分け、DNSはドメイン名の解決方法を決めます。この4つを分けて確認すれば、「通信が取り込まれていない」「振り分けが誤っている」「ノードが使えない」を切り分けられます。基本操作は利用ガイドから、プロトコルやトランスポートの設定は技術リファレンスから確認してください。