システムプロキシを設定してもWebサイトが開けない原因と対処法：ブラウザー・コマンドライン別に確認

この記事の要点

システムプロキシを有効にしても、OSにプロキシ設定が登録されるだけで、すべてのアプリがその設定を使うとは限りません。デスクトップ版v2rayNを例に、まずローカルの待ち受けとプロキシを明示したリクエストを確認し、次にブラウザーの設定とターミナルの環境変数を個別に調べます。最後に、接続・名前解決・証明書のエラーから原因を絞り込みます。「Webサイトが開けない」「ブラウザーは使えるのにコマンドラインはタイムアウトする」「クライアントを終了してもインターネットに接続できない」といった場合に役立ちます。

システムプロキシとTUNモード：通信を制御する範囲の違い

システムプロキシはアプリが参照する接続設定であり、すべての通信を強制的にプロキシへ送るスイッチではありません。システム設定に従うブラウザーはローカルのプロキシポートに接続しますが、設定を参照しないコマンドラインツールは直接インターネットに接続することがあります。一方、v2rayNのTUNモードは仮想ネットワークインターフェースとルーティングによって通信を取り込みます。権限、ルート、DNSも関係するため、システムプロキシとは分けて考えましょう。

アプリが設定を参照ローカルのプロキシ入口コアがルーティングを判定接続先を選択宛先サービスが応答

この経路のどこかで処理が止まると、Webページの読み込みに失敗することがあります。システム設定が正しくてもコアが起動していなければローカルの入口に問題があり、入口が正常でもノードに接続できなければ送信先側の問題です。特定のブラウザーだけで失敗する場合は、まずブラウザー独自のプロキシ設定を確認してください。調査中は経路を切り分けやすくするため、TUNやほかのプロキシツールを一時的に無効にし、通信方式を一つに絞りましょう。

ブラウザーもターミナルも失敗する：まずローカルポートをテストし、次にノードとルーティングのログを確認します。
ブラウザーは失敗するが、プロキシを明示したコマンドは成功する：拡張機能、PAC、ブラウザー独自のプロキシ設定を優先して確認します。
ブラウザーは成功するが、ターミナルは失敗する：環境変数、ツールの設定、実行環境を優先して確認します。
一部のドメインだけ失敗する：除外リスト、ドメイン別ルーティング、DNS、接続先サービスの状態を確認します。

ローカルの待ち受けを確認：プロキシを明示してテスト

v2rayNを起動し、ノードが選択されていることと、実行ログに起動失敗やポート競合がないことを確認します。次に、現在のクライアント設定または実際の実行設定から、待ち受けアドレス、ポート、入口の種類を確認してください。以下ではHTTPプロキシ接続を受け付ける入口として 127.0.0.1:10808 を例にします。すべてのバージョンで使われる既定ポートではありません。実行前に必ず実際の設定値に置き換えてください。

10808

ローカルポートの例。実際の設定値を使用してください

5秒

接続タイムアウトの上限例

20秒

リクエスト全体のタイムアウト上限例

Windowsでは、PowerShellで次のコマンドを実行してポートを確認し、公開テスト用ドメインへのリクエストでプロキシを明示します。一部のPowerShell環境では curl が別のコマンドとして解釈されるため、ここでは curl.exe を使います。例ではGETリクエストを使い、レスポンス本文を破棄します。HEADリクエストに対応していないサイトによる誤判定を避けるためです。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL --write-out "HTTP=%{http_code}\n" https://example.com/

TcpTestSucceeded : True が示すのはTCPポートに接続できたことだけです。そのポートがHTTPプロキシ接続を受け付けることや、リモートノードが利用可能なことまでは確認できません。プロキシを明示したリクエストでHTTPステータスコードが返れば、少なくともHTTP応答を受信できています。403など拒否を示す応答の場合は、接続先サイトと中間機器のどちらが返したものかも確認してください。このテストの対象は1つのドメインに限られるため、すべての利用環境の確認にはなりません。

結論：プロキシを明示したテストの成功後にブラウザーを調整

