v2rayNのシステムプロキシが効かないときの対処法｜ブラウザーは開けるのにターミナルがプロキシを使わない原因

この記事の要点

ブラウザーでアクセスできても、ターミナルがプロキシを使っているとは限りません。この記事ではWindows版v2rayNを例に、実際の待ち受けポートを確認し、プロキシを明示したリクエストで問題を切り分けてから、ブラウザー設定とターミナルの環境変数をそれぞれ見直します。Webページは開くのにコマンドラインがタイムアウトする場合や、システムプロキシを有効にしても効果がない場合に役立ちます。クライアントの再インストールやサブスクリプションの変更から始める必要はありません。

1. システムプロキシとターミナルのプロキシは別の経路

v2rayNのシステムプロキシ機能は、主にOSの設定にローカルプロキシのアドレスを書き込み、その設定を参照するアプリで使えるようにするものです。PC上のすべてのネットワーク接続を横取りする機能ではありません。ブラウザーはシステム設定を参照する場合もあれば、拡張機能や組織のポリシーによって上書きされる場合もあります。一方、コマンドラインツールは環境変数や独自の設定ファイル、起動オプションだけを参照することがあります。

アプリのプロキシ設定ローカル待ち受けポートコアのルーティング判定アウトバウンド接続接続先サービス

この経路でシステムプロキシが担うのは、アプリに接続先の入口を知らせることです。リクエストがコアに届いた後は、ルーティングルールに従って直結、プロキシ経由、またはブロックのいずれかが決まります。そのため、「クライアントがリクエストを受け取った」ことと「リクエストがリモートノード経由で送信された」ことは別です。ブラウザーでアクセスできても、直結ルールが適用された可能性があり、それだけではノードが使える証拠になりません。

システムプロキシ：対応アプリにプロキシアドレスを提供します。すべてのターミナルツールが自動で使うとは限りません。
ローカルインバウンド：コアが待ち受けるHTTP、SOCKS、または混合プロトコルの入口です。アドレスとプロトコルを一致させる必要があります。
ルーティング：リクエストがコアに入った後のアウトバウンド先を選択します。もともと直結するアプリを自動的にプロキシ経由にする機能ではありません。
TUNモード：別のトラフィック取り込み方式です。入口を切り分けやすくするため、今回はいったん無効にしてテストします。テスト後は元の設定に戻してください。

2. 10808・10809番ポートは古い手順を鵜呑みにせず確認

古い設定では、10808をSOCKS、10809をHTTPの入口として使うことがあります。一方、設定によっては10808だけで混合プロトコルの入口を提供する場合もあります。ポート番号だけでプロトコルは判断できず、アップデートや移行、手動変更で番号が変わっていることもあります。v2rayNの「設定」→「パラメーター設定」でローカル待ち受け関連の項目を確認し、起動ログと照らし合わせて実際の値を確認してください。画面によって項目名が多少異なる場合があります。

127.0.0.1

この記事で使うループバックアドレス

10808

確認対象となるSOCKSまたは混合プロトコル入口の例

10809

確認対象となる独立したHTTP入口の例

次のPowerShellコマンドは、例として挙げた2つのポートを確認するだけで、設定は変更しません。実際のポート番号が異なる場合は置き換えてください。出力のOwningProcessは待ち受けプロセスのIDです。Get-Process -Id プロセスIDでプロセス名を確認できます。実際に待ち受けているのは通常コアのプロセスで、画面側のプロセスとは限りません。

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

確認結果	考えられる状態	次の手順
どちらのポートも待ち受けていない	コアが起動していないか、別のポートを使用中	起動ログと実際の設定値を確認し、ターミナルの変数はまだ変更しない
10808だけが待ち受けている	単一プロトコル、または混合プロトコルの入口の可能性	インバウンドの種類を確認してから、HTTPまたはSOCKSでテスト
待ち受けプロセスが現在のコアではない	別のプログラムまたは残存プロセスがポートを使用中	プロセスの用途を確認してから対処し、むやみに終了しない
IPv6のループバックアドレスだけで待ち受けている	明示したIPv4アドレスと一致しない	待ち受けアドレスを確認するか、対応するIPv6ループバックアドレスでテスト

