システムプロキシを有効にしても動作しない：ブラウザーとターミナルを分けて確認する手順

「動作しない」を3つの範囲に分ける

v2rayN は設定とコアを管理するデスクトップクライアントで、Xray などのプロキシコアが実際の接続を処理します。Windows のシステムプロキシは、一部のアプリにローカルプロキシのアドレスを知らせるだけです。システムプロキシを有効にしても、すべての通信がコアへ強制的に送られるわけではなく、ルーティング規則が必ずプロキシ経由を選ぶわけでもありません。

第1層はローカル待受です。クライアントがコアを起動すると、通常はループバックアドレス上で HTTP、SOCKS、または混合プロキシのポートを待ち受けます。待受が実際に存在して初めて、ブラウザーやターミナルから接続できます。第2層はアプリの接続方法です。アプリが Windows のシステムプロキシを読み取るか、独自に保存したプロキシ設定を使うかを確認します。第3層がルーティングとアウトバウンドです。通信がコアに入った後、設定内のドメイン、IP、プロトコル、規則によって、直接接続、プロキシ経由、ブロックのいずれかが決まります。

そのため、「ブラウザーは使えるのに PowerShell は使えない」という場合、多くはノードが突然無効になったのではなく、接続方法が異なることが原因です。「ブラウザーでプロキシ接続に失敗する」ときは、まずローカルポートを確認し、VLESS、VMess、TLS のパラメータを先に変更しないでください。層ごとに調べれば、入口の問題をサーバー側の問題と取り違えずに済みます。

最初にコアとローカル待受を確認する

まず v2rayN で設定を1つ選択してコアを起動し、メイン画面またはログ欄に起動失敗、ポート使用中、設定解析エラーが表示されていないか確認します。サブスクリプションは設定の取得元にすぎません。サブスクリプションの更新に成功しても、コアが動作しているとは限らず、システムプロキシが正しいポートを指しているとも限りません。

続いて「設定」→「パラメーター設定」を開き、現在の HTTP と SOCKS の待受ポートを記録します。バージョンによって統合された混合ポートを使う場合も、画面に表示された実際の値を記録してください。待受アドレスは通常 127.0.0.1 にします。これは本機からの接続だけを受け付けるアドレスです。LAN からの接続が明確に必要な場合を除き、切り分けのためにすべてのネットワークアダプターへ公開されるアドレスへ変更しないでください。

1. ポートを記録する

   v2rayN の「設定」→「パラメーター設定」を開き、HTTP、SOCKS、または混合待受ポートを書き留めます。古いチュートリアルから番号を推測しないでください。

2. プロセスを確認する

   選択した設定を起動し、コアの終了通知が繰り返し表示されていないことを確認します。ログでは最後の行だけでなく、最初に出たエラーを特定してください。

3. 待受を確認する

   PowerShell で Get-NetTCPConnection を実行し、対象ポートが Listen 状態であることを確認して、対応するプロセス ID を記録します。

4. 入口をテストする

   Test-NetConnection を使ってループバックアドレスと HTTP ポートをテストします。TCP テストに失敗した場合は、まず待受の問題を解決してください。

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -in 10808, 10809 } |
  Select-Object LocalAddress, LocalPort, OwningProcess

Test-NetConnection 127.0.0.1 -Port 10809

TcpTestSucceeded が True でも、ポートが TCP 接続を受け付けていることしか証明できません。ノードのプロトコル、サーバーアドレス、ルーティング規則が正しいとは限らないため、明示的にプロキシを指定したリクエストで完全な経路を検証する必要があります。検索結果に対象ポートがない場合は、v2rayN のログに戻ってコアの起動問題を確認します。ポートが別のプロセスに使用されている場合は、Get-Process -Id プロセスID でプログラムの種類を確認できます。

ブラウザーは「システムに従う」と「個別設定」を分けて確認する

