システムプロキシはアプリにプロキシの接続先を知らせるもので、すべての通信を自動的に中継するわけではありません。この記事では、Windowsで「v2rayNは起動しているのに、ブラウザーやターミナルが直結する」場合の確認方法を解説します。まずローカルの待ち受けを確認し、次にブラウザーのプロキシ設定元、最後にターミナルのプロキシ設定を調べます。同じURLと接続先を使い、コアのログと照らし合わせることで、アプリがプロキシを使っていないのか、ルーティングで直結しているのか、ノードへの接続に失敗しているのかを切り分けられます。
まず整理：システムプロキシ・アプリのプロキシ・ルーティングの違い
システムプロキシを有効にしても、すべてのプログラムがv2rayN経由になるわけではありません。Windowsのプロキシ設定を使うには、アプリ側が設定を読み込む必要があります。ブラウザーは通常システム設定を参照しますが、多くのコマンドラインツールは専用のオプションや環境変数を使います。ブラウザーでアクセスできてターミナルでは失敗する場合も、ノードに問題があるとは限りません。
| レイヤー | 役割 | 主な確認項目 |
|---|---|---|
| システムプロキシ | システム設定に従うアプリにプロキシの接続先を提供 | Windowsのプロキシアドレス、ポート、例外リスト |
| アプリごとのプロキシ | ブラウザー拡張機能やコマンドラインオプションなどで接続先を指定 | システム設定を上書きしていないか、古いポートが残っていないか |
| コアのルーティング | コアが受け取ったリクエストを直結とプロキシ経由のどちらで送るか決定 | ルールの順序、適用されたルール、アウトバウンドのタグ |
| TUNモード | 仮想ネットワークインターフェースで、取り込み対象の通信を受け取る | 権限、ルート、DNS、除外設定 |
切り分けでは、まず条件をそろえます。TUNを一時的に無効にし、起動中のプロキシクライアントを1つだけにして、ノードとテストURLをそれぞれ1つ選びます。ここではリクエスト方法の例としてhttps://example.comを使います。特定の地域からのアクセス可否を調べる専用サイトではありません。実際の問題を確認する際は、元々アクセスできなかったURLでも再テストしてください。
手順1：ローカルのプロキシポートは待ち受け中？
ブラウザーの設定を変える前に、まずローカルの接続先を確認します。以下では、HTTPプロキシに対応していることを確認済みの127.0.0.1:10808を例にします。すべてのバージョンでこのポートが既定値という意味ではありません。クライアントに別のポートが表示されている場合は、すべてのコマンドをその値に合わせてください。古い手順に記載されたHTTP用とSOCKS用のポートを混同しないようにしましょう。
-
接続先を確認
v2rayNの「設定」→「パラメーター設定」を開き、基本設定にあるローカル待ち受けの項目でポートと接続プロトコルを確認します。画面のバージョンによって項目名やグループ分けが異なる場合があります。メイン画面の状態とコアの起動ログも確認し、ポート番号だけでプロトコルを推測しないでください。
-
待ち受けを確認
PowerShellで次の
Test-NetConnectionを実行します。TcpTestSucceededがFalseの場合は、コアが停止していないか、ポート番号に誤りがないかを確認し、起動ログも調べてください。 -
プロセスを確認
netstatで待ち受けの記録とPIDを調べ、タスクマネージャーの「詳細」タブでプロセスを確認します。ポートに接続できても、接続を受け付けているプログラムが現在のv2rayNから起動したコアとは限りません。 -
プロキシを明示してリクエスト
後述の
curl.exe --proxyで接続先を直接指定します。成功したら次にシステムプロキシを確認します。失敗した場合は、接続プロトコル、ノードの設定値、コアのエラーを優先して調べてください。
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
netstat -ano | findstr ":10808"コアのログにaddress already in useと表示された場合は、まずポートの競合を解消します。正体の分からないプロセスをそのまま終了しないでください。使用元のプログラムを確認してから、重複したインスタンスを終了するかローカルポートを変更し、システムプロキシを設定し直します。
ブラウザーでプロキシが使えない：システム設定・拡張機能・PACを確認
ブラウザーの切り分けでは、現在どの設定元のプロキシが実際に使われているかを特定することが重要です。EdgeやChromeでは、システム設定、プロキシ拡張機能、起動オプション、組織のポリシーが接続に影響する場合があります。v2rayNのアイコンが通知領域に表示されているだけでは、ブラウザーがプロキシを使っているとは判断できません。
-
システムプロキシを適用
v2rayNの通知領域アイコンのメニューから「システムプロキシ」→「システムプロキシを自動設定」を選択します。次にWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートが現在のローカル接続先と一致しているか確認してください。
-
プロキシ拡張機能を無効化
ブラウザーの「拡張機能」→「拡張機能を管理」を開き、プロキシを管理する拡張機能を一時的に無効にしてからブラウザーを再起動します。シークレットウィンドウだけで確認するのは避けてください。拡張機能によってはシークレットウィンドウでも動作し、ブラウザーのポリシーも引き続き適用されるためです。
-
自動設定スクリプトを確認
Windowsの同じ「プロキシ」画面で「セットアップ スクリプトを使う」を確認します。有効になっている場合は、スクリプトのアドレスとルールを確認してください。切り分けのため元の値を控え、一時的に単一の手動プロキシに切り替えると、PACが返す
DIRECTによる影響を除外できます。 -
再テストしてログを確認
ブラウザーを終了して再起動し、同じテストURLにアクセスしながらコアのアクセスログを確認します。リクエストがコアに届いている場合は、アウトバウンドのタグも確認してください。直結ルールが適用されているなら、それはルーティングの選択であり、システムプロキシの不具合ではありません。
PACが決めるのは「アプリがリクエストをどこに渡すか」、コアのルーティングが決めるのは「受け取ったリクエストをどこへ送るか」です。どちらの段階でも直結になる可能性がありますが、対処する場所は異なります。特定のサイトだけをプロキシ経由にするために、PAC、DNS、すべてのルーティングルールを同時に書き換えないでください。
判断の目安：プロキシを明示した接続が成功するなら、まずブラウザーの接続先を確認
同じURLへのcurlリクエストがプロキシを指定すると成功する一方、ブラウザーからのリクエストが有効なアクセスログに記録されない場合は、拡張機能、PAC、ブラウザーのポリシーを確認します。VMess、VLESS、トランスポートの設定は、まず変更しないでください。
ターミナルでプロキシが使えない：まずcurlで指定し、次に環境変数を設定
コマンドラインプログラムは、Windowsでシステムプロキシを有効にしても自動的に経由するとは限りません。まずオプションを明示して動作を確認し、その後で環境変数を検討してください。PowerShellではcurl.exeと入力します。Windows PowerShellのcurlは別コマンドのエイリアスになっている場合があり、オプションの意味が異なることがあるためです。
リクエストを1つ送ってHTTPプロキシの接続先を確認
次のコマンドはシステムプロキシに依存しません。--noproxyで、このリクエストのプロキシ除外先をテスト用の予約ドメインunused.invalidに限定し、既存のNO_PROXYによってexample.comが意図せず直結するのを防ぎます。このコマンドは永続的な設定を変更しません。
curl.exe --proxy http://127.0.0.1:10808 --noproxy unused.invalid --connect-timeout 10 --verbose --head https://example.com詳細出力にある127.0.0.1への接続と、HTTPSリクエストのCONNECTの流れで接続先を確認できます。HTTPのレスポンスコードは、その後のリクエスト結果を示します。レスポンスが返ってきても、必ずリモートのプロキシノードを経由したとは限りません。コアのアウトバウンド記録も照合してください。ログを共有する前に、認証情報や機密性のあるアドレスを削除してください。
現在のPowerShellセッションにプロキシを設定
$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe --connect-timeout 10 --head https://example.comHTTPS_PROXYにもhttp://と指定するのは正しい設定です。これはターミナルからローカルのHTTPプロキシへの接続方式を表し、HTTPSの接続先には通常CONNECTトンネルを使います。接続先のURLがHTTPSだからといって、プロキシの指定をhttps://に変更しないでください。
- 適用範囲：このPowerShellでの代入は、現在のセッションと、その後に起動する子プロセスにのみ適用されます。すでに起動している別のターミナルには反映されません。
- ツールによる違い：環境変数がすべてのツールに共通して適用されるわけではありません。小文字の変数名、専用設定、コマンドラインオプションが必要な場合もあるため、使用するツールのドキュメントを確認してください。
- ターミナル環境の違い：WSLやコンテナは独立したネットワーク環境を持つ場合があります。その中の
127.0.0.1がWindowsホストの接続先を指すとは限らないため、アドレスをそのまま流用しないでください。 - SOCKS接続先：対象ポートがSOCKS5に対応していると確認できた場合に限り、対応するオプションを使います。curlの
socks5h://は接続先のドメイン名をプロキシ側で解決する指定です。HTTP専用ポートへの接続には使わないでください。
テスト後にセッションの環境変数を削除
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue削除する前に元の値を控えてください。すでにプロキシ環境を設定しているPCでは、元の設定に戻します。特に、テスト用の変数をシステム全体の環境変数へ安易に追加しないでください。v2rayNを終了してローカルポートが閉じると、その変数を引き継いだプログラムで接続エラーが続く可能性があります。
エラーメッセージから対処する箇所を見分ける
エラーメッセージは、どの段階で発生したかと合わせて判断します。同じ「タイムアウト」でも、ターミナルからローカルの接続先への接続、コアからリモートサーバーへの接続、リモート側から対象サイトへのアクセスのいずれかで発生している可能性があります。以下には実際に表示されるエラーの一部を掲載しています。バージョンによっては、前後にアドレス、ポート、所要時間などが追加されます。
エラー：curl: (7) Failed to connect
原因：接続を確立できません。プロキシを明示したテストでローカルアドレスが表示される場合、接続先が待ち受けていないか、ポート番号が間違っている可能性があります。対処：curlの出力にあるアドレスを確認し、待ち受け状態を調べてポートとプロセスを特定してから、コアを再起動してください。
エラー：curl: (5) Could not resolve proxy
原因：プロキシのホスト名を解決できません。プロキシ用の環境変数の入力ミスがよくある原因です。対処：Get-ChildItem Env:*proxy*で環境変数を確認し、確認済みのローカル接続先に変更してから再テストしてください。
エラー：curl: (28) Connection timed out
原因：接続処理がタイムアウトしました。この表示だけではノードの障害と断定できません。対処：まず詳細出力でどの段階で停止したかを確認し、同じ時刻のコアのログと照らし合わせて、リモート接続とルーティング結果を調べてください。
エラー：ERR_PROXY_CONNECTION_FAILED
原因：ブラウザーから設定済みのプロキシに接続できません。対処：Windowsのプロキシ設定と拡張機能に古いポートが残っていないか確認し、コアの起動を確認してからブラウザーを再起動してください。まずサイトのDNSを変更する必要はありません。
TUNモードが便利なのはどんな場合？
複数のアプリがシステムプロキシを使わず、アプリごとの設定も難しい場合は、TUNを試す価値があります。仮想インターフェースとルーティングで通信を取り込みますが、使用するコア、DNSの方針、除外ルールの影響を受けます。あらゆる通信が無条件にリモートノードへ送られるわけではありません。
- まず基準となる状態を記録：HTTPプロキシを明示したテストが成功することを確認し、現在のノードとルーティング設定を記録してからTUNを有効にします。そうしないと、接続先の問題と仮想NICの問題が重なってしまいます。
- 案内に従って権限を付与：v2rayNのメイン画面でTUNを有効にし、管理者権限が必要と表示されたら、案内に従って再起動します。仮想インターフェース、ルート、DNSの初期化ログも確認してください。
- 設定の重複を避ける：最初の比較テストではターミナルのプロキシ環境変数を削除し、「システムプロキシ」を「システムプロキシを解除」に切り替えて、TUN経由の通信だけを確認します。複数の接続設定を同時に変更しないでください。
- 社内ネットワークへの接続を維持：LAN内の機器や社内ドメインにアクセスできるかテストします。他の仮想NICや社内ネットワークと競合した場合は、まずTUNを無効にして元の状態に戻し、その後で除外設定を調整してください。
使い分け：単一ツールはオプション、複数アプリならTUNを検討
失敗するコマンドが1つだけなら、そのツールのプロキシを設定するのが先です。複数のアプリで通信を取り込む必要がある場合にTUNを検討してください。TUNを使えば接続先をアプリごとに設定する手間は減りますが、ノード設定の誤りやサーバーへの接続不能は解決できません。
よくある質問：プロキシを有効にしたのに結果が違うのはなぜ？
ブラウザーでは使えるのに、PowerShellでは接続できないのはなぜ？
まず--proxyを指定したcurl.exeコマンドを実行します。成功したら、現在のターミナルにプロキシ環境変数を設定します。特定のツールだけが失敗する場合は、そのツール固有のプロキシ設定を確認してください。それだけでノードを変更する必要はありません。
ログにリクエストがあるのに、出口が変わらないのはなぜ？
対象リクエストに対応するアウトバウンドのタグを確認してください。directなど直結するアウトバウンドが適用されているなら、接続先の設定は機能しています。システムプロキシを何度も切り替えるのではなく、対象ドメインのルーティングルールと順序を調整してください。
v2rayNを終了したらブラウザーも開けなくなったのはなぜ？
終了前に通知領域の「システムプロキシ」から「システムプロキシを解除」を選択してください。すでにプログラムを終了している場合は、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開いて元の設定に戻し、自動設定スクリプトが残っていないか確認します。
netshのプロキシインポートコマンドを実行する必要はある？
汎用的な修復方法として使うべきではありません。WinHTTPのプロキシ設定は、ブラウザーで一般的に使われるシステムプロキシの設定と同じではありません。対象のサービスがWinHTTPを使用していると確認できた場合に限り、そのプロキシ状態を調べてください。他のシステムサービスに影響するおそれがあります。
最終的には、確認できる3つの結果を基準に判断します。アプリがローカルの接続先に接続しているか、コアがリクエストを受け取っているか、そのリクエストがどのアウトバウンドを選んだかです。この順に状況を確認すれば、クライアントの再インストールやDNSの無作為な変更を繰り返すより、問題を見つけやすくなります。初回のインポートやプロキシ設定を確認したい場合は、クイックスタートガイドもご覧ください。