V2Rayのシステムプロキシが機能しないときの対処法｜ブラウザーとコマンドラインを個別に確認

1. システムプロキシ・ローカル待ち受け・プロキシ経由の接続を区別する

v2rayN に「システムプロキシを自動設定」と表示されても、クライアントがシステムプロキシ設定を書き込むモードを選んでいることを示すだけです。すべてのアプリがその設定を使うことや、ノードへの接続が成功していることまでは保証されません。v2rayN は設定を管理するデスクトップクライアントで、実際の接続は起動中の V2Ray や Xray などのコアが処理します。アプリの通信がローカルポートに届いているか、コアが外部へ接続できているかを分けて確認すれば、問題箇所に関係のないサブスクリプション更新を繰り返さずに済みます。

システムプロキシは、PC全体の通信を一括して制御するスイッチではありません。ブラウザーはシステムプロキシを参照する場合もあれば、拡張機能や独自設定で上書きされる場合もあります。コマンドラインのプログラムは、独自のオプションや環境変数を使うことが一般的です。また、リクエストがコアに届いていても、ルールによって直接接続に振り分けられることがあります。そのため、「ローカルログに接続が記録された」ことと「接続先へプロキシ経由で接続できた」ことは別々に確認してください。

• ブラウザーもターミナルも接続できない：まず待ち受けポートを確認し、同じ接続先を使ってノードと外部接続をテストします。
• プロキシを明示したリクエストは成功するが、ブラウザーは失敗する：システム設定、拡張機能による上書き、ブラウザーポリシーを確認します。
• ブラウザーは使えるが、ターミナルは失敗する：プログラムのオプション、プロキシ環境変数、プロキシ除外リストを確認します。
• クライアント終了後に接続できない：停止したローカルポートがシステム設定に残っていないか確認します。

2. 10808 の待ち受けを確認して、プロキシを明示したテストを実行する

ここでは、ローカルの混合プロキシ接続口として 127.0.0.1:10808 を例にします。すべての環境で同じ値を使うわけではありません。v2rayN の「設定」→「パラメータ設定」で「ローカル混合ポート」を確認してください。バージョンによっては「Core:基本設定」タブにあります。HTTP と SOCKS のポートが個別に表示される場合、以下の HTTP テストには実際の HTTP ポートを入力してください。混合ポートの例をそのまま使うことはできません。

Windows PowerShell で以下の2つのコマンドを実行します。1つ目は待ち受け中のプロセスを確認し、2つ目はシステムプロキシの自動検出を使わず、ローカルの HTTP プロキシへ直接接続します。ここでは curl.exe を使います。旧バージョンの Windows PowerShell では、curl が別コマンドのエイリアスとして解釈されることがあるためです。-q を最初のオプションに指定すると、curl の既定設定ファイルを読み込まずに実行できます。

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe -q --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 30 --head https://example.com/

この記事では、一般的な HTTPS 接続先として example.com を使用します。実際に確認したいWebサイトとは限りません。再テストでは問題が起きている完全な URL に置き換え、同じ接続先を使い続けてください。接続先が HEAD リクエストに対応していない場合は、--head を外し、Windows では --output NUL を追加してレスポンス本文を破棄します。現在のネットワークから特定のWebサイトへ直接接続できるかどうかだけで、プロキシの動作を判断しないでください。

3. ブラウザーが接続できない場合：拡張機能、システム設定、PAC の順に確認する

プロキシを明示したテストは成功するのに、ブラウザーで ERR_PROXY_CONNECTION_FAILED が表示される場合は、まずブラウザーが実際に使っている接続口を確認します。シークレットウィンドウを「拡張機能の影響がない環境」と見なすのは避けてください。拡張機能によってはシークレットモードでも有効になり、組織のポリシーからプロキシ設定が適用されることもあります。確認する際は、プロキシを変更する拡張機能を明示的に一時停止し、ブラウザーを完全に終了してから再起動してください。

1. プロキシ拡張機能を一時停止する

   Chrome では「拡張機能」→「拡張機能を管理」、Edge では「拡張機能」→「拡張機能の管理」を開き、プロキシ設定を変更する拡張機能を一時停止します。拡張機能を引き続き使う場合は、現在のモードとポート番号を記録し、後で個別に再有効化してテストしてください。

