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

ブラウザーでプロキシに接続できない場合と、ターミナルのコマンドがプロキシを使わない場合では原因が異なります。Windowsのプロキシ設定、ブラウザー拡張機能、環境変数を個別に確認します。

この記事の要点

まずv2rayNのローカルポートがリクエストを受け付けていることを確認し、ブラウザーのシステムプロキシ設定とターミナルのプロキシ指定を個別に調べます。システムプロキシを有効にしても一部のアプリが直接接続するWindowsユーザー向けの内容です。手順に沿って確認すれば、ポートが待ち受けていない、ブラウザー独自の設定が優先される、コマンドラインがプロキシ設定を読み込まない、クライアントに届いたリクエストがルーティングで直接接続される、といった原因を切り分けられます。

システムプロキシ・アプリの接続方法・ルーティングを切り分ける

現在のノードとルーティング設定はそのままにし、サブスクリプション、DNS、コアを同時に変更しないでください。v2rayNのメイン画面下部にある「システムプロキシ」を開き、「システムプロキシを自動設定」を選択します。バージョンによっては、タスクトレイの右クリックメニューにも同じ項目があります。ここでいう「自動設定」は、クライアントがWindowsのプロキシ設定を書き換える機能です。すべてのプログラムがプロキシを経由するという意味ではなく、PACスクリプト方式と同じものでもありません。

アプリがプロキシ設定を読み取るローカルポートがリクエストを受け付けるルーティングルールを照合するアウトバウンド接続を確立するレスポンスをアプリに返す

システムプロキシは、対応アプリに「リクエストをどのローカルアドレスへ送るか」を伝えます。ルーティングはリクエストがコアに届いた後、プロキシ経由と直接接続のどちらで送るかを決定します。ブラウザーは通常、Windowsの現在のユーザー設定を読み込みます。一方、コマンドラインツールがその設定を使うかどうかはツールごとに異なるため、ブラウザーでの結果をそのままターミナルの結果とみなすことはできません。

ローカルポートを確認してから、プロキシを明示してテストする

「設定」→「パラメータ設定」を開き、ローカルの待ち受けポートに関する項目を探します。バージョンによっては「ローカル混合待ち受けポート」と表示される場合や、HTTPとSOCKSのポートが別々に表示される場合があります。以下ではHTTPプロキシに対応するローカルポートとして10808を例にします。実際の値に合わせてコマンドを変更してください。このポート番号が固定の既定値というわけではありません。

10808
ローカルプロキシのポート例
127.0.0.1
ループバックアドレス
443
HTTPS接続でよく使われるポート

PowerShellで次のコマンドを実行します。1つ目はTCP接続の確認、2つ目は待ち受け中のプロセスIDの表示、3つ目はcurlからローカルのHTTPプロキシへの接続を明示するテストです。Windows PowerShell 5.1ではcurlが別名として扱われ、引数の動作が異なる場合があるため、curl.exeを使います。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess
curl.exe -q -v --connect-timeout 10 --max-time 30 --noproxy "localhost,127.0.0.1" --proxy http://127.0.0.1:10808 https://example.com/ -o NUL

-qは最初の引数に指定し、curlの既定設定ファイルを読み込まないようにします。--noproxyではバイパス対象をローカルアドレスに限定し、既存のNO_PROXY設定によってテスト対象のドメインが意図せず直接接続されるのを防ぎます。example.comは接続確認用の例です。続けて、実際に失敗している、アクセス権のある接続先でも同じコマンドを実行してください。

  1. TcpTestSucceededがFalseの場合は、ポート番号が一致しているか、コアが起動しているか、起動ログにエラーがないかを確認します。
  2. ポートが待ち受けている場合は、OwningProcessでプロセスを確認します。必要に応じてGet-Process -Idを実行し、末尾に確認したプロセスIDを指定してください。ポートに接続できても、待ち受けているのが現在のv2rayNのコアとは限りません。
  3. curlに127.0.0.1への接続が表示されれば、アプリからローカルプロキシまでリクエストが届いています。HTTPプロキシ経由のHTTPS接続では、通常CONNECTトンネルのネゴシエーション情報も表示されます。
  4. 接続先サイトからHTTPレスポンスが返れば、少なくとも今回のリクエストが結果を受け取ったことを確認できます。リモートプロキシ経由で接続したかどうかは、ルーティングログも確認してください。

まとめ:プロキシを明示した接続に成功したら、システム設定を確認

同じ接続先に--proxyを指定すれば接続できるのにブラウザーでは失敗する場合は、ノードとコアの設定は変えないでください。サブスクリプションを再インポートするより、ブラウザーがプロキシ設定を読み取る方法だけを調整するほうが原因を特定しやすくなります。