ローカルプロキシを明示したリクエストが成功したら、ノードとコアの設定はそのままにして、失敗するアプリのプロキシ入口だけを調整します。テストに失敗する場合は、待ち受けまたは送信先への接続を先に解決しましょう。ブラウザーの設定を何度も変更する必要はありません。

ブラウザーの確認：拡張機能、PAC、除外リスト

ブラウザーでは、システム設定、プロキシ拡張機能、独自のプロキシ設定が併用されることがあります。まず現在の設定を控え、一つずつ確認してください。変更する項目は毎回一つにし、同じURLにアクセスして結果を比較します。ブラウザーを変えて開けたからといって、ノードが修復されたとは限りません。2つのブラウザーで通信経路が異なる可能性があります。

システム側の入口を確認

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシセットアップ」のアドレスとポートが、クライアントの現在の待ち受け設定と一致しているか確認します。PACを使う場合は「セットアップスクリプトを使う」のスクリプトURLを確認してください。スクリプトのURLをプロキシサーバーのアドレスとして入力しないようにしましょう。
プロキシ拡張機能を一時停止

Chromeで「拡張機能」→「拡張機能を管理」を開き、プロキシを制御する拡張機能を一時的に無効にします。次に「設定」→「システム」→「パソコンのプロキシ設定を開く」で、システム側の設定を確認してください。「設定は組織によって管理されています」と表示される場合は、デバイスのポリシーを確認します。通常のスイッチではポリシーを上書きできないことがあります。
ブラウザー独自の設定を確認

Firefoxで「設定」→「一般」→「ネットワーク設定」→「設定」を開き、「システムのプロキシ設定を利用する」と「手動でプロキシを設定する」のどちらが選ばれているか確認します。手動設定の場合は、ポートとプロキシの種類をローカルの入口に合わせてください。HTTP用の入口をSOCKS欄に入力しないようにしましょう。
除外条件を確認

システムプロキシの例外、ブラウザーの「プロキシを使用しない」リスト、PACの判定結果を確認します。テスト対象のドメインが除外条件に一致すると、リクエストはプロキシを通らず直接接続されます。PACの DIRECT は直接接続を意味し、PROXY 127.0.0.1:10808 は該当するHTTPプロキシ入口を使う指定です。
接続を作り直す

ブラウザーのウィンドウをすべて閉じてから再起動し、以前の接続が再利用される影響を除外します。プライベートウィンドウでも、すべての拡張機能が無効になるとは限らず、システムプロキシが自動的に無視されるわけでもありません。条件をそろえて比較するには、拡張機能を入れていない一時的なブラウザープロファイルを使います。

PACはURLやホスト名に応じて接続方法を決めるスクリプトであり、有効にすればすべての通信がプロキシ経由になるわけではありません。スクリプトにアクセスできない、古いポートが返される、対象ドメインがルールで直接接続に指定されている、といった場合はWebページを開けないことがあります。動作確認には、利用可能と確認済みの手動プロキシ入口へ一時的に切り替えて比較します。問題が解消したらPACに戻し、ルールを確認してください。テスト後は、社内ネットワークやLAN用の例外設定を元に戻し、内部サービスへの接続に影響しないようにしましょう。

ターミナルの確認：http_proxyとツール独自の設定

コマンドラインツールがシステムプロキシを参照するとは限りません。まず、上記の --proxy で入口を明示し、成功を確認してから環境変数を設定します。最初からシステム全体に設定を書き込まず、現在のターミナルセッションで動作を確かめてから、永続化するか判断してください。新しく起動したターミナル、エディター内蔵ターミナル、バックグラウンドサービスでは、引き継がれる環境変数が異なることがあります。一つのウィンドウでの結果を、ほかのプロセスにも当てはめないでください。

PowerShell：現在のセッションだけを変更

Get-ChildItem Env: | Where-Object Name -Match '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 --connect-timeout 5 --max-time 20 --output NUL --write-out "HTTP=%{http_code}\n" https://example.com/