2. システム設定を設定し直す

   v2rayN のタスクトレイアイコンを右クリックし、「システムプロキシ」から「システムプロキシを解除」を選んでから、「システムプロキシを自動設定」を選択します。クライアントを起動したまま、トレイメニューの選択状態だけでなく、システムに実際に書き込まれた値を確認してください。

3. アドレスとポートを確認する

   Windows 11 で「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシ セットアップ」の「プロキシ サーバーを使う」を確認します。システムプロキシの自動設定で使用される一般的なローカル接続口は、クライアントの実際の待ち受けアドレスとポートに一致している必要があります。例：127.0.0.1 と 10808。

4. スクリプトの競合を確認する

   同じ画面で「セットアップ スクリプトを使う」も確認します。古い PAC URL が設定されている場合は、設定元を記録してください。個人のデバイスで、組織のポリシーによる管理を受けていない場合は、スクリプトを一時的に無効にして、プロキシの選択方法を一つに絞ります。業務用デバイスでは、組織の管理ルールを確認せずに設定を上書きしないでください。

5. ブラウザー独自の設定を確認する

   Firefox で「設定」→「一般」→「ネットワーク設定」→「設定」を開き、「システムのプロキシー設定を利用する」を選んでから再テストします。手動で設定する場合は、HTTP プロキシ、ポート、HTTPS リクエスト用のプロキシ設定を確認してください。システム設定に自動で追従するとは限りません。

「システムプロキシの自動設定」と「セットアップ スクリプトを使う」は別の機能です。前者は通常、クライアントがローカルプロキシの接続口を設定します。後者はブラウザーに PAC スクリプトを参照させ、接続先ごとにプロキシ経由か直接接続かを決めます。PAC ルールから特定のドメインが漏れている場合、そのドメインだけで問題が起きることがあります。その場合は、スクリプトの判定結果やキャッシュを確認してください。サブスクリプション URL とローカルポートを同時に変更する必要はありません。

• 設定を保存してもすぐに元に戻る：別のプロキシツール、スタートアップタスク、組織のポリシーが設定を繰り返し書き換えていないか確認します。
• 特定のブラウザーだけで問題が起きる：一時的な新規ブラウザープロファイルで比較し、そのブラウザーの拡張機能と独自設定を重点的に確認します。
• 特定のサイトだけで問題が起きる：ルーティングルール、サイトの稼働状況、完全なドメイン名を確認します。他のサイトが開けても、すべての振り分け経路が正常とは限りません。

4. ターミナルが接続できない場合：環境変数とプログラム独自のオプションを確認する

ブラウザーではWebページが開けるのに、PowerShell などのターミナルではタイムアウトすることがあります。これは矛盾ではありません。ターミナルはプログラムを起動するためのシェルであり、システムプロキシを参照するかどうかはプログラムの実装によって異なります。環境変数は通常、プロセスの起動時に引き継がれます。あるターミナルウィンドウで変数を設定しても、すでに開いている別のウィンドウには反映されず、ブラウザーのシステムプロキシ設定にも反映されません。

まず PowerShell で現在のプロキシ環境変数を確認し、その後、現在のセッションに HTTP プロキシを設定します。ここでの HTTPS_PROXY は、HTTPS の接続先へアクセスする際に使うプロキシを指定します。ローカルのプロキシアドレス自体を https:// にするという意味ではありません。一般的なローカル HTTP CONNECT 接続口では、引き続き http://127.0.0.1:10808 を使います。

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"

curl.exe -q --connect-timeout 10 --max-time 30 --head https://example.com/

Windows の環境変数名では大文字と小文字が区別されません。一方、macOS と Linux では大文字・小文字の違いに注意が必要です。curl はセキュリティ上の理由から、大文字の HTTP_PROXY を HTTP プロキシ変数として使用しません。そのため、以下の例では小文字に統一しています。他のコマンドラインツールでは対応方法が異なる場合があるため、curl の動作をそのまま当てはめないでください。