3. プロキシを明示したリクエストでターミナルの問題を切り分ける

まず環境変数を使わず、コマンドにプロキシアドレスを直接指定します。Windows PowerShellではcurlが別のコマンドのエイリアスになっている環境があるため、curl.exeを明示して実行してください。最初にcurl.exe --versionを実行し、ツールが使えることを確認します。以下の接続先はテスト方法を示す例です。ブラウザーで確認中のHTTPS公開URLに置き換えると、異なるルーティング先への接続を避けられます。

# 10809がHTTPの入口だと確認できた場合のみ実行
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy http://127.0.0.1:10809 https://example.com/ -o NUL

# 10808がSOCKS5に対応していると確認できた場合のみ実行
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy socks5h://127.0.0.1:10808 https://example.com/ -o NUL

--noproxy ""を指定すると、今回のテストではプロキシ除外リストが空になり、既存のNO_PROXYによる意図しない直結を防げます。HTTPの混合入口が実際には10808の場合は、1つ目のコマンドのポートを10808に変更してください。10909をそのまま使わないでください。socks5hでは接続先ドメインの名前解決をSOCKSプロキシ側で行います。socks5では通常ローカル側で名前解決するため、解決経路が異なります。

まずローカル接続を確認。詳細出力に、接続先として指定したループバックアドレスとポートが表示されることを確認します。接続先の公開IPアドレスへ直接接続している場合は、プロキシを経由していません。
次にプロキシとの接続を確認。HTTPプロキシ経由でHTTPSサイトにアクセスすると、通常はCONNECTトンネルの確立が表示されます。SOCKSの場合は、対応する接続処理が表示されます。
最後に応答を確認。HTTPステータスコードが返れば、少なくともサーバーから応答を受信しています。403などの応答は、ローカルポートの障害とは限らず、接続先サービスが正常に使えることを意味するものでもありません。
同時刻のコアログも確認。接続先ドメインとアウトバウンドの選択内容を照らし合わせます。ログにアウトバウンドが明確に記録されている場合に限り、想定したノードを経由したかどうかをさらに判断できます。

プロキシを明示したリクエストは成功するのに通常のコマンドが失敗する場合は、まずツールがプロキシ設定をどう読み込むか確認します。明示的な指定でも失敗するなら、ローカルの入口、ノードへの接続、ルーティングを確認してください。環境変数をむやみに追加しないでください。テストでは一度に変更する条件を1つに絞り、コマンド、実行時刻、結果を記録します。「Webページが開かない」とだけ記録するより、再現しやすくなります。

4. ブラウザーのシステムプロキシ、拡張機能、除外ルールを確認

v2rayNのタスクトレイメニューで「システムプロキシ」の状態を確認します。「システムプロキシを自動設定」は通常、クライアントが現在のプロキシ設定を書き込むことを意味し、PACファイルが有効になったという意味ではありません。「システムプロキシを解除」は該当する設定を取り消します。「システムプロキシを変更しない」は設定を書き換えないだけで、既存のシステムプロキシを無効にするものではありません。

Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、手動プロキシのアドレスとポートが現在のHTTPまたは混合プロトコルの入口と一致しているか確認します。セットアップスクリプトが有効になっていないかも確認してください。
プロキシを制御するブラウザー拡張機能を一時的に無効にします。拡張機能が古いポートを参照していると、システム設定が正しくても、そちらがまったく使われない場合があります。
ブラウザー独自の手動プロキシ設定も確認します。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」を開き、システムプロキシを使用する設定になっているか確認できます。組織で管理されているブラウザーでは、ポリシーによる制限も確認してください。
ブラウザーを終了して再起動し、同じ接続先で再テストします。その際、新しいリクエストがコアログに記録されるか確認してください。既存の接続やキャッシュされたページは、新しい設定が反映された証拠にはなりません。

