この記事では、Windows版v2rayNを使って設定します。まずシステムプロキシでノードの接続を確認し、管理者権限でTUNを有効にしてから、ルーティング、DNS、アプリの接続をそれぞれ検証します。ブラウザーは使えるのに、コマンドラインツールやほかのアプリがプロキシを経由しない場合に役立ちます。TUNで通信を取り込んだ後、直接接続するかプロキシを使うかはルールによって決まります。
システムプロキシとTUN：通信を取り込む層の違い
システムプロキシは、システム設定に従うアプリにローカルプロキシのアドレスを渡します。アプリがリクエストをプロキシの待ち受けポートへ送り、クライアントが転送する仕組みです。独自のネットワークスタックやプロキシ設定を使うアプリ、UDP接続を直接確立するアプリは、この設定を経由しないことがあります。ブラウザーでWebページを開けても、ほかのアプリもプロキシを使っているとは限りません。
TUNはネットワーク層に仮想インターフェースを提供します。条件に合うIPパケットをシステムルートがそのインターフェースに送り、TUNバックエンドが処理してから、直接接続またはプロキシのアウトバウンドへ転送します。通常、アプリ側でHTTPプロキシやSOCKSプロキシに対応する必要はありません。ただし、あらゆる通信プロトコルや宛先が必ず転送されるわけではありません。
ここでは「全体」を2つの意味に分けて考える必要があります。TUNが通信を取り込む範囲と、ルーティングでプロキシを使う範囲は別の設定です。TUNを有効にしても、LANやプライベートアドレス、ルールで指定した宛先は直接接続できます。取り込み可能なすべてのインターネット向け通信をプロキシ経由にするには、TUNのスイッチだけでなく、現在のルーティングモードとデフォルトのアウトバウンドも確認してください。
有効化する前に：ポート、ノード、ルーティングの状態を記録
まずv2rayNでインポート済みのノードを選び、アクティブサーバーに設定して、システムプロキシ経由で実際にWebページへアクセスします。遅延テストの結果だけでは不十分です。テストに成功しても、その確認経路が使えることを示すだけで、DNS、TLS、実際の通信がすべて正常とは限りません。この段階で失敗する場合は、ノードのアドレス、認証情報、トランスポート設定、サーバーの状態を先に確認してください。
10808は以下で使うテスト用の値です。まず「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートを確認して、コマンドのポート番号を実際の値に置き換えてください。バージョンによっては混合ポートが用意されていたり、SOCKSとHTTPのポートが別々に表示されたりします。そのポートがHTTPプロキシに対応すると確認できた場合に限り、以下のHTTPプロキシのテストコマンドを使ってください。
- 現在のアクティブノード、ルーティングモード、システムプロキシの状態を記録し、必要に応じてクライアント設定をバックアップします。
- デフォルトルートやDNSをすでに制御しているVPN、通信最適化ツール、プロキシソフトを終了し、基準テストでは通信を取り込むソフトを1つだけにします。
- 現在の配布パッケージに必要なコアコンポーネントが含まれていることを確認します。ログに実行ファイルが見つからないと表示された場合は、TUNを何度も切り替えるのではなく、先にコンポーネントを補ってください。
- 会社の端末では、仮想インターフェースの作成がネットワークやエンドポイントセキュリティのポリシーで許可されているか、先に確認してください。管理ポリシーを回避するためにセキュリティソフトを無効にしないでください。
Windowsでの有効化手順：管理者権限とTUN設定
以下では、「TUNを有効にする」スイッチがあるv2rayNの画面を前提に説明します。デスクトップ版とWPF版、バージョンによってボタンの位置は異なる場合があります。通常、メイン画面にTUNスイッチがあり、TUN関連の設定は「設定」→「パラメーター設定」にまとまっています。現在の画面に項目がない場合は、クライアントのバージョンと配布パッケージの種類を確認してください。Windowsのネットワーク設定から、同じ名前のNICを手動で作成しないでください。
- 完全に終了してから管理者権限で起動します。トレイメニューからv2rayNを終了し、既存のプロセスが終了したことを確認してから、プログラムを右クリックして「管理者として実行」を選択します。ウィンドウだけを開き直してトレイのプロセスが残っていると、以前の権限のまま動作する場合があります。
- アクティブノードを確認します。メイン画面で現在のサーバーとルーティングモードを確認します。まずは実際の接続で動作を確認済みのノードを使い、TUNを初めて有効にするときに、サブスクリプション、トランスポート方式、DNSを同時に変更しないでください。
- TUNの設定を確認します。初回はクライアントのデフォルトのスタック、MTU、ルーティング関連の設定を維持します。独自設定を使っている場合は、自動ルーティングが無効になっていないか確認してください。無効だと、仮想インターフェースが存在しても対象の通信を取り込めないことがあります。
- システムプロキシを解除します。クライアントのシステムプロキシメニューから設定を解除し、TUNだけを検証できる状態にします。両方を併用できないわけではありませんが、同時に有効にすると、ブラウザーのテストだけではTUNが機能しているか判断できません。
- TUNを有効にしてログを確認します。メイン画面で「TUNを有効にする」をオンにし、権限不足、インターフェースの作成失敗、コアの終了、設定の解析エラーがないかログを確認します。エラーが発生したら、まずスイッチをオフにして、最初に記録された明確なエラーから対処してください。
ルーティングとDNS：LAN接続を維持し、アウトバウンドのループを防ぐ
TUNでは、アプリの通信をトンネルに通しつつ、プロキシコアからサーバーへの通信が自分自身に再び取り込まれ続けないようにする必要があります。通常、クライアントとバックエンドは、ルートの除外やインターフェースのバインドなどでこの問題を処理します。複数の通信制御ソフトの併用、デフォルトルートの手動追加、不完全な独自設定は、この仕組みを壊す原因になります。
初回テストの基準設定
- 通信を取り込む方式
- TUNのみを有効にし、システムプロキシを解除
- アクティブノード
- 実際のアクセスで接続を確認済みのノードを使用
- TUNスタックとMTU
- 現在のバージョンのデフォルト値を維持
- DNS設定
- クライアントで使える設定を維持し、リゾルバーを同時に変更しない
まず変更要因を絞り、ログをもとに通信の取り込み、名前解決、アウトバウンドの問題を特定します。
基準テストに成功した後の調整
- LAN内の宛先
- 必要に応じて192.168.0.0/16などのプライベートネットワークを直接接続
- プロキシサーバー
- 接続がTUNに再度取り込まれていないことを確認
- インターネット上の宛先
- 現在のルーティングルールに従ってアウトバウンドを選択
- DNSの経路
- リゾルバーへの到達性と、使用するアウトバウンドが一致していることを確認
これらは確認項目であり、そのままインポートできる設定キーではありません。具体的な項目はバックエンドのバージョンによって異なります。
LAN向けルールに192.168.0.0/16だけを指定しても不十分です。実際のネットワークに応じて、10.0.0.0/8、172.16.0.0/12などのアドレスやIPv6のLAN範囲も確認してください。プリンター、ファイル共有、ルーターの管理画面は、必要に応じて直接接続できるようにします。「LANをバイパス」といった設定名だけで、すべての範囲が対象になると思い込まないでください。
DNSも検証が必要です。通常のUDP/TCP 53番ポートの問い合わせと、アプリ内蔵の暗号化DNSは経路が異なります。ブラウザーが独自のリゾルバーを使っていると、システムの結果と一致しない場合があります。FakeIPを有効にしている場合、合成アドレスが返されても、それだけで名前解決エラーとは限りません。バックエンドがそのアドレスを元のドメイン名に対応付けられるか確認してください。到達できないリゾルバーの解決策として、キャッシュの削除を頼りにしないでください。
通信の取り込みを検証する：ブラウザーの再読み込みだけで済ませない
検証時はブラウザーに手動設定したプロキシを解除し、システムプロキシもオフになっていることを確認します。既存の接続が以前の経路を使い続けないよう、対象アプリを終了してから再起動してください。以下のコマンドは、明示的なプロキシ接続と通常のシステムネットワーク接続を区別するためのものです。テスト用ドメインは繰り返しHTTPSリクエストを送るために使い、特定のWebサイトがプロキシルールに一致するかを判定するものではありません。
# Windows PowerShellで実行
# 10808がHTTPプロキシに対応すると確認できた場合のみ、1つ目のコマンドを使用
curl.exe -I --connect-timeout 10 --proxy http://127.0.0.1:10808 https://example.com
# curlで明示的なプロキシを使わず、システムルートで処理
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com
# 現在のインターフェースとIPv4・IPv6のルートを確認
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
# システムのDNS問い合わせ結果を個別に確認
Resolve-DnsName example.com- まずスイッチのオン・オフで比較します。TUNをオフにして明示的なプロキシを使わないリクエストを実行し、次にTUNをオンにして再試行します。同時に、クライアントのログにそのアプリの新しい接続が記録されているか確認してください。一度成功しただけでは、通信経路が変わったとは断定できません。
- 一致したアウトバウンドを確認します。テスト対象が、もともとルールで直接接続に指定されていることがあります。プロキシ経由か検証するには、プロキシを使うと明確に設定された宛先を選び、接続履歴または該当する詳細度のルーティングログを確認してください。
- IPv4とIPv6を分けてテストします。必要に応じて、リクエストに
-4または-6を指定してください。一方だけ成功する場合は、ノードが無効だと決めつけず、アドレスファミリーごとの通信の取り込みとアウトバウンドの対応状況を確認します。 - 問題が起きているアプリを個別にテストします。Webとコマンドラインでの確認後、実際に問題が出ているアプリをテストしてください。UDPが使えるかどうかは、TUNバックエンド、ノードのプロトコル、サーバーによって異なり、HTTPSのテスト結果からは判断できません。
仮想インターフェースを向く0.0.0.0/0のルートがあるかだけを確認しても不十分です。自動ルーティングでは、より具体的なルートに分割される場合があります。宛先アドレス、プレフィックス長、インターフェースを照合し、実際に選択されるルートを確認してください。ログの詳細度を上げるのは必要なときだけにし、共有する前にノードのアドレスや認証情報、個人のアクセス履歴を含む内容を削除してください。
よくあるトラブル：権限、通信の取り込み、名前解決、アウトバウンドの順に確認
TUNをオンにするとエラーが出て、スイッチがオフに戻る？
まずトレイから完全に終了し、管理者権限で起動します。ログで最初に記録されたインターフェース、権限、コア起動に関するエラーを確認してください。コンポーネントの不足や設定項目の互換性が原因の場合は、該当する配布パッケージを修正するか、独自のTUN設定を元に戻します。管理者権限では設定の解析エラーは解決できません。
システムプロキシでは使えるのに、TUNをオンにするとネットにつながらない？
ほかのVPNや通信最適化ツールを終了し、通信を取り込むソフトを1つだけにします。まずTUNをオフにして基準状態に戻し、有効化後のルートの変化とサーバー接続のログを確認してください。プロキシサーバーへの接続まで再び取り込まれている場合は、ノードを何度も切り替えるのではなく、独自ルーティングの除外設定を確認します。
接続は確立できるのに、ドメイン名の名前解決が続けて失敗する？
Resolve-DnsName example.comでシステムの名前解決を個別に確認し、クライアントのDNSログとリゾルバーのアウトバウンドも確認します。設定を修正したと確認できてから、ipconfig /flushdnsを実行して古いキャッシュを削除してください。ブラウザー独自のDNSも別途確認が必要です。
有効化後、プリンターや社内ネットワークにアクセスできない？
社内ネットワーク内の宛先アドレスを確認し、プライベートネットワークを直接接続するルールとNICのルートを照合します。社内専用ドメインでは、内部DNSが必要な場合もあります。通常、パブリックDNSに問い合わせても正しい結果は得られません。変更前に元の設定を保存し、社内のアドレス範囲全体を安易にプロキシ対象へ追加しないでください。
Webは見られるのに、ゲームや音声通話がつながらない？
まず、そのアプリが別のインターフェースに個別にバインドされていないか確認し、UDP接続のログとノードのUDP対応状況を調べます。小さなパケットは通るのに、大きなパケットで接続が止まりやすい場合に限り、MTUやパスMTUを追加で調査します。根拠がないままMTUの変更を最初に試さないでください。
停止と復旧：先に通信の取り込みを解除し、その後クライアントを終了
TUNを使わなくなったら、まずv2rayNで「TUNを有効にする」をオフにし、通常のネットワーク接続が復旧したことを確認してからクライアントを終了します。システムプロキシに戻す場合は、ローカルプロキシが正常に待ち受けていることを確認し、クライアントからシステムプロキシを再設定してください。こうすると仮想NIC経由とアプリのプロキシ経由を区別でき、終了済みプロセスを指すシステムプロキシの設定が残るのを防げます。
- 通常の手順でTUNをオフにし、バックエンドの停止とルートの削除が完了したかログで確認します。
- 使用しないシステムプロキシ設定を解除し、対象アプリを再起動してテストします。
- 異常終了後にネットワークがつながらない場合は、クライアントを再起動してTUNを通常の手順で一度オン・オフするか、システムを再起動してから残ったルートを確認します。
- 用途の分からない仮想NICをそのまま削除したり、ルートテーブルを一括消去したり、すべてのネットワークインターフェースをリセットしたりしないでください。ほかの業務用ネットワーク設定まで壊すおそれがあります。
TUNが解決するのは、アプリの通信をクライアントに取り込む方法です。ノードの接続可否、ドメイン名の名前解決、ルールに一致するアウトバウンドは、それぞれ別の問題です。「システムプロキシで基準確認、TUN単独で検証、対象アプリを再テスト」の順に結果を記録すると、複数の設定を同時に変更するより原因を特定しやすくなります。ルールやDNSの詳しい説明は高度な設定を、用語の意味は用語集を参照してください。