システムのネットワーク設定を使う多くのデスクトップブラウザーは Windows のプロキシを読み取りますが、ブラウザー拡張機能、企業ポリシー、起動引数、ブラウザー独自のネットワーク設定によって上書きされる場合があります。切り分けでは、まず制御元を1つに絞ります。Windows のシステムプロキシに従うか、ブラウザーでローカルプロキシを明示的に指定し、拡張機能とシステム設定が同時に接続先を書き換えないようにしてください。

v2rayN のトレイメニューでシステムプロキシ関連の項目を選ぶときは、現在の用途に合ったモード、たとえばシステムプロキシの自動設定が選ばれているか確認します。続いて Windows の「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシまたは自動構成スクリプトが現在のクライアント設定を反映しているか確認してください。v2rayN のモードによってシステム設定への書き込み方法が異なるため、アドレスを手動で重ねて設定しないでください。

1つのブラウザーだけに問題がある場合は、まず一時的なブラウザープロファイルを作成するか、プロキシ切り替えを担当する拡張機能を無効にして再テストします。プライベートウィンドウは通常、システムプロキシを迂回しません。そのためキャッシュやログイン状態の切り分けには使えますが、プロキシ入口が復旧した証明にはなりません。ブラウザーのセキュア DNS はドメイン解決を担当するもので、HTTP や SOCKS プロキシとは別の仕組みです。

1. 制御元を統一する

   ブラウザー内でプロキシ切り替えを担当する拡張機能を一時的に無効にし、テスト用の起動引数を削除して、Windows のシステムプロキシだけを制御経路として残します。

2. システム設定を確認する

   Windows の「設定」→「ネットワークとインターネット」→「プロキシ」を開き、アドレス、ポート、自動構成の状態が v2rayN の現在のモードと対応しているか確認します。

3. ブラウザーを再起動する

   すべてのブラウザープロセスを完全に終了してから再起動し、起動時に読み込んだ古いプロキシ設定を使い続けないようにします。

4. 1つずつ比較する

   まず通常の HTTPS ページを1つテストし、次に以前失敗したドメインをテストします。後者だけ失敗する場合は、ルーティング、DNS、SNI、サーバー設定を調べます。

ターミナルのプログラムにはプロキシ環境変数を明示的に設定する

PowerShell、コマンドラインのダウンロードツール、パッケージマネージャー、開発ツールは、Windows のシステムプロキシを必ずしも読み取りません。大文字の環境変数だけを認識するプログラムもあれば、大文字と小文字の両方を認識するもの、独自の設定ファイルでプロキシを指定する必要があるものもあります。システムプロキシを有効にしてもターミナルが直接接続するのは、こうしたプログラムではよくある現象です。

まず curl.exe の --proxy 引数を使って明示的にテストします。これにより、ツールがシステム設定を読み取るかどうかに左右されず、ローカル入口から対象サイトまでのリクエスト経路を直接検証できます。HTTP ポートの例は 10809、SOCKS ポートの例は 10808 ですが、実際のテストでは v2rayN の現在の値に置き換えてください。

curl.exe --proxy http://127.0.0.1:10809 https://example.com/ --max-time 10

curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/ --max-time 10

socks5h の h は、対象ホスト名の解決をプロキシ側で行うことを示します。本機の DNS とプロキシ側の解決結果を比較するのに適しています。HTTP と SOCKS のテストがどちらも成功し、--proxy なしのコマンドだけが失敗または直接接続する場合、問題はターミナルの接続方法にあります。サブスクリプション設定をさらに変更する必要はありません。

現在の PowerShell セッションで複数のツールにプロキシを試させる場合は、環境変数を一時的に設定できます。セッションを閉じると変数は消えるため、切り分けに適しています。ユーザー単位またはシステム単位の環境変数へ書き込む前に、対象ツールがその変数をサポートしているか、イントラネットアドレスへどのような影響があるか確認してください。

