v2rayNは起動しているのに、ブラウザーでサイトを開けない、ターミナルからの通信が直接接続になる、一部のアプリだけ接続できる場合に役立ちます。まずプロキシを明示したリクエストでローカルの接続口を確認し、ブラウザーのプロキシ設定、システムのPAC設定、ターミナルの環境変数をそれぞれ調べます。ここではWindowsを中心に、BashとZshでの確認コマンドも紹介します。例のポート番号は、クライアントで実際に待ち受けている値に置き換えてください。
1. システムプロキシ、アプリの接続方法、ルーティングを切り分ける
v2rayNの「システムプロキシを自動設定」は、PC全体の通信を強制的にプロキシへ送る機能ではありません。システムのプロキシ設定を書き換えるため、その設定を参照するアプリだけがローカルのプロキシ接続口を使います。ブラウザーは通常この設定を参照しますが、拡張機能やブラウザーポリシー、個別のプロキシ設定が優先されることがあります。コマンドラインツールが設定を参照するかどうかは、ツールの実装によります。
ルーティングモードが関係するのは、リクエストが接続口に入った後です。「全般」モードを選んでも、ローカルの待ち受けポートに届いていないリクエストは取り込まれません。逆に、コアに届いたリクエストでも、現在のルールによって直接接続に振り分けられることがあります。まずリクエストが取り込まれているかを確認し、次にどのアウトバウンドへ進んだかを調べましょう。2つの設定を混同しないことが大切です。
- ブラウザーは使えるが、ターミナルでは使えない：ノードを変更する前に、ターミナルのプロキシ引数と環境変数を確認します。
- プロキシを明示すれば使えるが、ブラウザーでは使えない：拡張機能、PAC設定、ブラウザー独自のプロキシ設定を確認します。
- プロキシを明示しても使えない：まずポート、コアの稼働状態、アウトバウンドログを確認します。システムプロキシの設定は後回しで構いません。
- 一部のドメインだけ接続できない：バイパスリスト、ルーティングルール、DNS、接続先サイトの応答を確認します。
2. ポートを指定してローカルのプロキシ接続口を確認する
まずv2rayNのメイン画面下部にあるステータスバーでローカルポートを確認し、「設定」→「パラメーター設定」で待ち受けポートとプロトコルを照合します。バージョンによってSOCKS、HTTP、または混合の待ち受け口が表示されることがあります。他の解説に記載された番号を、そのまま自分の環境に当てはめないでください。以下では、127.0.0.1:10808がHTTPプロキシとして待ち受けていることを確認済みとします。このポートがSOCKSにしか対応していない場合は、後述のSOCKS用コマンドを使ってください。
Windows PowerShellでは、まずポートに接続できるか確認し、次にcurl.exeでプロキシを明示してリクエストします。curl.exeと指定することで、一部のWindows PowerShell環境でcurlエイリアスが別のコマンドを指す問題を避けられます。テスト先のhttps://example.com/はリクエスト経路の確認用であり、特定のサービスへの接続を保証するものではありません。
Test-NetConnection 127.0.0.1 -Port 10808
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 20 -I -v https://example.com/--noproxy ""を指定すると、このコマンドではバイパスリストが空になり、既存のNO_PROXYによる影響を避けられます。接続口がSOCKS5のみ対応する場合は、次のコマンドを使ってください。socks5hは、接続先のドメイン名をcurl側でなくプロキシ側で解決する指定です。
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 20 -I -v https://example.com/ポイント：接続口を固定してから自動接続設定を確認
プロキシを明示したリクエストで接続先からのHTTPレスポンスを受け取れたら、ブラウザーやターミナルの自動プロキシ設定を調べます。200 Connection establishedだけでは不十分です。これはトンネルが確立したことを示すため、続けてTLSハンドシェイクと接続先からのレスポンスも確認してください。接続先が403を返しても、ローカルポートの障害とは限りません。
3. ブラウザー拡張機能とPAC設定の残存を確認する
ここではWindows 11のChrome、Edge、Firefoxを例に説明します。まず現在のプロキシ設定を記録してください。特に、職場のネットワークで使うスクリプトのアドレスに注意が必要です。組織管理下の端末では管理者の指示に従い、既存の設定を安易に削除しないでください。シークレットウィンドウは拡張機能を確実に切り離すテストにはなりません。シークレットモードでの実行が許可された拡張機能もあり、システム設定も引き続き適用されます。
-
プロキシ拡張機能を無効にする
Chromeでは「拡張機能」→「拡張機能を管理」、Edgeでは「拡張機能」→「拡張機能の管理」を開きます。プロキシ制御、自動切り替えルール、ネットワークリクエストを操作する拡張機能を一時的に無効にし、ブラウザーのウィンドウをすべて閉じてから再起動します。同じ接続先を開いて確認してください。
-
システムの接続口を確認する
Windowsで「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。「手動プロキシ セットアップ」のアドレスとポートが、ローカルのHTTPまたは混合待ち受け口と一致するか確認してください。アドレスだけを入力する欄には
127.0.0.1を指定し、プロキシURL全体は入力しないでください。 -
スクリプトの設定を確認する
同じページにある「セットアップ スクリプトを使う」も確認します。個人用端末で古いPACアドレスが有効な場合は、まず値を記録してから一時的に無効にし、今回確認する接続方法だけを残してください。スクリプト、手動ポート、ルーティングプリセットを同時に変更すると、どの変更で直ったか分からなくなります。
-
ブラウザー独自のプロキシ設定を確認する
Firefoxで「設定」→「一般」→「ネットワーク設定」→「設定」を開きます。v2rayNが設定したシステム設定に従う場合は「システムのプロキシ設定を利用する」を選びます。手動プロキシを使う場合は、各ポートを確認してください。SOCKS専用ポートをHTTPプロキシ欄に入力しないようにします。
-
設定を再適用する
ローカルプロキシを明示したテストが成功したら、v2rayNのタスクトレイメニューにある「システムプロキシ」から、まず「システムプロキシをクリア」、次に「システムプロキシを自動設定」を選びます。その後、Windowsのプロキシ設定ページを開き直し、アドレスとポートが想定どおり変わったか確認してください。
PACはURLやドメインなどの条件に応じてプロキシを選ぶスクリプトで、リクエストによっては直接接続を返すことがあります。そのため、スクリプトアドレスが設定されているだけでは、すべてのリクエストがv2rayNを使っているとは限りません。ブラウザーに「組織によって管理されています」と表示される場合や、無効にしても自動で元に戻る場合は、システムプロキシのボタンを何度も押すのではなく、管理ポリシーや起動中の別のプロキシツールを確認してください。
4. ターミナルで環境変数、プロトコル、プロセスの継承を確認する
ブラウザーで接続できても、ターミナルが自動的に同じ設定を使うとは限りません。curlなどのツールでは、前の節の--proxyオプションで確認してから、現在のターミナルセッションに環境変数を設定します。https_proxyは「HTTPSの接続先に使うプロキシ」を表しますが、値にはhttp://127.0.0.1:10808を指定できます。クライアントはHTTPプロキシのCONNECTメソッドで接続先へのTLSトンネルを確立するため、プロキシURLをHTTPSにする必要はありません。
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,::1'
Remove-Item Env:all_proxy -ErrorAction SilentlyContinue
curl.exe --connect-timeout 5 --max-time 20 -I -v https://example.com/上記の代入で変更されるのは、現在のPowerShellプロセスと、そこから起動する子プロセスだけです。すでに起動しているターミナル、エディター、バックグラウンドタスクには自動で反映されません。Windowsでは環境変数名の大文字・小文字は区別されませんが、ほかのシステムでは両方の表記に注意してください。認証情報を含むプロキシ変数の出力を、公開の掲示板などに貼り付けないでください。
Bash / Zsh：競合する設定を整理して小文字の変数を使う
env | grep -iE '^(http|https|all|no)_proxy='
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY all_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 -I -v https://example.com/curlのhttp_proxyには大文字・小文字に関する特別な扱いがあるため、複数のOSで切り分ける場合は小文字の変数を優先してください。ALL_PROXYは一部のツールが対応する汎用プロキシ変数ですが、すべてのツールが参照するとは限りません。NO_PROXYはプロキシを経由しない接続先を指定します。接続先のドメインが含まれている場合や、値が*の場合は、「変数に値があるのに直接接続になる」ことがあります。各ツールで一致判定の書式が異なる点にも注意してください。
- このウィンドウだけ失敗する：2つのターミナルセッションで変数を比較し、古いウィンドウが以前のポートを使っていないか確認します。
- エディター内のターミナルで失敗する：エディターの起動後に変数を変更した場合は、エディターを再起動し、新しいターミナルに更新後の環境を引き継がせます。
- サブシステムやコンテナー内で失敗する：
127.0.0.1はホストではなく、サブシステムやコンテナー自身を指す場合があります。実際のネットワーク構成に応じてホストのアドレスを確認し、ホストのループバックアドレスをそのまま使わないでください。 - curlは使えるが、ほかのツールでは失敗する：そのツール独自のプロキシ設定と公式の対応方法を確認してください。それだけでv2rayNの障害と判断する必要はありません。
テスト後は、PowerShellでRemove-Item Env:http_proxy,Env:https_proxy,Env:no_proxy -ErrorAction SilentlyContinueを実行して今回設定した変数を削除できます。Bash / Zshではunset http_proxy https_proxy no_proxyを使います。テスト前から値が設定されていた場合は、削除せず記録した元の値に戻してください。
5. 実際のエラーメッセージから失敗箇所を特定する
コマンドラインのエラー全文と発生時刻を記録し、v2rayNのログにある同じリクエストと照合してください。以下はcurlでよく見られるエラーの原文です。ポート、接続先アドレス、タイムアウト時間（ミリ秒）は環境によって異なります。エラーコードは原因の候補を絞る手掛かりになりますが、「接続できません」という表示だけで判断せず、プロキシを明示したテストの結果と併せて確認してください。
エラー：curl: (7) Failed to connect to 127.0.0.1 port 10808
原因：curlがローカルの接続口に接続できていません。コアが起動していない、待ち受けポートが一致していない、またはローカルのポリシーで接続がブロックされている可能性があります。
対処法：実際の待ち受けポートとコアのログを確認し、Test-NetConnectionで接続をテストします。待ち受けプロセスも確認し、ファイアウォール全体を無効にすることは避けてください。
エラー：curl: (5) Could not resolve proxy
原因：プロキシサーバー名を解決できません。プロキシアドレスの入力ミスや、環境変数に不正な形式のホスト名が含まれている場合によく発生します。
対処法：このPC上でのテストでは、確認済みのループバックアドレスとポートを明示します。環境変数の内容を確認してから、同じコマンドを再実行してください。
エラー：curl: (28) Connection timed out
原因：接続またはデータの転送がタイムアウトしました。このエラーだけでは、ローカルの接続口、リモートへのアウトバウンド接続、接続先サイトのどこで問題が起きているか判断できません。
対処法：-vの出力でローカルポートに接続できたか確認し、同じ時刻のコアのログと照合して、アウトバウンド接続と接続先からの応答を調べます。
エラー：curl: (60) SSL certificate problem
原因：証明書の検証に失敗しています。システム時刻、証明書チェーン、ネットワーク上のHTTPS検査などが原因として考えられます。リクエストがプロキシに届いていないという意味ではありません。
対処法：システムの日付、証明書の発行者、システムの信頼設定を確認してください。証明書検証を無効にする方法を恒久的な対策にしないでください。
ログにリクエストが直接接続ルールに一致したと表示される場合は、ブラウザーを再インストールするのではなく、ルーティングを確認してください。VMessやVLESSなどのノードプロトコルはプロキシのアウトバウンド接続に使われます。ローカルアプリは通常、HTTPまたはSOCKSの接続口を利用します。http_proxyにノードのプロトコル名を書いても、正しいローカルプロキシ接続にはなりません。
6. 比較結果で確認し、複数の設定を同時に変更しない
一度に変更する設定は一つだけにし、同じ接続先で再テストしてください。プロキシを明示したcurl、環境変数だけを使ったcurl、プロキシ拡張機能を無効にしたブラウザーの3つの結果を記録するのがおすすめです。障害箇所を絞り込めるほか、クライアントの更新、ポートの変更、ネットワークの切り替え後にも同じ手順で再確認できます。
- プロキシを明示したテストは成功し、環境変数を使うテストは失敗する：変数の値、バイパスリスト、プロセスへの継承、ツールの設定を確認します。
- どちらのcurlテストも成功し、ブラウザーだけ失敗する：拡張機能、PAC設定、ブラウザー独自のプロキシ設定、管理ポリシーを確認します。
- ポートに接続できるが、プロキシを明示したテストは失敗する：接続口のプロトコルが合っているかを確認し、次にコアのログ、ノードへの接続、接続先サイトを調べます。
- すべて復旧した：必要に応じて拡張機能や既存のスクリプトを一つずつ元に戻し、その都度テストして競合の原因を特定します。
まとめ：同じリクエストの接続経路を示す証拠で判断する
システムプロキシボタンの状態から分かるのは設定操作の結果だけで、接続先へのリクエストがプロキシを経由した証拠にはなりません。クライアントのログ、curlの詳細出力、アプリのプロキシ設定を照合するほうが、全般モードを何度も切り替えるより障害箇所を特定しやすくなります。
さらに調べる場合は、OSとv2rayNのバージョン、待ち受けプロトコルとポート、失敗したコマンド、エラーの発生時刻を記録してください。ログを共有する前に、サブスクリプションURL、アクセストークン、ノードの認証情報、個人に関わる接続先アドレスを削除します。サブスクリプションの更新で接続設定は変わりますが、ターミナルの環境変数が補われたり、ブラウザー拡張機能のプロキシ制御が解除されたりすることはありません。