ブラウザーでプロキシが効かない:Windowsの設定と拡張機能を確認

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「プロキシサーバーを使う」を開きます。Windows 10では通常、「設定」→「ネットワークとインターネット」→「プロキシ」が該当します。プロキシサーバーのアドレスとポートがv2rayNの設定と一致しているか、例外リストにテスト対象のドメインが含まれていないか確認してください。

  1. 設定を書き込み直す。v2rayNで「システムプロキシをクリア」を選び、続けて「システムプロキシを自動設定」を選択します。クライアントのメニュー表示が変わっただけでなく、Windowsの設定画面でアドレスとポートが実際に更新されたことを確認してください。
  2. プロキシ管理拡張機能を一時的に無効にする。ブラウザーの「拡張機能」ページで、プロキシを制御する拡張機能を無効にしてから、ブラウザーを完全に終了して再起動します。シークレットウィンドウでも問題が解消するとは限りません。拡張機能によっては、シークレットウィンドウでの実行が許可されているためです。
  3. ブラウザーが参照するプロキシ設定を確認する。EdgeとChromeは通常、システム設定を使いますが、起動オプションや組織のポリシーで上書きされる場合があります。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」を開き、「システムのプロキシ設定を使用する」を選択します。
  4. 古いプロセスや接続を終了する。ページを保存してすべてのウィンドウを閉じ、バックグラウンドプロセスが終了したことを確認してから、接続先のページを再度開きます。既存のタブを再読み込みするだけでは、以前確立した接続が再利用されることがあります。
  5. 設定が勝手に変わらないか確認する。設定を書き込んですぐにポート番号が元に戻る場合は、ほかのネットワークツール、スタートアップアプリ、組織のポリシーを確認します。管理対象の端末では管理者にポリシーを確認してもらい、設定の上書きを繰り返さないでください。

ブラウザーで一般的なWebページは開けるのに特定のサイトだけで問題が起きる場合は、そのサイトに適用されるルーティング、DNS、証明書エラーを確認します。ページに403や429が表示される場合、サイトからHTTPレスポンスが返っています。アクセス制限やリクエスト頻度が関係している可能性があり、単純に「システムプロキシが無効」とは判断できません。

ターミナルでプロキシが効かない:まず明示指定で試し、次に環境変数を設定する

まず前述のcurl.exe --proxyでテストします。成功したら、ターミナルに環境変数を設定する必要があるか判断してください。Windowsのシステムプロキシは、ターミナルプログラム共通の切り替えではありません。HTTP_PROXYやHTTPS_PROXYを読み込むツールもあれば、独自の設定を使うもの、プロキシの明示指定が必要なものもあります。

PowerShell:現在のウィンドウと、そこから起動する子プロセスだけに設定する

現在の環境変数を確認して記録してから、一時設定を行います。以下のアドレスにあるhttp://は、「アプリがローカルプロキシに接続するときのプロトコル」を示します。接続先のWebサイトがHTTPSでも、ローカルのHTTPプロキシアドレスには通常この形式を使い、CONNECTでトンネルを確立します。

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 -q -v --connect-timeout 10 --max-time 30 https://example.com/ -o NUL

2回目のテストでは、ツールが環境変数を読み込むか確認するため、あえて--proxyを指定しません。curlのHTTPプロキシ用環境変数には大文字・小文字の使い分けがあります。Windowsでは環境変数名の大文字・小文字が区別されませんが、大文字・小文字を区別するシステムでコマンドを使う場合は、ツールのドキュメントを確認してください。HTTPSのテストではHTTPS_PROXYが使われるかを確認します。

コマンドプロンプト:PowerShellの構文ではなくsetを使う

set "HTTP_PROXY=http://127.0.0.1:10808"
set "HTTPS_PROXY=http://127.0.0.1:10808"
set "NO_PROXY=localhost,127.0.0.1"
curl.exe -q -v --connect-timeout 10 --max-time 30 https://example.com/ -o NUL

PowerShellのWebリクエストを確認する場合は、Invoke-WebRequest -Uri 'https://example.com/' -Proxy 'http://127.0.0.1:10808'のようにプロキシを明示できます。既定のプロキシ設定や環境変数の読み込み方は、PowerShellやランタイムのバージョンによって異なります。あるコマンドで成功しても、別のコマンドの動作までは保証されません。

実際のエラーから原因を特定する:接続拒否・トンネル失敗・証明書エラー

まずエラーがブラウザー、curl、コアのログのどこから出ているかを確認し、どの段階で失敗したかを判断します。以下はよくあるエラーの例です。表示される全文はバージョンや接続先によって異なります。「タイムアウト」だけでサブスクリプションの無効を疑ったり、すべてのエラーをDNSの問題と決めつけたりしないでください。

ERR_PROXY_CONNECTION_FAILED

原因:ブラウザーが設定されたプロキシへの接続を確立できていません。プロキシポートの待ち受けが停止している場合や、拡張機能によって設定が書き換えられた場合によく発生します。