# macOS / Linux：現在のシェルと、そこから起動する子プロセスにのみ適用
export http_proxy='http://127.0.0.1:10808'
export https_proxy='http://127.0.0.1:10808'
export no_proxy='localhost,127.0.0.1,::1'

curl -q --connect-timeout 10 --max-time 30 --head https://example.com/

コマンドをコンテナ、仮想マシン、または異なるネットワークモードの WSL で実行すると、127.0.0.1 はデスクトップのホストではなく、その環境自身を指す場合があります。まずホスト側の接続口に到達できるか確認してから、待ち受けアドレスを変更する必要があるか判断してください。手軽だからといって、プロキシをすべてのネットワークインターフェースに公開しないでください。環境をまたいだ接続が必要な場合は、接続元アドレスを制限し、ファイアウォールのルールを確認してください。

5. HTTP・SOCKS・DNS のどこで失敗しているかを切り分ける

ローカルの混合プロキシ接続口は通常、HTTP と SOCKS の両方を受け付けますが、古い設定ではポートが分かれていることがあります。SOCKS 専用ポートへ HTTP CONNECT を送ると、ハンドシェイクエラーや空のレスポンスが返ることがあります。この問題は VMess や VLESS のノードプロトコルとは別の層で発生しています。まずローカルのインバウンドプロトコルを確認し、その後でリモートノードの設定を調べてください。

# SOCKS 対応の実際のポートでテストし、接続先のドメイン名はプロキシ側で名前解決する
curl -q --proxy socks5h://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 30 --head https://example.com/

Windows で上記のコマンドを実行する場合は、curl を curl.exe に変更します。curl では通常、socks5:// を使うと接続先のドメイン名をローカルで名前解決し、socks5h:// を使うと SOCKS プロキシ側で名前解決します。結果の違いから名前解決の場所を推測できますが、どの DNS サーバーを変更すべきかまでは判断できません。

• HTTPS 接続に HTTP プロキシを使用：curl は通常、接続先のホスト名をプロキシに渡して CONNECT トンネルを確立します。ローカルの名前解決キャッシュが原因とは限りません。
• コアのログにノードのドメイン名解決エラーがある：ノードアドレスと、コアが使用する DNS の経路を確認してください。ブラウザーのキャッシュを削除しても、ノードの名前解決問題は解決しません。
• 同じ接続先が直接接続に振り分けられる：現在のルーティングモードとルールの順序を確認します。プロキシポートへ接続されたからといって、最終的にプロキシ経由で接続されるとは限りません。

6. 設定を元に戻し、再現可能な調査結果を残す

原因を特定したら一時的な変更を元に戻し、テスト用の設定が次のトラブルの原因にならないようにします。PowerShell に一時的に設定した変数は、現在のウィンドウで削除できます。システム設定から永続的に変数を登録した場合は、設定した場所に戻って削除し、影響を受けるアプリを再起動してください。以下のコマンドは、現在の PowerShell セッションにある4つのプロキシ変数だけを削除し、ユーザー単位やシステム単位の永続設定は変更しません。

Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

macOS または Linux の現在のシェルでは、unset http_proxy https_proxy all_proxy no_proxy を実行します。大文字の変数を設定していた場合は、対応する大文字の項目も確認して削除してください。変数がシェルの起動ファイルに設定されている場合、現在のウィンドウで unset を実行するだけでは、次回の読み込みを防げません。

1. v2rayN を終了する前に、必要に応じて「システムプロキシ」から「システムプロキシを解除」を選択し、ブラウザーが想定どおり直接接続できるか確認します。
2. 必要な拡張機能や TUN を、一つずつ有効に戻します。有効にするたびに、同じ接続先で再テストしてください。
3. テストした時刻、実際の待ち受けポート、完全なエラーコード、ブラウザーでの結果、プロキシを明示した curl の結果を記録します。すべての現象を「インターネットにまったくつながらない」とひとまとめにしないでください。
4. 調査の協力を依頼する場合は、関係するログの範囲だけを共有してください。サブスクリプション URL、ノードの認証情報、トークンを含むリクエスト URL は必ず伏せてください。