システムプロキシが効かない原因と対処法|ブラウザー拡張機能とターミナルを個別に確認

ブラウザーのプロキシ拡張機能とシステム設定、ターミナルの http_proxy・https_proxy を確認。コマンドラインツールがシステムプロキシを使わない理由も解説します。

この記事の概要

v2rayNでシステムプロキシを有効にしても、ブラウザーやコマンドラインから接続できない方向けのデスクトップ環境での確認方法です。まずローカルプロキシの接続先を確認し、ブラウザー拡張機能、システムプロキシの設定元、ターミナルの環境変数、除外ルールを順に調べます。プロキシを明示した場合と直接接続した場合を比較すれば、アプリの設定、ローカルの待ち受け、リモート接続のどこに問題があるかを切り分けられます。リクエスト経路が変わらないままノードを何度も切り替える必要はありません。

システムプロキシを設定しても、すべてのアプリがプロキシを使うとは限らない

v2rayNの「システムプロキシ」は、主にローカルプロキシのアドレスをOSのプロキシ設定に登録します。その設定を使うかどうかはアプリごとに異なります。ブラウザーは通常システムプロキシを参照しますが、拡張機能や起動オプション、組織のポリシーによって上書きされることもあります。curlなどのコマンドラインツールは独自のオプションや環境変数を使うのが一般的です。タスクトレイのメニューにチェックが入っているだけで、ターミナルの通信もクライアント経由だと判断しないでください。

アプリのプロキシ選択 ローカルプロキシの接続先 コアのルーティング判定 接続先

「リクエストがクライアントに届くこと」と「リクエストがリモートプロキシを経由すること」は分けて考える必要があります。ローカルの接続先に届いても、ルーティングルールによって直接接続になる場合があります。システムプロキシは接続先を選ぶ設定で、ルーティングはその後の出力先を決める設定です。両者は別の段階にあります。VMessやVLESSなどのノード用プロトコルを、ブラウザーのプロキシ設定に入力するわけではありません。ブラウザーが接続するのは、クライアントが提供するHTTPまたはSOCKSのローカル接続先です。

v2rayNのローカル待ち受けポートを確認する

以下では、HTTPプロキシとして利用できるローカル接続先の例に 127.0.0.1:10808 を使います。確認用の例であり、すべてのバージョンや設定で同じ値になるわけではありません。まずv2rayNの「設定」→「パラメーター設定」で、ローカルの待ち受けポートと接続方式を確認してください。バージョンによっては「ローカル混合リスニングポート」など、表示名が異なります。現在の画面に表示されている値を使ってください。HTTPとSOCKSで待ち受けポートが別の場合は、HTTP用のポートを選びます。

10808
この記事で使用するHTTP接続先のポート
10秒
接続フェーズのタイムアウト
20秒
1回のリクエストの制限時間

Windows PowerShellでは、まずポートが待ち受けていることを確認してから、プロキシを明示したリクエストを実行します。ここでは curl.exe を使います。一部のWindows PowerShell環境では、curl が別のコマンドとして解釈されるためです。テスト中はv2rayNを起動したままにし、現在のノードとコアが起動していることを確認してください。

Get-NetTCPConnection -State Listen -LocalPort 10808

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

このコマンドでは、除外リストをローカルアドレスに限定しているため、例のドメインへのアクセスには指定したプロキシが使われます。接続先サイトからHTTP応答が返れば、少なくともプロキシ経由の通信と接続先への接続が完了したことを示します。ただし、ログに直接接続ルールへの一致が記録されている場合、リモートノード経由とは断定できません。200 Connection established だけが表示された場合は、HTTP CONNECTトンネルが受け付けられたことを示すにすぎません。接続先サイトからの応答も確認してください。

ブラウザー拡張機能の競合を3ステップで切り分ける

