システムプロキシを設定しても使えない？ブラウザー・ターミナル別の確認手順

1. システムプロキシ・アプリのプロキシ・ルーティングの違い

v2rayNの「システムプロキシを自動設定」は、OSがアプリに提供するプロキシ設定を書き換える機能です。端末上のすべての通信を制御するわけではありません。ブラウザーは通常この設定を参照しますが、コマンドラインツール、バックグラウンドサービス、独自のネットワーク機能を持つアプリは設定を無視することがあります。そのため「ブラウザーは使えるがターミナルは失敗する」場合、まずアプリごとの接続方法の違いを確認しましょう。ノードの障害とは限りません。

この通信経路でシステムプロキシが影響するのは最初の段階だけです。XrayまたはV2Rayのコアがリクエストを受け取った後、ルールに従って直結・プロキシ・ブロックのいずれかを選びます。ブラウザーがローカルポートに接続していても、直結ルールに一致したサイトはローカル回線から接続されます。「出口IPが変わらない」ことだけでは、システムプロキシが機能していないとは判断できません。

TUNは、システムプロキシとは別の通信経路を制御する機能です。確認項目を絞るため、この記事ではTUNを無効にした状態を前提にします。現在のネットワークがTUNに依存している場合は、元の設定を記録してから、接続が一時的に切れても問題ない状況で切り分けてください。TUN、DNS、ルーティングを同時に変更すると、原因を特定しにくくなります。

2. ローカルポートと明示的なプロキシ接続を確認

v2rayNの「設定」→「パラメーター設定」を開き、ローカルの待ち受け設定を確認します。コアの起動ログにも待ち受け情報が記録されているので確認してください。バージョンによって項目名や分類は異なる場合があります。実際の画面とログを基準にしましょう。以下の数値は確認用の例で、すべてのバージョンの標準値ではありません。SOCKS専用ポートはHTTPプロキシとして使えません。

Windows PowerShellでは、まず待ち受けポートを確認し、プロキシを明示したリクエストを実行します。一部のPowerShell環境ではcurlが別のツールのエイリアスになっているため、curl.exeを使ってください。macOSやLinuxでは、2つ目のコマンドのcurl.exeをcurlに置き換えます。

Get-NetTCPConnection -State Listen -LocalPort 10808

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -v https://example.com/ -o NUL

--noproxy ""を指定すると、このテスト中は除外リストが空になり、既存のNO_PROXYの影響を防げます。macOSやLinuxでは、出力を破棄するパスを/dev/nullに変更してください。接続確認用のドメインは、実際に問題が起きているサイトにも置き換えて試しましょう。あるサイトに接続できても、すべてのルートや宛先ポートが正常とは限りません。

• 127.0.0.1:10808への接続が拒否される場合：コアが起動していない、ポートが違う、または待ち受けアドレスが一致していない可能性があります。
• 200 Connection establishedが表示される場合：HTTP CONNECTトンネルは確立しています。続けてTLSハンドシェイクと最終レスポンスを確認してください。
• 接続先からHTTP 200、301、403などが返る場合：アプリケーション層のレスポンスを受信できています。403は接続先によるアクセス拒否であり、ローカルプロキシの障害とは限りません。
• ローカルの接続先にはつながるが、その後タイムアウトする場合：コアのログで外部接続、DNS、接続先の状態を確認してください。ブラウザーのプロキシ設定を繰り返し切り替える必要はありません。

3. ブラウザーでプロキシが使えない場合の確認手順

v2rayNを起動したまま使用可能なノードを選び、トレイメニューの「システムプロキシ」→「システムプロキシを自動設定」を実行します。その後、トレイの表示だけでなく、OSに実際に保存された設定も確認してください。他のプロキシソフト、ブラウザー拡張機能、組織のポリシーが設定を上書きしていることがあります。

1. OSの設定を確認

   Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」のアドレスとポートを確認します。macOSでは「システム設定」→「ネットワーク」→現在の接続→「詳細」→「プロキシ」を開きます。Linuxはデスクトップ環境によって異なります。GNOMEの場合は「設定」→「ネットワーク」→「ネットワークプロキシ」を確認してください。

2. ブラウザーの接続設定を確認

   Chromeでは「設定」→「システム」→「パソコンのプロキシ設定を開く」を選びます。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」を開き、「システムのプロキシ設定を使用する」が選ばれているか確認してください。「プロキシーを使用しない」または手動設定になっている場合、システム設定には従いません。

3. プロキシ拡張機能を一時停止

   Chromeの「拡張機能」→「拡張機能を管理」を開き、プロキシを制御する拡張機能を一時的に無効にして、新しいブラウザープロファイルでテストします。シークレットウィンドウでも、ポリシーや許可された拡張機能が引き継がれる場合があります。完全な切り分け環境とは限りません。

4. 除外ルールを確認

   システムプロキシの例外、ブラウザーの手動設定にある「プロキシを使用しない」リスト、自動設定スクリプトの有無を確認します。PACは接続先に応じて直結を指定できます。ルールの内容を確認せずに、PAC設定ならすべてのサイトがプロキシ経由になると考えないでください。

5. 再起動して再テスト

   ブラウザーのウィンドウをすべて閉じ、バックグラウンドプロセスも終了してから起動し直します。コマンドラインテストと同じURLにアクセスし、v2rayNのログも確認してください。Chromeではアドレスバーにchrome://policyと入力すると、組織から適用されたプロキシポリシーを確認できます。管理対象の端末では管理者に相談してください。

