2026-09-27 · トラブル対処 · 約10分

v2rayNのシステムプロキシが効かないときの対処法｜ブラウザーとターミナルを個別に確認

接続済みなのにWebページが開けない場合は、ブラウザー拡張機能・システムプロキシと、ターミナルの環境変数を個別に確認。PACや例外設定、ポートの確認手順も解説します。

この記事の要点

v2rayNのコアが起動しているのに、ブラウザーでアクセスできない、ターミナルのリクエストがタイムアウトする、一部のアプリだけ通信できる場合に役立つ内容です。まずプロキシを明示したリクエストでローカルの接続先を確認し、次にブラウザーがシステムプロキシを使っているか、最後にターミナルの環境変数、PAC、例外設定を確認します。主にWindowsでの操作を解説します。例に示すポートはクライアントの実際の待ち受けポートに置き換えてください。コマンドが成功しても、すべての通信がプロキシ経由とは限りません。

システムプロキシ・コアの起動・サーバーの接続可否を切り分ける

v2rayNに「コア起動中」と表示されても、関連プロセスが動作していることを示すだけです。サーバーを選択していても、ブラウザーがそのサーバーを利用しているとは限りません。システムプロキシは、この設定に従うアプリにローカルプロキシのアドレスを通知するもので、すべてのプログラムの通信を自動的に経由させる機能ではありません。ターミナルツールやブラウザー拡張機能、アプリ独自のプロキシ設定が別の経路を使っていることもあります。

アプリが設定を読み取る ローカルプロキシの接続先 コアのルーティング判定 外部への接続 接続先サイトの応答

この経路に沿って、各段階を順に確認します。プロキシを明示しても失敗する場合は、待ち受けポート、コアのログ、サーバーへの接続を確認します。明示プロキシなら成功するのに通常のブラウザーアクセスが失敗する場合は、システム設定とブラウザーを確認します。この順序なら、接続先に到達できていない段階でPACルールを何度も変更せずに済みます。

  1. 現在のサーバー、システムプロキシのモード、ローカルの待ち受けアドレスとポートを記録し、元に戻せるようにします。
  2. 切り分け中はTUNをいったん無効にし、別の経路で通信が捕捉されないようにします。また、システムプロキシを制御する別のプログラムを同時に起動しないでください。
  3. v2rayNの「設定」→「パラメーター設定」で、ローカルの待ち受けに関する項目を確認します。画面によって項目の位置が異なる場合があるため、実際の表示に従ってください。
  4. クライアントのログを開き、起動失敗、ポートのバインド失敗、継続的な接続エラーがないことを確認してから、以降の比較テストを行います。

プロキシを明示したリクエストでローカル接続先を確認

まずPowerShellで curl.exe を実行します。環境によっては curl が別のコマンドを指す場合があるためです。以下の2つのリクエストは同じ接続先を使い、1つ目はプロキシを迂回し、2つ目はローカルのHTTPプロキシを明示します。接続時間と全体のタイムアウトを設定し、長時間待たずに済むようにします。例のサイトは接続確認用であり、実際の速度測定結果を示すものではありません。

10808
ローカルプロキシのポート例。実際の設定に合わせてください
443
この例で使用するHTTPS接続先のポート
2回
直接接続と明示プロキシの比較リクエスト
# 直接接続の比較：すべてのプロキシを経由しない
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/

# 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.com/

socks5h は接続先のドメイン名の処理をSOCKSプロキシ側に任せますが、最終的な名前解決の方法はコアの設定に左右されます。HTTPプロキシでHTTPSアドレスにアクセスする場合、通常はCONNECTトンネルを使用します。プロキシのアドレスを http://127.0.0.1:10808 と指定しても、接続先のWebページが暗号化されないHTTPになるわけではありません。

比較結果優先して確認する項目この結果だけでは判断できないこと
明示プロキシは成功するが、ブラウザーは失敗するブラウザー拡張機能、システムプロキシのアドレス、PAC、例外設定ブラウザーがプロキシ経由で接続しているとは限らない
ローカルプロキシへの接続が拒否される待ち受けポート、接続先のプロトコル、コアの動作状況リモートサーバーの障害とは断定できない
直接接続とプロキシ接続の両方が成功するログを確認して実際の外部接続経路を判断する同じWebページが開いても、2回の接続経路が同じとは限らない
プロキシリクエストがタイムアウトするログの時刻をもとにDNS、ルーティング、外部接続を確認するタイムアウトだけでは、どの段階の問題か特定できない

判断のポイント：明示プロキシの成功を確認してからシステム設定を変更