対処法:ブラウザーが実際に使っているプロキシアドレスを確認し、同じポートに対してTest-NetConnectionを実行して、待ち受けプロセスも確認します。

curl: (7) Failed to connect

原因:TCP接続の確立に失敗しています。エラーが127.0.0.1とローカルポートを示している場合、プロキシに届く前の段階で失敗しています。

対処法:コアの起動ログ、待ち受けアドレス、ポートの使用状況を確認します。まずリモートノードの通信パラメーターを変更するのは避けてください。

ERR_TUNNEL_CONNECTION_FAILED

原因:ブラウザーがプロキシ経由でトンネルを確立できていません。ポートのプロトコルが合っていない場合や、プロキシが接続先への接続を確立できない場合があります。

対処法:HTTPまたは混合待ち受けのポートを指定していることを確認し、curlの詳細出力と同じ時刻のコアログを照合して原因を調べます。

curl: (60) SSL peer certificate or SSH remote key was not OK

原因:証明書または信頼チェーンの検証に失敗しています。このエラーだけで、リクエストがプロキシをまったく経由していないとは判断できません。

対処法:システム時刻、接続先の証明書、管理されたネットワークの証明書ポリシーを確認します。証明書検証を無効にする方法を恒久的な対処として使わないでください。

ローカルポートには接続できるものの、トンネル確立後にリクエストが止まる場合は、接続先のドメイン、ノードへの到達性、TLSログを確認します。HTTPプロキシ経由でHTTPSサイトにアクセスすると、接続先のホスト名は通常プロキシに渡されます。SOCKSでテストする場合、socks5://とsocks5h://ではドメインを解決する場所が異なり、後者はプロキシ側で名前解決します。比較する際はどちらを使ったか明確にし、同一条件のテストとして扱わないでください。

リクエストがv2rayNに届いている場合:ルーティングを確認し、入口を重ねない

メイン画面のログ欄を開き、接続情報が表示されるログレベルに設定して、接続先のページを1回だけ再読み込みします。時刻を手掛かりに、接続先ドメイン、ポート、アウトバウンドの情報を探してください。ログは選択中のコアが出力するため、項目名はコアやバージョンによって異なることがあります。ログに記録がない場合も、ログレベルが不十分な可能性があり、アプリがクライアントに届いていないとは限りません。

まとめ:一度に変更するのは接続方法かルールのどちらか1つ

まずTUNを無効にし、システムプロキシだけを使った条件でテストします。その後、ブラウザー、プロキシを明示したコマンド、環境変数を使うコマンドを個別に比較してください。特定のアプリがプロキシに対応していないと確認できてから、TUNの利用を検討します。接続方法を複数同時に有効にし、ページが開いたというだけで原因を特定したと判断しないでください。

TUNは別の通信取り込み方式で、仮想ネットワークアダプター、権限、ルーティングテーブルが関係する場合があります。プロキシ設定を読み込まないアプリの通信を取り込めますが、ノードのパラメーター設定の誤りを修正するものではなく、すべての通信を取り込めるとも限りません。設定する場合は、まずTUNモードの説明を読み、元に戻せるよう現在の設定を控えてください。

再テスト後、一時的な環境変数を削除し、原因の調査記録を残す

まず、テスト前のルーティング、ログレベル、ブラウザー拡張機能の状態に戻します。一時的な環境変数をテスト前に設定していなかった場合は、PowerShellで以下の削除コマンドを実行できます。以前から値が設定されていた場合は、記録した元の値に戻し、削除しないでください。現在のターミナルを閉じると、今回のプロセス単位の設定は通常終了しますが、起動済みの子プロセスは独自の環境変数のコピーを保持していることがあります。

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue
  1. 環境を記録:Windowsのバージョン、v2rayNのバージョン、現在のコアとそのバージョン、ローカルの待ち受けポート。
  2. 3つの結果を記録:ブラウザーからのアクセス、curlでプロキシを明示したアクセス、curlで環境変数を使ったアクセスが成功したかどうか。
  3. 失敗した段階を記録:ローカルポートへの接続、CONNECTトンネル、TLS検証、HTTPレスポンス、またはコアからリモートノードへの接続。
  4. ログを整理して問い合わせる:時刻とエラー前後の情報を残し、サブスクリプションURL、認証情報、共有リンク、公開に適さない接続先情報を伏せてください。

クライアントを正常に終了するときは、v2rayNによるシステムプロキシの解除が完了するまで待ちます。クライアントが異常終了し、ブラウザーにプロキシ接続エラーが表示される場合は、Windowsのプロキシ設定が停止中のローカルポートを指したままになっていないか確認してください。インストールと基本設定は接続確認の手順を、システムプロキシとルーティングの違いはプロキシモードの説明を参照してください。

v2rayN をダウンロード対応プラットフォームとインストーラーを確認