特定の拡張機能を有効にした場合だけブラウザーでアクセスできるなら、まず拡張機能が実際に使うプロトコルとポートを記録し、システム設定と比較してください。多くの場合、2つの接続経路が異なるのであり、システムプロキシのボタン自体が機能していないわけではありません。ブラウザーとコマンドラインで異なるドメインをテストした場合は、まず接続先をそろえてからアウトバウンドの結果を比較してください。

5. ツールの対応状況に合わせてターミナルの環境変数を設定

多くのターミナルツールはHTTP_PROXY、HTTPS_PROXY、またはALL_PROXYを参照します。ただし、対応する変数や優先順位、設定ファイルの扱いはツールによって異なります。まず現在のプロセスから見える値を確認し、システム全体の環境変数はすぐに変更しないでください。次のPowerShellコマンドは値を表示するだけです。出力にユーザー名、パスワード、内部アドレスが含まれる場合は、共有前に削除してください。

Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

以下は現在のPowerShellセッションに設定する例です。10809がHTTPプロキシに対応していると確認済みであることが前提です。すでに変数が設定されている場合は、元の値を記録してから試し、終了後に戻してください。Windowsの環境変数名は通常、大文字と小文字を区別しません。ほかのシェルでは大文字と小文字の違いに注意してください。たとえばcurlでは、HTTPプロキシ変数に小文字のhttp_proxyを使用します。

$env:http_proxy = 'http://127.0.0.1:10809'
$env:https_proxy = 'http://127.0.0.1:10809'

curl.exe -v --connect-timeout 10 --max-time 30 https://example.com/ -o NUL

https_proxyの値にhttp://を使うことは可能です。ここで指定するプロトコルは、接続先のWebページではなく「ツールからプロキシへの接続方法」を表します。HTTPSサイトにアクセスする際、ツールは通常のHTTPプロキシを通じてCONNECTトンネルを確立し、その中で接続先とTLS通信を行えます。これを機械的にhttps://127.0.0.1:10809へ変更すると、TLSに対応していないローカルプロキシとのハンドシェイクを試みて失敗することがあります。

NO_PROXY：接続先ドメインやドメインの末尾、または*が含まれていると、リクエストがプロキシを迂回することがあります。まず元の値を保存してから、対象を絞ってテストしてください。必要な社内ネットワーク向けの例外を削除したままにしないでください。
ALL_PROXY：一部のツールは汎用プロキシの指定に使います。古い値が残っていると切り分けの妨げになる場合があります。優先順位はツールのドキュメントを確認してください。
子プロセスへの継承：現在のターミナルから起動したプログラムは、通常その環境を引き継ぎます。一方、すでに起動しているエディターの統合ターミナルには、後から変更したシステム変数が反映されないことがあります。
独立した実行環境：WSLやコンテナは独自のネットワーク環境を使います。その中の127.0.0.1がWindowsホストを指すとは限りません。実際のネットワークモードを確認してテストし、ローカルのアドレスをそのまま流用しないでください。

テスト前に変数が設定されていなかった場合は、次のコマンドで今回のセッションの設定を解除できます。元から値があった場合は削除せず、元の値に戻してください。このPowerShellウィンドウを閉じれば、セッション単位の変更も終了します。動作を確認してから恒久的な設定を検討し、使用するコマンドラインツールのプロキシオプションも個別に確認してください。システム全体の変数がほかの作業に影響するのを防げます。

Remove-Item Env:http_proxy -ErrorAction SilentlyContinue
Remove-Item Env:https_proxy -ErrorAction SilentlyContinue

6. エラーが発生した段階を特定し、すべてのタイムアウトをノードの問題と決めつけない

以下にはcurlでよく見られるエラーの一部を掲載しています。アドレスや所要時間、TLSバックエンドに関する表示は環境によって異なります。まずエラーがローカルの入口への接続、プロキシとの接続、接続先へのアクセスのどの段階で発生したかを判断してから、変更する設定を決めてください。

エラー：`curl: (7) Failed to connect to 127.0.0.1 port 10809`