繰り返し成功する明示プロキシのコマンドを基準として残します。その後はブラウザー、PAC、環境変数のうち一度に1項目だけ変更します。基準のコマンドは成功するのにアプリで失敗するなら、アプリ側の接続経路に範囲を絞って調べられます。

ブラウザーがプロキシを使わない：システム設定と拡張機能を確認

Windows 11で「設定」→「ネットワークとインターネット」→「プロキシ」を開き、設定スクリプトと手動プロキシのどちらが有効か確認します。v2rayNの手動システムプロキシを使う場合は、アドレスとポートがクライアントで現在利用できるHTTPまたは混合プロキシの接続先と一致している必要があります。PACを使う場合はスクリプトのアドレスを確認し、手動プロキシのスイッチも同時に有効にする必要があるとは限りません。

  1. システムプロキシを設定し直す。v2rayNのトレイメニューで「システムプロキシ」→「システムプロキシを自動設定」を選びます。画面上の表記が異なる場合は、ローカルプロキシのアドレスを書き込む項目を選択し、システム設定に反映されたことを確認します。
  2. プロキシ拡張機能を一時的に無効にする。拡張機能が特定のサーバーを固定したり、直接接続を強制したり、独自ルールで通信を振り分けたりすることがあります。まず関連する拡張機能を無効にし、通常のウィンドウでテストしてください。シークレットウィンドウでも一部の拡張機能は実行を許可できるため、完全に分離された環境とは限りません。
  3. ブラウザー独自の設定を確認する。ブラウザーに個別のプロキシ設定がある場合は、システムプロキシを使う設定にします。個別の設定項目がない場合は、起動オプションでプロキシ接続または直接接続が固定されていないか確認してください。
  4. ブラウザーを終了して再起動する。すべてのブラウザーウィンドウを閉じ、バックグラウンドのプロセスも終了したことを確認してから、同じテスト用アドレスを開きます。古い接続が判定に影響するのを防げます。

システム設定を変更してもすぐに元に戻る場合は、別のプロキシプログラム、ブラウザー拡張機能、組織の管理ポリシーを優先して確認してください。管理対象の端末では、ポリシー設定を繰り返し上書きせず、利用可能なプロキシ方式を管理者に確認します。システムプロキシが正常でも特定のアプリで失敗する場合、そのアプリがシステム設定を参照していない可能性もあります。

PACと例外設定：リクエストが迂回されていないか確認

PACは、アプリが読み込んで実行するプロキシ選択スクリプトです。一般的な戻り値には DIRECT と PROXY 127.0.0.1:10808 があります。PACが決めるのはリクエストの最初の接続先であり、コアに届いた後のルーティング振り分けとは別の段階です。PACが直接接続を返すと、そのリクエストはv2rayNに届かない可能性があります。

Windowsの手動プロキシにある「例外」とPAC内部の直接接続ルールは、現在有効なモードに応じてそれぞれ確認します。ターミナルの NO_PROXY は別の設定です。システムの例外を削除しても、コマンドラインツールの迂回リストが同時に消えるわけではありません。

判断のポイント：接続先を一時的に固定し、PACとコアの問題を切り分ける

まずPACのアドレスを記録してから、検証済みの手動プロキシ接続先に一時的に切り替えます。ブラウザーがすぐに復旧し、明示プロキシのコマンドも常に成功する場合は、PACの読み込みとルールの適用を優先して確認します。原因を特定したら元のモードに戻せばよく、コアのルーティングまで同時に変更する必要はありません。

ターミナルがプロキシを使わない：環境変数とツールの設定を確認

ターミナルのプログラムがWindowsのシステムプロキシを参照するとは限りません。ブラウザーでは接続できるのにコマンドラインでタイムアウトする場合は、ツールのプロキシ引数と環境変数を個別に確認します。以下のPowerShell設定は現在のセッションと、そこから起動する子プロセスにだけ適用され、すでに実行中の別のターミナルウィンドウは変更しません。

# 現在のセッションで、名前にproxyを含む環境変数を表示
Get-ChildItem Env: | Where-Object { $_.Name -match 'proxy' }

# 例：これらの変数に対応するツールでHTTPプロキシを設定
$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"

# --proxyを明示せず、curl.exeが現在の環境変数を読み取るか確認
curl.exe --connect-timeout 10 --max-time 20 -I https://example.com/

# 確認後、このセッションで設定した変数を削除
Remove-Item Env:http_proxy,Env:https_proxy,Env:no_proxy -ErrorAction SilentlyContinue

https_proxy はHTTPSの接続先に使用するプロキシを指定するもので、プロキシ自体のアドレスをHTTPSにする必要はありません。ローカルの接続先が通常のHTTPプロキシにしか対応していない場合、https://127.0.0.1:10808 と指定するとTLSハンドシェイクに失敗することがあります。環境変数への対応状況と優先順位はツールによって異なるため、curlの動作をすべてのプログラムに当てはめないでください。

