システムプロキシの設定が反映されるのは、その設定を参照するアプリだけです。すべての通信がv2rayNを経由するわけではありません。まずローカルのプロキシ接続を確認し、ブラウザーのシステム設定・拡張機能・PACと、ターミナルの環境変数・ツール設定を個別に調べます。順番にテストすれば、ローカルの待ち受け、アプリ側の設定、ルーティング、ノードからの接続のどこに問題があるかを絞り込めます。最初からクライアントを再インストールする必要はありません。
1. システムプロキシ・アプリのプロキシ・ノードからの接続を区別する
v2rayNは、設定を管理してプロキシコアを起動するデスクトップクライアントです。システムプロキシは、その設定に従うアプリに接続先のローカルアドレスとポートを伝えます。アプリが設定を参照していない場合や、独自設定で上書きしている場合、通信は接続先へ直接送られることがあります。ターミナルのcurl、パッケージ管理ツール、開発ツールも、ブラウザーと同じシステムプロキシを使うとは限りません。
調査を始める前に、テスト先のアドレスと使用中のノードを1つずつ決めます。TUNを一時的に無効にし、元のシステムプロキシとルーティングのモードを記録してください。2つの経路が重なると、原因を特定しにくくなります。利用中のネットワークでTUNが必須の場合は、その条件を記録し、テスト結果だけでシステムプロキシが正常だと判断しないでください。
- ローカル接続：
127.0.0.1で実際に待ち受けているプロキシポートへアプリが接続できるか。 - アプリの接続設定：ブラウザーやターミナルが、古いポートや直接接続ではなく、この接続先を使っているか。
- ノードからの接続：通信がコアに届いた後、ルールに従って想定したノードを使い、接続先に接続できるか。
2. 明示的なプロキシ指定でローカルポートを確認する
v2rayNの「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートを確認します。バージョンによっては「Core: 基本設定」ページに該当項目があります。項目名や画面構成はバージョンにより異なるため、現在の画面と起動ログを確認してください。ここでは、10808がHTTPに対応した混合ポートだと確認済みである前提で説明します。独立したHTTPポートを使っている場合は、以下の例のポートをすべて実際の値に置き換えてください。
Windows PowerShellではcurl.exeを使うと、一部のPowerShellでcurlが別のコマンドとして解釈される問題を避けられます。まず待ち受け状態を確認し、次にプロキシを明示して接続します。ブラウザーがシステムプロキシを参照しているかどうかには左右されません。
Get-NetTCPConnection -State Listen -LocalPort 10808
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.commacOSとLinuxでは、以下のcurlコマンドで同様にプロキシを明示してテストできます。実行前に、現在のシェルに設定されたNO_PROXYとno_proxyを確認し、テスト対象のドメインやワイルドカード*が含まれていないことを確認してください。含まれているとプロキシを経由せずに接続する場合があります。
curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com判定：明示的なプロキシ接続に失敗したら、ブラウザーの設定は後回し
まず待ち受けポートか、コアから外部への接続を確認します。ログで接続先が直接接続のルールに一致している場合、ローカルプロキシを明示しても、通信がリモートノードを経由した証拠にはなりません。ルーティング結果もあわせて確認してください。
3. ブラウザーで接続できない：システム設定・拡張機能・PACを順に確認
以下では主にWindowsデスクトップを例に説明します。macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」でシステムプロキシを確認できます。Linuxはデスクトップ環境によって設定場所が異なり、プロキシ設定を行ってもターミナルの環境変数に自動反映されるとは限りません。
-
システムプロキシを設定する
v2rayNのタスクトレイメニューから「システムプロキシ」→「自動設定」を選びます。「システムプロキシをクリア」は有効化する操作ではありません。「システムプロキシを変更しない」を選ぶと現在の設定が維持されますが、今回起動したポートを参照しているとは限りません。
-
システムプロキシの接続先を確認する
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートがv2rayNの現在の待ち受け設定と一致しているか確認します。「セットアップスクリプトを使う」の状態も記録し、以前のPACと手動設定が交互に影響しないようにしてください。
-
プロキシ拡張機能を無効にする
プロキシを管理するブラウザー拡張機能を一時的に無効にし、ブラウザーを完全に終了してから再起動します。ChromeやEdgeは通常システムプロキシを使いますが、拡張機能や起動オプションで上書きされることがあります。管理対象の端末では、ブラウザーポリシーも確認してください。
-
ブラウザー独自の設定を確認する
Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」から接続方法を確認できます。システムプロキシをテストするには「システムのプロキシ設定を利用する」を選択します。手動プロキシを選んでいる場合は、アドレス、ポート、例外リストを個別に確認してください。
-
PACのルールを確認する
普段PACを使っている場合は、スクリプトを元に戻して同じアドレスをテストします。スクリプトのURLにアクセスできるか、取得内容がプロキシ自動設定スクリプトか、対象ドメインに
DIRECTが返されるかを確認してください。スクリプトに記載されたローカルポートも、現在の接続先と一致している必要があります。
PACが決めるのは、アプリが接続をプロキシに渡すかどうかです。v2rayNのルーティングルールが決めるのは、コアに届いた通信をどこから外へ出すかです。これは別々の段階です。「PACでプロキシが選択された」からといって、「コアが必ずリモートノードを選ぶ」とは限りません。元の設定値を記録したうえで、一時的に手動プロキシを指定して比較し、テスト後に普段のPAC設定へ戻してください。
- 特定のブラウザーだけ失敗する：拡張機能、独自プロキシ設定、起動オプション、ブラウザーポリシーを優先して確認します。
- すべてのブラウザーで失敗するが、curlの明示的なプロキシ指定は成功する：システムプロキシのアドレス、ポート、除外リストを優先して確認します。
- 特定のサイトだけ失敗する：そのドメインに対するPACの戻り値、ルーティングルール、サイト側の応答を確認します。
4. ターミナルでプロキシが使えない：環境変数とツール設定を分けて確認
名前が似た環境変数でも、用途は同じではありません。https_proxyは、HTTPSの接続先へのリクエストに使うプロキシを指定する変数です。プロキシ接続先がHTTPSでなければならない、という意味ではありません。ローカル接続先がHTTPプロキシなら、値はhttp://127.0.0.1:10808のままで問題ありません。ツールはCONNECTを使ってHTTPSトンネルを確立します。
PowerShellでは、まず現在の変数を確認してから、現在のセッションにプロキシを設定します。この例の設定は現在のターミナルと、そこから起動する子プロセスにだけ反映され、端末全体の設定は変更しません。HTTPの接続先に対するcurlは通常、小文字のhttp_proxyを参照します。大文字のHTTP_PROXYだけに頼らないでください。
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 10 --max-time 20 -I https://example.comBashやZshなどのシェルでは、以下のように現在のセッションに設定できます。大文字の除外変数がすでに設定されている場合は、ツールによって大文字・小文字のどちらを優先するか異なるため、値を確認してください。シェル設定ファイルを変更しても、すでに開いている別のターミナルには自動反映されません。
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 10 --max-time 20 -I https://example.com| 設定箇所 | 確認する内容 | よくある誤解 |
|---|---|---|
| コマンドのオプション | curlの--proxy、--noproxy | 明示的なオプションや除外条件によって、環境変数の設定が適用されないことがあります。 |
| 環境変数 | http_proxy、https_proxy、ALL_PROXY | 変数を1つ設定すれば、すべてのツールで使われると思い込む。 |
| 除外リスト | no_proxy、NO_PROXY | *や接続先のドメインが含まれていると、リクエストがプロキシを経由しません。 |
| ツール固有の設定 | 例：npm config get proxyとnpm config get https-proxy | ツールに古いポートが設定されたままで、想定した設定が上書きされている。 |
| 独立した実行環境 | コンテナー、リモートターミナル、サブシステムのネットワークと環境変数 | その環境内の127.0.0.1は、ホスト側のプロキシ接続先とは限りません。 |
5. 実際のエラーから失敗した段階を特定する
以下に、よくあるエラーの原文を示します。同じエラーでも原因は複数考えられるため、発生時刻とv2rayNのログを照合してください。ログを共有する前に、サブスクリプションURL、ノードの認証情報、個人のアクセス履歴を削除し、必要なエラー行とポート情報だけを残してください。
エラー：curl: (7) Failed to connect to 127.0.0.1 port 10808
原因と対処：ローカル接続を確立できていません。コアが起動していない、ポート番号が違う、接続先に到達できないといった原因が考えられます。まず待ち受け状態とコアの起動ログを確認し、実際のポートを指定して再試行してください。最初にリモートDNSを変更する必要はありません。
エラー：ERR_PROXY_CONNECTION_FAILED
原因と対処：ブラウザーが設定済みのプロキシ接続先に接続できていません。システムのアドレス、拡張機能の設定、PACが返すポートを確認し、同じアドレスを指定してcurlでも接続をテストしてください。
エラー：curl: (5) Could not resolve proxy
原因と対処：プロキシのアドレスを名前解決できていません。ポート、プロトコル、空白などを誤った位置に記述している可能性があります。変数がhttp://127.0.0.1:10808の形式になっているか確認し、ツール固有の設定も調べてください。
エラー：curl: (6) Could not resolve host
原因と対処：接続先ドメインを名前解決できていません。まず、リクエストが直接接続されているのか、ローカルで名前解決するSOCKSモードを使っているのか確認します。除外リストと実際のプロキシ方式を調べてください。プロキシ側で名前解決する場合は、利用可能と確認済みのSOCKS5接続先にsocks5hを指定して比較できます。
エラー：curl: (28) Operation timed out
原因と対処：制限時間内にリクエストが完了しませんでした。タイムアウトだけでは、どの段階で問題が起きたか判断できません。コアがリクエストを受け取ったか、どの出口を選んだかを確認し、ノードへの接続と接続先サイトを個別に調べてください。
HTTPプロキシのテストで200 Connection establishedが表示されても、確認できるのはCONNECTトンネルが受け付けられたことまでです。接続先のTLSハンドシェイクと最終的なHTTPレスポンスも確認してください。接続先から403や405が返っても、プロキシが無効とは限りません。サイトによってはアクセス元やHEADリクエストが制限されています。TLSエラーを隠すために証明書の検証を無効にしないでください。
6. 比較テスト後、普段の設定に戻す
キャッシュや一時的なネットワーク変動の影響を避けるため、同じテスト用ドメインを使い、以下の順に結果を記録してください。一度に変更する項目は1つだけにし、成功したか、エラーの内容、ログに記録された実際の接続先を残します。ここに記載したタイムアウト値はテスト用であり、ノードの速度やネットワーク品質を測定した結果ではありません。
- プロキシを明示してテスト：
--proxyで確認済みのローカルポートを指定し、除外リストに接続先が含まれていないことを確認します。 - ブラウザーでテスト：プロキシ拡張機能を無効にしてシステムプロキシを有効にし、同じドメインにアクセスしてコアのログを確認します。
- ターミナルの環境変数をテスト：明示的なプロキシオプションを外し、現在のセッションの環境変数だけを残してリクエストを実行します。
- 直接接続との比較：curlで
--noproxy '*'を指定すると、アプリケーション層のプロキシを迂回できます。TUNが動作中の場合、ネットワーク層で直接接続したことにはなりません。 - 設定を元に戻す：元のPAC、ルーティング、TUNの状態に戻し、一時的な環境変数を削除してから、よく使うアプリで再確認します。
まとめ：ローカル接続を確認してからアプリ側を調べる
プロキシを明示した接続は成功するのにブラウザーで失敗する場合は、システム設定、拡張機能、PACを重点的に確認します。ブラウザーは成功するのにターミナルで失敗する場合は、環境変数、除外リスト、ツール設定を調べてください。リクエストがコアに届いてから失敗する場合に、ルーティング、DNS、ノードからの接続を確認します。
PowerShellの現在のセッションに設定した一時変数は、Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinueで削除できます。BashやZshではunset http_proxy https_proxy no_proxyを実行します。元からこれらの変数が設定されていた場合は、記録した値に戻し、削除しないでください。設定の考え方をさらに確認したい場合は、サイト内のトラブル対処ガイドまたは用語集をご覧ください。