プロキシを明示したテストが成功してもブラウザーで接続できない場合は、まず「ブラウザーのプロキシをどの設定が制御しているか」を確認します。同じブラウザーに複数のプロキシ拡張機能を入れていると、一方が固定プロキシ、もう一方が自動設定スクリプトを有効にするなど、設定が競合しやすくなります。拡張機能のアイコンに表示されるモードが、OSに保存されたプロキシ設定と一致するとも限りません。

  1. プロキシ拡張機能を無効にする

    Chromeでは「メニュー」→「拡張機能」→「拡張機能を管理」を開きます。Edgeでは「メニュー」→「拡張機能」→「拡張機能の管理」を開きます。プロキシ設定を変更する拡張機能をすべて一時的に無効にし、元の状態を記録してから、ブラウザーを完全に終了して再起動します。現在のタブを閉じるだけでは不十分です。

  2. システム側の接続先を確認する

    Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」に設定されたアドレスとポートが、v2rayNの現在の待ち受け先と一致するか確認します。「セットアップスクリプトを使う」が有効な場合は、まずスクリプトのアドレスを記録し、現在必要な設定のものか確認してください。

  3. 設定を個別に戻してテストする

    同じテスト用アドレスに再度アクセスします。拡張機能を無効にして直った場合は、プロキシ拡張機能を1つだけ有効に戻し、「システムプロキシを使用する」か、正しい固定プロキシ設定を明示的に選びます。変更は一度に1項目だけにして、同じURLで確認してください。キャッシュ、ノード、ルールをまとめて変更しないようにします。

Firefoxでは「設定」→「一般」→「ネットワーク設定」→「接続設定」も確認し、「システムのプロキシ設定を使用する」が選択されているか確認してください。古い手動プロキシや自動プロキシ設定URLが選択されている場合があります。ブラウザーに「プロキシ設定は組織によって管理されています」と表示される場合は、デバイスの管理者に問い合わせてください。通常、v2rayNを再インストールしてもブラウザーのポリシーは解除されません。

ターミナルでは環境変数を個別に設定する

ターミナルはプログラムを実行する環境であり、各プログラムをシステムプロキシに接続する役割はありません。curlは通常プロキシ環境変数を参照しますが、ほかのコマンドは独自の設定ファイルやコマンドラインオプションを使う場合があります。まず前のセクションの --proxy オプションを明示して接続を確認してから、環境変数を設定しましょう。「プロキシ自体が使えない」のか「プログラムが設定を読み込んでいない」のかを切り分けられます。

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

curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/

https_proxy はHTTPS接続先へのリクエストに対応しますが、変数の値には http://127.0.0.1:10808 を指定できます。これはローカルプロキシサービスの接続方式を示すもので、curlはHTTP CONNECTでトンネルを確立します。接続先のHTTPSサイトを平文通信にするわけではありません。変数名にHTTPSが含まれているからといって、接続先を機械的に https:// に変更しないでください。

macOS・Linux:環境変数の大文字と小文字に注意

env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

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 -I --connect-timeout 10 --max-time 20 https://example.com/

大文字と小文字を区別する環境でcurlのHTTPプロキシを設定する場合は、小文字の http_proxy を使います。大文字の HTTP_PROXY だけでは反映されないことがあります。ほかのツールの対応状況はそれぞれ異なるため、各ツールのドキュメントを確認してください。まずは現在のシェルだけに設定し、動作を確認してからシェルの起動ファイルへの追記を検討しましょう。ターミナルを開くたびに誤ったポートが設定されるのを防げます。

除外リストと直接接続の結果も確認する

no_proxy または NO_PROXY には、プロキシを経由させない接続先を指定します。テスト用ドメインが含まれていたり、値が * になっていたりすると、プロキシの環境変数が正しくても直接接続する場合があります。古い all_proxy が、すでに停止しているSOCKSポートを指しているのもよくある原因です。環境変数の優先順位はプログラムによって異なるため、https_proxy だけでなく関連する変数をまとめて確認してください。

テスト結果優先して確認する項目次に行うこと
プロキシを明示すれば成功、通常のリクエストは失敗アプリが参照するプロキシ設定環境変数、個別設定、除外リストを確認
プロキシを明示すると失敗、直接接続は成功ローカル接続先またはプロキシ経由の外向き通信待ち受けポート、接続方式、コアのログを確認
ターミナルは成功、ブラウザーは失敗ブラウザー側で上書きされた設定プロキシ拡張機能を無効にし、システムプロキシとブラウザーのポリシーを確認
どちらのリクエストも失敗ネットワークまたは接続先への通信まず基本のインターネット接続を確認し、その後名前解決、ハンドシェイク、接続先サイトを調べる