ポートの競合と具体的なエラー：待ち受け状態から確認

明示プロキシのコマンドでローカルポートへの接続に失敗する場合は、VMessやVLESSなどのプロトコル設定を変える前に、待ち受け状態を確認してください。以下のコマンドはPowerShellで実行し、ポートには前述の例を使用します。待ち受けが見つかった場合も、所有するプロセスを確認してください。「何らかのプログラムが待ち受けている」ことは、「v2rayNの現在のコアが待ち受けている」ことを意味しません。

# このポートがTCPで待ち受けているか確認
Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

# 待ち受けプロセスの名前を確認
Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue }

# 別の設定情報として、WindowsのWinHTTPプロキシ設定を確認
netsh winhttp show proxy

netsh winhttp show proxy に表示されるのはWinHTTPのプロキシ設定であり、ブラウザーが使うユーザー向けのシステムプロキシ設定とは異なります。直接接続と表示されても、v2rayNがブラウザー用のシステム設定を書き込めていないとは判断できません。また、確認せずにユーザープロキシを別の設定にインポートしないでください。

エラー：Connection refused

原因：ローカルのループバックアドレスへの接続時にこのメッセージが表示される場合、通常は対象ポートで接続を受け付けるサービスがありません。接続が明示的に拒否された可能性もあります。対処法：実際の待ち受けアドレスとポートを確認し、コアの起動ログを調べてから、正しい接続先プロトコルで再試行します。

エラー：address already in use

原因：よくあるポートのバインドエラーです。別のプロセスや二重起動したインスタンスが、同じアドレスとポートを使用している可能性があります。対処法：待ち受けプロセスを調べて使用元を確認し、競合するプログラムを正常に終了するか、ローカルポートを変更します。その場合はシステムプロキシ、PAC、ターミナルの環境変数もあわせて更新してください。

エラー：Could not resolve proxy

原因：curlがプロキシのホスト名を解決できません。プロキシアドレスの入力ミス、古い環境変数、不正な形式などがよくある原因です。対処法：まず http://127.0.0.1:10808 を明示してテストし、その後、環境変数とツール設定内のプロキシアドレスを確認します。

エラー：Could not resolve host

原因：現在のリクエスト経路で接続先ドメインを名前解決できていません。直接接続、SOCKS、HTTPプロキシのどの方式を使うかによって、発生する場所が異なります。対処法：使用したコマンドとプロキシ方式を記録し、コアのログでリクエストがプロキシに届いたか確認したうえで、該当する経路のDNS設定を調べます。

OSやコアのバージョンによって、エラー全文の表記は異なる場合があります。エラーのキーワード、発生時刻、接続先ポートを記録すれば、原因の特定に役立ちます。「タイムアウト」という表示だけを切り取って、サーバーが無効だと決めつけないでください。ローカルの接続先には到達できており、ログにリモート接続の失敗が記録されている場合は、サーバーアドレス、ポート、トランスポート、安全性に関するパラメーターを確認します。

設定を元に戻し、3項目を確認して切り分けを終える

原因がわかったら、実際に使うプロキシモードに戻し、調査のために追加した一時設定を削除します。特に、システムプロキシだけ新しいポートに変更され、ターミナルには古いポートが残っている、またはPACが変更前のアドレスを参照している状態に注意してください。一度に1項目ずつ戻し、結果が安定したことを確認してから次に進みます。

  1. 明示プロキシで繰り返し成功する：基準にしたコマンドをもう一度実行し、ローカルの接続先から外部への経路までリクエストが完了することを確認します。
  2. アプリの接続経路が明確：ブラウザーが想定どおりにシステムプロキシまたはPACを参照し、ターミナルが必要に応じて環境変数を参照することを確認します。ログでリクエストがコアに届いているかも確認してください。
  3. 終了時の動作を確認：プロキシを使い終えたら、先にシステムプロキシを解除するか、元の設定に戻します。クライアントの異常終了後にWebページが開けなくなった場合は、停止済みのローカルポートをシステムが参照したままになっていないか確認してください。

追加のサポートが必要な場合は、OS、v2rayNの画面タイプ、実際の待ち受けプロトコルとポート、システムプロキシのモード、比較に使ったコマンド、該当時刻のログを提示してください。共有前に、サブスクリプションURL、認証情報、サーバーの機密情報は伏せてください。設定の考え方は応用設定、初めて設定する場合は入門ガイドで基本手順を確認できます。

v2rayNをダウンロード