原因：ローカルのTCP接続を確立できていません。ポートが待ち受けていないか、アドレスが一致していない場合によく発生します。対処法：待ち受け状況を確認し、現在のコアと実際のポート番号を照合してから、プロキシを明示したリクエストを再試行します。リモートノードを先に切り替える必要はありません。

エラー：`curl: (5) Could not resolve proxy`

原因：プロキシサーバー名を名前解決できません。環境変数のホスト名が間違っているか、余分な文字が含まれている可能性があります。対処法：環境変数の値全体を確認し、確認済みのループバックアドレスを使って明示的にテストします。プロキシアドレスと接続先ドメインの名前解決を切り分けてください。

エラー：`curl: (28) Connection timed out`

原因：いずれかの接続段階でタイムアウトしました。この行だけでは、ノード、DNS、接続先サービスのどれが原因か判断できません。対処法：-vで最後に完了した処理と同時刻のコアログを確認します。まずローカル接続が確立したかを判断し、その後のアウトバウンドを調べてください。

エラー：`curl: (35) SSL connect error`

原因：TLS接続の確立に失敗しています。プロトコルの設定ミス、中間機器、接続先とのネゴシエーションなどが考えられます。対処法：まずローカルプロキシURLのプロトコルを確認し、次にシステム時刻とTLSに関する詳細なメッセージを調べてください。証明書検証の無効化を通常の対処法にしないでください。

一時的にログの詳細度を上げると、ルーティングや接続段階の切り分けに役立ちます。ただし、ログにはアクセス先のドメインやノードのアドレスが含まれることがあります。調査後はログレベルを元に戻し、共有する場合は必要な箇所だけ残して、サブスクリプションURL、認証情報、個人のアクセス履歴を伏せてください。

7. よくある質問と設定の復元チェック

ブラウザーもcurlでプロキシを明示した場合も正常なのに、通常のコマンドが失敗するのはなぜですか？

入口と基本的な接続は確認できています。次に、そのツールが環境変数を参照するか、独自のプロキシ設定がないか、NO_PROXYが接続先に適用されていないかを調べてください。まず同じターミナルでテストし、そのターミナルから実際のツールを起動して、環境の引き継ぎの違いを避けます。

ポートを変更したらブラウザーは直ったのに、ターミナルが古いポートに接続し続けるのはなぜですか？

システムプロキシとターミナルの環境変数は別々に設定されています。現在のターミナルでプロキシ変数を再確認し、実際のポート番号に変更してください。ツールが設定ファイルを使っている場合は、該当する項目も変更します。長時間起動したままのプロセスは再起動が必要なことがあります。

10808があれば、10809も必ず開く必要がありますか？

いいえ、必ずしも必要ではありません。10808が混合プロトコルの入口なら、HTTPとSOCKSのクライアントがそれぞれのプロトコルで同じポートに接続できます。まず現在のインバウンドが対応するプロトコルを確認してからテストしてください。古い手順に合わせるためだけに、待ち受け設定を増やす必要はありません。

クライアントを終了した後、Webページが開けなくなった場合はどうすればよいですか？

Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、停止したローカルポートが指定されたままになっていないか確認して、使わないプロキシ設定を解除してください。ターミナルの環境変数もテスト前の値に戻し、ブラウザー拡張機能も想定した状態に戻します。

最後に3点を確認します。プロキシを明示したリクエストが正しいローカル入口に接続できること、ブラウザーとターミナルがそれぞれ想定したプロキシ設定を使うこと、コアログのルーティング先が意図したアウトバウンドと一致することです。これにより、「システムプロキシの設定に成功した」「アプリが実際にプロキシを使っている」「リクエストが想定したアウトバウンドを選んだ」を区別でき、次回の問題発生時に再インストールから始めずに済みます。

実際の待ち受けアドレス、ポート番号、プロトコルを記録し、繰り返し実行できるテストコマンドを1つ残します。
調査中に無効にした拡張機能、変更した環境変数、一時的に上げたログレベルを元に戻し、効果を確認できた設定だけを残します。
まだ解決しない場合は、ツール名、コマンド全文、エラーが発生した段階、機密情報を伏せたログをまとめ、同じ接続経路をさらに調べます。