ブラウザーのリクエストがコアのログにまったく現れない場合は、まずブラウザー側の接続設定を確認します。ただし、アクセスログが有効で、適切なログレベルに設定されている場合に限り、記録がないことを判断材料にできます。接続先への直結がログに明記されている場合は、問題はシステムプロキシではなくルーティングの選択にあります。プロキシ経由の外部接続で失敗している場合は、ノードと接続先の状態を確認してください。

4. ターミナルは環境変数と単発のオプションで確認

ターミナルツールには、共通の「システムプロキシに従う」仕様はありません。プロキシ環境変数に対応したツールなら、現在のターミナルセッションで変数を設定できます。コマンドラインのプロキシオプションに対応している場合は、単発の指定のほうが原因を切り分けやすくなります。変数が引き継がれるのは、その後に起動した子プロセスです。起動済みのエディター内ターミナルやバックグラウンドタスクには自動で反映されません。

Windows 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"

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

Get-ChildItem Env: | Where-Object Name -Match 'proxy'

HTTPS_PROXYのhttp://は、「ターミナルからローカルプロキシまで」の接続プロトコルを示します。接続先URLのプロトコルを示すものではありません。HTTPSサイトへのアクセスでは、通常HTTPプロキシがCONNECTでトンネルを確立します。接続先がHTTPSだからといって、変数の値をhttps://127.0.0.1:10808に変更する必要はありません。後者が使えるのは、ローカルの接続先が実際にTLSプロキシを提供している場合に限られます。

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'

curl --connect-timeout 5 --max-time 15 -v https://example.com/ -o /dev/null

env | grep -i proxy

大文字と小文字を区別する環境では、curlがHTTPプロキシ用に参照するのは小文字のhttp_proxyだけです。HTTPSプロキシの変数には対応する大文字・小文字の形式があります。他のツールでは仕様が異なる場合があるため、各ツールのドキュメントを確認してください。同じ変数名で大文字・小文字の形式が両方あり、値が異なる場合は、変数を追加する前に競合を解消します。

• NO_PROXYまたはno_proxyに指定した接続先ドメインはプロキシを経由しません。ツールによっては*をすべての接続先を除外する指定として扱います。
• ALL_PROXYは一部ツールで代替プロキシとして使えます。ただし、対応状況はツールごとに異なり、専用の変数やコマンドラインオプションが優先される場合もあります。
• 動作確認済みのSOCKS接続先がある場合は、curl --proxy socks5h://127.0.0.1:10808 https://example.com/で単発テストできます。socks5hでは接続先ドメインの名前解決をプロキシ側で行います。
• WSL、コンテナー、リモートターミナル内の127.0.0.1はそれぞれの環境を指し、v2rayNを動かしているホストを指すとは限りません。接続のためにローカルプロキシをLAN全体へ公開しないでください。

明示的な--proxyでは成功するのに、環境変数を設定すると失敗する場合は、ツールが環境変数に対応しているか、独自のプロキシ設定があるか、接続先が除外リストに一致していないかを確認します。WindowsのWinHTTP設定とデスクトップのシステムプロキシ設定は別のものです。ターミナルの特定ツールを直すために、WinHTTPの全体設定を安易に変更しないでください。

5. 実際のエラーから原因の層を特定

「ウェブページを開けない」という情報より、エラーメッセージのほうが原因の特定に役立ちます。以下はよくある出力例です。実際の表示はcurlのバージョン、OS、ブラウザーの言語設定によって異なります。ローカル接続、CONNECT、TLS、接続先の応答のどの段階で失敗したかを記録してから、変更する設定を判断しましょう。

ブラウザーは使えるのにターミナルで証明書エラーだけが出る場合、すぐにノードを切り替えないでください。ブラウザーとコマンドラインアプリで、証明書の信頼ストアが異なることがあります。同様に、ターミナルは成功するのにブラウザーでプロキシ接続エラーが出る場合は、まず両者が使うローカルポートを比較しましょう。特定のプロトコル全体が使えないとは限りません。

6. 設定を元に戻し、必要最小限の調査記録を残す

原因を特定したら、必要な設定だけを残します。作業上プロキシ環境変数が必要な場合は、使用しているシェルの起動ファイルに設定し、ローカル開発サービスへの影響も確認してください。一時テストが終わったら、以下のコマンドで今回設定した変数を解除できます。テスト前から値が設定されていた場合は、削除せず元の値に戻してください。

現在のセッションの環境変数を解除

# Windows PowerShell
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS、Linux shell
unset http_proxy https_proxy no_proxy

この操作では、ツール専用の設定、大文字・小文字が異なる環境変数、シェルの起動ファイル、すでに起動している子プロセスなど、別の場所に保存された設定は消えません。ブラウザーのテストで一時停止した拡張機能は、1つずつ戻して再確認してください。設定を戻した直後に問題が再現すれば、上書きしている設定を特定できます。

• 環境を記録：OS、v2rayNのバージョン、コアの種類、TUNの有効・無効、ローカル接続先のプロトコルとポート。
• リクエストを統一：同じURLを使い、明示的なプロキシ、環境変数、ブラウザーでの結果をそれぞれ記録します。
• 外部接続先を特定：該当時刻のルーティング判定とエラーログを保存し、直結とプロキシのどちらが使われたか確認します。
• 情報を保護：ログを共有する前に、サブスクリプションURL、トークン、ノードの認証情報、不要な内部ドメインを削除します。