$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
$env:ALL_PROXY = "socks5h://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1"

Get-ChildItem Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY

接続成功後にルーティングと DNS を確認する

明示的なプロキシリクエストがコアに到達しているのに、特定のサイトだけ失敗する場合、調査の焦点を「アプリが接続できているか」から「コアがどのように処理しているか」へ移します。v2rayN が管理するルーティング規則は、ドメイン、IP、プロトコルに応じて直接接続とプロキシ接続を選択します。VLESS と VMess はノードのプロトコル設定の一部であり、ターミナルが Windows のシステムプロキシを読み取るかどうかを決めるものではありません。

ログを確認するときは、同じテストリクエストに対応させます。まずテスト時刻を記録し、1つのリクエストだけを実行して、対象ドメイン、適用された規則、アウトバウンドエラーを確認してください。ログにそのリクエストがまったくない場合、通信はまだコアに入っていません。リクエストがあり、直接接続が明示されている場合はルーティング規則を確認します。プロキシ接続が選ばれた後に解決またはハンドシェイクのエラーが出る場合は、ノードのパラメータと DNS を調べます。

• サブスクリプションの更新は設定一覧を取得するだけで、その中の各設定で現在接続を確立できることを証明するものではありません。
• システムプロキシは一部のアプリがローカル入口を見つける方法を決め、ルーティング分岐はコアに入った通信の行き先を決めます。
• 本機の DNS による先行解決とプロキシ側の解決では異なる結果になる場合があります。SOCKS をテストするときは socks5 と socks5h を比較してください。
• 規則を変更した後は、単一のリクエストを再実行し、新しいログで確認します。ポート、DNS、ノード、ルーティングを同時に変更しないでください。

TUN を検討するタイミング

TUN は、HTTP や SOCKS のプロキシ設定に対応していないアプリを対象にしたい場合や、より多くの通信を統一的に取り込む場合に適しています。仮想ネットワークインターフェースを通じて通信の取り込み方法を変えるため、通常はシステムプロキシより広い範囲をカバーします。一方で、ルーティングテーブル、DNS、管理者権限、他の VPN 系接続との調整が必要です。

問題がプロキシ引数に対応した1つのターミナルツールだけに発生している場合は、まずそのツールを設定するか環境変数を使うほうが、動作を確認しやすく元に戻すのも簡単です。複数のアプリがシステムプロキシをまったく読み取らず、個別設定の負担が大きい場合に TUN を検討します。TUN を、ローカルポートが待ち受けていない問題、ノードのハンドシェイク失敗、誤ったルーティング規則の代替策にしないでください。

変更を最小限にして再確認する

一度に1つの条件だけを変更すれば、どの手順で接続が復旧したか判断できます。最も安全な順序は、ローカル待受、明示的なプロキシテスト、アプリの接続設定、ルーティングと DNS、最後に TUN です。各手順でポート、コマンド結果、ログの時刻を記録し、画面上のスイッチ状態だけで判断しないでください。

1. v2rayN の「設定」→「パラメーター設定」で現在の待受アドレスとポートを記録し、コアが起動していることを確認します。
2. Get-NetTCPConnection と Test-NetConnection で、ポートが実際に待ち受けていることを確認します。
3. curl.exe --proxy を使い、HTTP または SOCKS の入口をそれぞれテストします。タイムアウトは10秒に設定します。
4. ブラウザーのプロキシ制御元を1つだけ残し、完全に終了してから再起動し、他のブラウザーと比較します。
5. ターミナルはコマンド引数または一時的な環境変数で接続し、Windows のシステムプロキシを自動的に読み取るとは想定しません。
6. リクエストがコアに入ったことを確認してから、ログに基づいてルーティング分岐、DNS、ノードのプロトコル、TLS を確認します。
7. 複数のアプリで個別にプロキシを設定できず、対象範囲を広げる必要がある場合に限り、TUN を設定して検証します。