この記事では、Windows版v2rayNを例に、「システムプロキシを設定したのに、ブラウザーやターミナルから接続できない」場合の確認方法を解説します。まず明示的にプロキシを指定してローカルの接続先を検証し、次にブラウザーの拡張機能、自動構成スクリプト、ターミナルの環境変数を確認します。アプリのプロキシ設定、ローカルポートの待ち受け、コアの出站処理、ルーティングのどこに問題があるかを切り分け、ノードをむやみに変更せずに原因を特定できます。
1. システムプロキシ・ルーティング・TUNの違い
v2rayNの「システムプロキシ」は、OSにプロキシ設定を書き込む機能であり、すべての通信を引き受けるものではありません。アプリがシステム設定を参照して初めて、リクエストがローカルプロキシポートに送られます。通常、ブラウザーはシステムプロキシに対応しています。一方、コマンドラインツールがシステム設定、環境変数、独自の設定ファイルのどれを参照するかは、ツールによって異なります。
切り分けの際は、仮想ネットワークアダプターによる通信の取り込みがシステムプロキシの問題を見えにくくしないよう、まずTUNモードをオフにします。ほかのトンネルや企業ネットワーク用ソフトウェアを使っている場合は、状態を記録し、設定をすぐに削除しないでください。この記事に記載するポート番号はテスト用の例です。v2rayNに現在表示されている待ち受けポートに置き換えてください。
| 設定レイヤー | 実際の役割 | これだけでは確認できないこと |
|---|---|---|
| システムプロキシ | システム設定に従うアプリに、使用するプロキシの接続先を指定する | すべてのターミナルやバックグラウンドアプリがプロキシを使っていること |
| ローカルの受け入れポート | ループバックアドレスと指定ポートでHTTPまたはSOCKSリクエストを受け付ける | リモートサーバーへの接続が成功していること |
| コアのルーティング | 受信したリクエストの出先を、直結・プロキシ・ブロックから選択する | 受信したすべてのリクエストがリモートプロキシ経由になること |
| TUNモード | 仮想ネットワークアダプターで対象のネットワーク通信を取り込む | アプリがシステムプロキシを正しく参照していること |
2. ローカルポートを確認して、プロキシを明示してテスト
まずv2rayNの「設定」→「パラメータ設定」でローカルの待ち受け設定を確認し、メイン画面下部に表示されるポート情報を見ます。バージョンによってはHTTPとSOCKSの専用ポートや、両方に対応する混合ポートがあります。名称や画面構成も異なる場合があります。混合ポートは対応するプロトコルの両方を受け付けますが、SOCKS専用ポートをHTTPプロキシとして使うことはできません。
この2つの番号は、すべてのバージョンで共通する既定値ではなく、両方を同時に待ち受けさせる必要もありません。以下は、127.0.0.1:10808がHTTPとSOCKSに対応していることを確認済みとして、PowerShellで実行します。環境によっては同名のエイリアスによる引数の違いがあるため、curlではなくcurl.exeを使います。
# TCPポートが接続を受け付けるか確認
Test-NetConnection 127.0.0.1 -Port 10808
# 待ち受けプロセスを確認し、現在のコアに属しているか確認
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
# HTTPプロキシを明示し、除外リストにはローカルアドレスのみ指定
curl.exe --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com
# SOCKSを明示し、接続先のドメイン名解決をプロキシに任せる
curl.exe --proxy socks5h://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.comTcpTestSucceeded : Trueで確認できるのは、TCPポートに接続できることだけです。HTTPプロキシのテストで200 Connection establishedが返っても、CONNECTトンネルの確立が許可されたことを示すにすぎません。その後のTLS処理と接続先サイトの応答も確認してください。接続先から403や405が返った場合も、応答元が接続先サイト、プロキシサービス、中間ネットワーク機器のどれかを見極める必要があります。ステータスコードだけでシステムプロキシの不具合と判断しないでください。
結論：プロキシを明示したリクエストが成功したら、アプリの設定を確認
プロキシを明示したリクエストで接続先から応答があり、通常のブラウザーではアクセスできない場合は、ブラウザーが別の接続先を使っていないかを優先的に確認します。この段階でサブスクリプション、通信プロトコル、リモートポートを変更する必要はありません。
3. ブラウザーで効かない場合：拡張機能と個別のプロキシ設定を確認
ブラウザーの拡張機能がシステムプロキシを上書きすることがあります。あるウィンドウでは接続でき、別のウィンドウではできない場合は、ノードの問題と決めつけず、ブラウザープロファイルと拡張機能の状態を比較してください。シークレットウィンドウも「拡張機能が無効な環境」とは限りません。シークレットウィンドウでの実行を許可された拡張機能は、引き続き動作する場合があります。
-
システムプロキシを有効にする
Windows版v2rayNのメイン画面下部にある「システムプロキシ」メニューから「システムプロキシを自動設定」を選択します。これはクライアントがシステムプロキシを書き込む操作を指し、PACスクリプトモードと同じ意味ではありません。
-
システムの接続先を確認
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートを確認します。ループバックアドレスはこのPCを指し、ポートは前の手順で接続を確認したHTTPまたは混合ポートと一致している必要があります。
-
プロキシ拡張機能を無効にする
Chromeの「拡張機能」→「拡張機能を管理」から、プロキシを制御する拡張機能を一時的に無効にします。Edgeでは「拡張機能」→「拡張機能の管理」から操作できます。関連するブラウザーのプロセスを終了してから再起動し、同じテスト用URLにアクセスしてください。
-
個別設定を確認
Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」で「システムのプロキシ設定を使用」を選択できます。手動プロキシが選択されている場合は、設定されたポートを確認してください。Windowsの設定変更に自動で追従するとは限りません。
システムプロキシのアドレスが設定直後に変更される場合、別のプログラムや組織のポリシーが管理している可能性があります。重複して起動しているプロキシプログラムを終了して、再度確認してください。組織の管理下にあるデバイスでは、管理者にポリシーを確認してください。このPCのブラウザーからプロキシに接続するために、待ち受けアドレスを0.0.0.0に変更する必要はありません。また、ファイアウォール全体を無効にすることも、最初に試す方法ではありません。
4. PACモード：スクリプトのアドレスと戻り値を確認
PACは、自動プロキシ構成スクリプトです。ブラウザーはスクリプト内のFindProxyForURL(url, host)を呼び出し、戻り値に応じてプロキシを使うか直結するかを決めます。これはv2rayNのコア内にあるrouting.rulesとは別のレイヤーのルールです。PACによってリクエストがコアに届かないこともあります。コアのルーティングが処理できるのは、ローカルの受け入れポートまで届いたリクエストだけです。
- スクリプトが有効か確認：Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」→「セットアップスクリプトを使う」でアドレスを確認します。手動のシステムプロキシだけを使う場合は、元のアドレスを記録してから一時的にスクリプトをオフにしてテストします。
- スクリプトにアクセスできるか確認：スクリプトの接続先がローカルポートの場合、対応するサービスがまだ動作しているか確認します。古いクライアントの終了後に残ったスクリプトのアドレスは、すでに読み込めなくなっている可能性があります。
- 戻り値を確認：
DIRECTは直結、PROXY 127.0.0.1:10808は指定したHTTPプロキシに接続することを示します。スクリプトが古いポートを参照していると、現在のコアが正常に動作していても接続に失敗します。 - フォールバック処理を確認：
PROXY 127.0.0.1:10808; DIRECTには直結へのフォールバックが含まれています。プロキシを利用できないときにブラウザーが直結を試すため、一部のサイトにはアクセスできる場合があります。
5. ターミナルで効かない場合：環境変数とツールの設定を確認
ブラウザーでは使えるのにターミナルでは使えない場合、プロキシ設定の参照元が異なることがよくあります。多くのコマンドラインツールはWindowsのユーザープロキシ設定を自動では参照せず、独自の設定ファイルを使うツールもあります。まず2章のプロキシを明示するコマンドでテストし、その後、必要であれば現在のターミナルセッションに環境変数を設定してください。すぐにシステム全体の環境変数を変更しないでください。
# 現在のPowerShellプロセスが引き継いだプロキシ環境変数を確認
Get-ChildItem Env: |
Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }
# 現在のセッションと、そこから起動する子プロセスで使うプロキシを設定
$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"
# --proxyを指定せず、curl.exeが現在の環境変数を参照するか確認
curl.exe --connect-timeout 10 --max-time 20 -I https://example.comhttps_proxyは「HTTPS接続先に使うプロキシ」を表しますが、値にはhttp://を指定できます。HTTP CONNECTでトンネルを確立するためです。接続先がHTTPSだからといって、ローカルの接続先をhttps://に変更する必要はありません。環境変数がサポートされているか、どの名前に対応しているかは、使用するツールのドキュメントで確認してください。curlはHTTPプロキシ用環境変数の大文字・小文字の扱いに独自のルールがあるため、複数のOSで使うスクリプトでは小文字のhttp_proxyを優先してください。
| 確認項目 | よくある問題 | 対処方法 |
|---|---|---|
NO_PROXY | 接続先のドメイン名または*が含まれ、プロキシがバイパスされている | テスト用セッションでは必要なローカルアドレスだけを残して再試行する |
ALL_PROXY | 古いSOCKSポートを参照している | プロトコルとポートを確認し、複数の変数が異なる接続先を指さないようにする |
| ターミナルのプロセス | システム変数を変更する前に起動していた | ターミナルとそのホストプログラムを再起動するか、現在のセッションに直接設定する |
| ツールの設定ファイル | ツール独自のプロキシ設定が、想定している設定を上書きしている | ツールで有効な設定を確認し、プロキシを明示する引数で比較テストする |
WSL、コンテナー、リモートターミナルにはそれぞれ独自のネットワーク環境があります。その中の127.0.0.1がWindows上の待ち受けポートを指すとは限りません。これらの環境での接続失敗を、Windowsのシステムプロキシの問題と判断しないでください。まずWindows上で基本の接続テストを行い、その後、仮想ネットワークとホストのアドレスを個別に確認します。このために、すべてのネットワークインターフェイスから接続できるようプロキシポートを公開しないでください。
上記の設定は、現在のPowerShellセッションと、そこから起動した子プロセスにだけ適用されます。セッションを閉じれば一時設定は終了します。元のセッションでプロキシ環境変数を使用している場合は、元の値を記録し、テスト後に復元してください。
6. エラーとログから残りの問題を切り分ける
プロキシを明示しても接続できない場合は、「ローカルの待ち受け→プロトコルの一致→リモート接続→接続先の応答」の順に確認します。以下はcurlで表示される可能性のあるエラーの例です。実際の文言はバージョンやOSによって異なります。エラーコードは原因の範囲を絞るのに役立ちますが、1つのエラーだけで原因を特定できるとは限りません。
curl: (7) Failed to connect to 127.0.0.1 port 10808
原因：ローカルのTCP接続が確立できていません。コアが起動していない、ポートの指定が誤っている、ローカル接続がブロックされている場合によく発生します。
対処方法：ポートの待ち受け状態を確認し、待ち受けプロセスを特定してから、v2rayNのコア起動ログを確認します。まずリモート側のプロトコルを変更するのは避けてください。
curl: (5) Could not resolve proxy
原因：プロキシアドレスのホスト名を解決できないか、プロキシ環境変数の値の形式に誤りがあります。
対処方法：ローカルでのテストではhttp://127.0.0.1:10808を明示し、変数に引用符、空白、無効なホスト名が含まれていないか確認してください。
curl: (28) Connection timed out
原因：接続またはデータ転送がタイムアウトしています。プロキシの接続口、リモートサーバー、接続先の応答のいずれかで処理が止まっている可能性があります。
対処方法：-vを追加して最後に完了した処理を確認し、同じ時刻のコアログと照らし合わせて、ローカルの接続先に到達できないのか、リモート側でタイムアウトしているのかを切り分けます。
curl: (60) SSL certificate problem
原因：証明書の検証に失敗しています。システム時刻、証明書の信頼チェーン、ネットワーク上のTLS検査が関係している可能性があります。
対処方法：システム時刻と証明書の入手元を確認してください。証明書検証のスキップを恒久的な対策にせず、このエラーをシステムプロキシが効かない問題と決めつけないでください。
ログに新しい記録がないからといって、リクエストがコアに届いていないとは限りません。現在のログレベルでは、アクセスごとに記録されない場合があります。v2rayNの「設定」→「パラメータ設定」でログ関連の項目を確認し、一時的に詳細なログを有効にしてコアを再起動してから、実行時刻を記録してテストを1回行います。完了後は元のログレベルに戻してください。ログを共有する前に、サブスクリプションのURL、認証情報などの機密情報を削除してください。
結論：一度に変更する設定は1つだけ
テスト対象を同じにして、プロキシを明示した場合、ブラウザーのシステムプロキシ、ターミナルの環境変数の3通りの結果を順に記録します。プロキシを明示しても失敗する場合に限り、コアとリモート接続の切り分けを続けます。成功する場合は、まずアプリがプロキシ設定を参照する経路を修正してください。
- プロキシを明示すると成功し、ブラウザーでは失敗：拡張機能、個別のプロキシ設定、PAC、組織のポリシーを確認します。
- ブラウザーでは成功し、ターミナルでは失敗：環境変数、プロセス間の継承、ツール独自の設定を確認します。
- ポートには接続できるが、プロキシ経由のリクエストは失敗：受け入れ側のプロトコル、出先のログ、サーバー設定、DNSを確認します。
- リクエストには接続できるが、想定した経路で通信できない：PACが直結を返していないか、コアのルーティングが実際にどの出先を選んでいるかを確認します。