Windowsでは、次の2つのコマンドで同じ接続先にアクセスできます。1つ目はローカルプロキシを明示し、2つ目は --noproxy "*" で直接接続します。macOSとLinuxでは、コマンド名を curl に変更してください。例のドメインは接続確認用です。直接接続とプロキシ接続の両方が成功しても問題ではなく、出口の地域を判断する根拠にもなりません。

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

curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

結論:まずリクエストの経路を固定する

プロキシを明示すると成功し、通常のリクエストが失敗する場合は、まずアプリがプロキシ設定を読み込む方法を修正してください。先にノードを変更する必要はありません。同じローカル接続先を通っていると確認できた後も失敗する場合に、ルーティングとリモート接続を調べます。

curlのエラーから失敗した段階を特定する

ブラウザーの「接続できません」という表示だけでは、原因を特定しにくいことがあります。curlのエラー番号を使うと、接続先への接続、プロキシのプロトコル、TLSのどの段階で失敗したかを切り分けやすくなります。以下はよくあるエラーの一部です。所要時間やアドレス、その後に続く説明はOSやcurlのバージョンによって異なります。

エラー:curl: (7) Failed to connect

原因と対処:指定したアドレスへの接続に失敗しています。表示されたアドレスが 127.0.0.1 の場合は、まずv2rayNのコアが動作しているか、ポート番号が正しいか、ポートが待ち受け状態かを確認してください。リモート接続のTLSを先に調べる必要はありません。

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

原因と対処:プロキシのホスト名を名前解決できません。プロキシ環境変数のアドレス、プロトコルのプレフィックス、引用符を確認してください。ローカル接続先を使う場合は、実際のループバックアドレスとポートを指定します。

エラー:curl: (6) Could not resolve host

原因と対処:接続先のホスト名を名前解決できません。意図せず直接接続していないか、ローカル側で名前解決するSOCKSモードになっていないかを確認し、ログを見て名前解決の経路を調べてください。ノードのタイムアウトと同じ原因とは限りません。

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

原因と対処:制限時間内に接続が完了していません。エラーに表示されたアドレスとコアのログを照らし合わせ、ローカル接続先への接続と、その後のリモート接続を切り分けてください。次に、ノードのアドレスとポート、ネットワークからの到達性を確認します。

エラー:curl: (60) SSL certificate problem

原因と対処:証明書の検証に失敗しています。システム時刻、証明書の信頼チェーン、ネットワーク上で通信が妨げられていないかを確認してください。証明書の検証を無効にして、問題が解決したことにしないでください。

詳細を確認するには、元のコマンドに -v を追加し、実際の接続先アドレス、プロキシ環境変数の情報、ハンドシェイクの段階を確認します。ログを共有する前に、サブスクリプションURL、認証情報、プロキシの認証情報、機密性の高いリクエストヘッダーを削除してください。設定全体を公開する必要はありません。また、ターミナルの環境変数をすべてそのまま公開の掲示板に投稿しないでください。

設定を戻して、切り分け結果を確認する

テスト後は、プロキシを制御する方法を1つに絞ってください。普段のブラウザーでシステムプロキシを使う場合は、拡張機能もシステム設定に従わせます。ターミナルでプロキシが必要な場合は、該当するセッションに環境変数を設定します。システムプロキシ、拡張機能の固定プロキシ、自動設定スクリプト、古い環境変数を「予備」として同時に残すと、次回のトラブル時にリクエストの経路を再現しにくくなります。

# PowerShell:今回新たに追加した、元から存在しない変数だけを削除
Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue

# Bash / Zsh:今回新たに追加した、元から存在しない変数だけを削除
unset http_proxy https_proxy no_proxy

プロキシを明示した通信は成功するものの、特定のドメインだけ想定した経路にならない場合は、ルーティングの振り分けについてを確認してください。ローカル接続先にもノードにも接続できない場合は、接続トラブルの対処法に沿って確認を続けてください。まず接続先とアプリの設定を段階的に切り分けてから、DNS、ルーティング、ノードの設定を変更すれば、どの変更が問題を解決したかを特定できます。

v2rayN ダウンロードセンター