https_proxy は通常、HTTPSの接続先に使用するプロキシを指定する変数です。値が https:// で始まる必要はありません。変数名の大文字・小文字の扱いはツールによって異なります。curlでは http_proxy の大文字・小文字に特別な扱いがあるため、複数の環境で使うなら小文字の名前が便利です。確認時は ALL_PROXY と NO_PROXY にも注意してください。後者によって対象ドメインがプロキシを迂回する場合があります。

macOS・Linux：現在のシェルを確認

env | grep -i 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,::1'

curl --connect-timeout 5 --max-time 20 --output /dev/null --write-out 'HTTP=%{http_code}\n' https://example.com/

症状	まず確認する項目	対処方法
プロキシを明示すると成功するが、通常のリクエストは失敗する	環境変数が読み込まれていない、または除外条件がある	変数とツールのドキュメントを確認し、no_proxyの範囲を狭めて再テストする
curlは成功するが、ほかのツールは失敗する	ツール独自のプロキシ設定	起動オプション、設定ファイル、実行時のプロキシ設定を確認する
新しいターミナルでは成功するが、古いターミナルでは失敗する	古いプロセスが以前の環境変数を引き継いでいる	ターミナルまたは親プロセスを再起動する
コンテナや仮想環境で接続が拒否される	127.0.0.1が環境自身を指している	その環境から到達できるホストのアドレスを使い、待ち受け設定とファイアウォールを確認する

ブラウザーのプロキシ拡張機能の設定がターミナルに引き継がれることはなく、ターミナルの環境変数によって起動済みのブラウザーの設定が変わることもありません。コンテナ内の 127.0.0.1 は通常、ホストマシンではなくコンテナ自身を指します。ただし、この問題を解決するために、すべてのネットワークインターフェースで待ち受ける設定を安易に有効にしないでください。環境をまたいだ接続が必要な場合は、接続元アドレスを制限し、適切なアクセス制御を設定します。

エラーの見分け方：接続、DNS、TLSを分けて確認

失敗したコマンドのエラー全文を保存し、同じ時間帯のクライアントログも確認します。ブラウザーのエラーページから分かるのは失敗段階の一部だけですが、コマンドラインの詳細出力なら「ローカルの入口に接続できない」のか「リモートとのハンドシェイクに失敗した」のかを見分けやすくなります。ログを共有する前に、サブスクリプションURL、ノードの認証情報、個人の閲覧記録を削除してください。

エラー：ERR_PROXY_CONNECTION_FAILED

原因：ブラウザーが設定済みのプロキシ入口に接続できていません。クライアントの終了、ポートの変更、古いアドレスを参照するプロキシ拡張機能などがよくある原因です。

対処：現在設定されているアドレスのローカルポートをテストし、ブラウザーが実際に使用しているプロキシ設定を確認します。まずリモートノードを変更する必要はありません。

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

原因：TCP接続を確立できていません。続くメッセージを確認し、接続できない相手がローカルプロキシなのか接続先サーバーなのかを判断します。

対処：接続先が127.0.0.1の場合は、待ち受けポート、コアの起動ログ、ポート競合を確認します。リモートアドレスへの接続に失敗している場合は、該当するネットワーク経路を調べてください。

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

原因：プロキシのホスト名を名前解決できていないか、変数の形式が誤っていて、ツールが不正な値をホスト名として扱っています。

対処：プロキシURLのプロトコル、ホスト、ポートを確認します。ローカル入口には実際のループバックアドレスを指定し、PACスクリプトのURLをプロキシ変数に入力しないでください。

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

原因：接続先ホスト名の名前解決に失敗しています。プロキシを迂回して直接接続している場合や、SOCKSの設定でローカル側が接続先ドメインを名前解決している場合によく見られます。

対処：まずリクエストがプロキシを迂回していないか確認し、ローカルでの名前解決とプロキシ経由の名前解決を比較します。このエラーだけを根拠に、DNS設定全体を変更しないでください。

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

原因：証明書の信頼チェーンを検証できていません。システム時刻、信頼できる証明書の不足、ネットワーク上のTLS検査機器などが原因となる場合があります。

対処：システム時刻と証明書チェーンを確認し、組織の指示に従って信頼する証明書を設定します。証明書検証を恒久的に無効化する方法で解決しないでください。

実際の入口がSOCKS5を受け付ける場合は、次の2つのコマンドを使って、ドメイン名をどこで名前解決するか比較できます。socks5:// ではcurlがローカルで接続先ドメインを名前解決し、socks5h:// ではプロキシに名前解決を任せます。後者だけ成功する場合は、まずローカルの名前解決経路を調べてください。ここでもデモ用ポートを使っているため、HTTP専用の入口にSOCKSのコマンドをそのまま使うことはできません。

curl.exe --noproxy "" --proxy socks5://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL https://example.com/

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 20 --output NUL https://example.com/

V2Rayのプロトコル選択は別の階層の問題です。ブラウザーはローカルのHTTPまたはSOCKS入口に接続し、コアがノード設定に従ってVMessやVLESSなどのプロトコルで通信します。送信側のプロトコルを変更しても、システムプロキシを参照しないアプリが設定を読み込むようになるわけではありません。V2Rayノードの速度測定も、特定の条件で得られた参考値にすぎず、ブラウザーの除外リスト、ターミナルの環境変数、接続先サイトの証明書が正しいことを保証するものではありません。

設定を戻して再テスト：直結に残った設定を持ち込まない

調査が終わったら、一時的に変更した設定をすべて元に戻してください。特に、クライアントを終了した後もシステムの手動プロキシがローカルポートを指していると、システム設定に従うブラウザーは、待ち受けプログラムのない入口へ接続し続けます。まずv2rayNのシステムプロキシメニューで「システムプロキシをクリア」を選び、その後にクライアントを終了します。クライアントを起動できない場合は、OSのプロキシ設定で該当する入口を手動で無効にしてください。

ブラウザー：必要な拡張機能と元のPAC設定を戻し、古いポートを参照していないことを確認します。
ターミナル：テスト用のセッションを終了するか、一時的に設定した環境変数を削除します。起動ファイルに記述した場合は、該当するファイルも確認してください。
クライアント：元のルーティングと通信制御方式に戻し、切り分け用の全体プロキシ設定が残らないようにします。
再テスト：直接接続、プロキシを明示した接続、ブラウザー、通常のターミナルリクエストの結果をそれぞれ記録し、同じ結果を再現できることを確認します。

現在のセッションからプロキシ変数を削除

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

# macOS / Linux shell
unset http_proxy https_proxy all_proxy no_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

上記のコマンドで削除されるのは、現在のセッションに設定された該当変数です。Windowsのユーザー単位で永続化された変数や、シェルの起動ファイルは変更されません。実行前に元の値を控えてください。組織から提供されたネットワーク設定の場合は、単に消去せず元の値に戻します。エディター内蔵ターミナルを使っている場合、親プロセスから引き継いだ古い変数をクリアするために、エディターの再起動が必要なこともあります。

結論：失敗する範囲を切り分け、有効な設定は維持

ローカル入口が正常ならポート設定を維持し、プロキシを明示した接続が成功するならノード設定を維持します。特定のアプリだけが失敗する場合は、そのアプリの設定を確認してください。一度に変更する変数を一つに絞るほうが、クライアントの再インストールやサブスクリプションの再更新を繰り返すより、確実な原因特定につながります。

サブスクリプションのインポートで解決できるのはノード設定の取得元であり、ブラウザーのプロキシ設定やターミナルの環境変数が自動で設定されるわけではありません。デスクトップでは、この記事を参考にv2rayNの入口とアプリの設定を確認してください。Android版v2rayNGでは、サブスクリプションをインポートした後、アプリの手順に従ってVPNサービスを起動する必要があります。これはデスクトップのシステムプロキシとは別の通信経路です。v2rayNGなどのダウンロード先を探す場合は、ダウンロードページでプラットフォームに応じてv2rayN、v2rayNG、v2flyNGを選び、入門ガイドに沿って基本設定を行ってください。