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

システムプロキシですべての通信が切り替わるわけではない

v2rayNのシステムプロキシ機能は、主にローカルのプロキシアドレスをシステム設定に登録するものです。その設定を参照するかどうかはアプリによって異なります。ブラウザーはシステム設定に従う場合もあれば、拡張機能や独自設定を使う場合もあります。コマンドラインツールは環境変数や独自の設定ファイルを参照することがよくあります。そのため、「ブラウザーは使えるのにターミナルでは使えない」という状況も起こり得ます。

通信経路の振り分けも、二つの段階に分けて考えましょう。まずアプリがリクエストをローカルプロキシに渡すかどうかを決めます。次に、コアが受け取ったリクエストをルーティングルールに従って、直接接続またはプロキシ経由のどちらにするか選びます。リクエストがv2rayNに届いても、必ずリモートノードを経由するとは限りません。システムプロキシが有効でも、すべてのプロセスがリクエストをそこへ送るわけではありません。

• システムプロキシ：システム設定に従うアプリにプロキシの接続先を提供します。すべてのネットワーク接続を引き受ける機能ではありません。
• PAC：スクリプトが接続先に応じてプロキシアドレスまたは DIRECT を返します。直接接続になるのは、スイッチの不具合ではなくルールの結果かもしれません。
• ターミナルのプロキシ：http_proxy、https_proxy、ALL_PROXY などの環境変数や、ツールのオプションで設定するのが一般的です。
• TUN：通信を転送する別の経路です。システムプロキシとの混同を避けるため、この記事ではTUNを無効にして切り分けます。

ローカルポートを確認してからプロキシ経由の接続をテストする

以下ではSOCKSポート 10808 とHTTPポート 10809 を例にします。これらはすべてのバージョンで共通の固定値ではありません。HTTPとSOCKSの両方を受け付ける混合ポートだけを設定している場合もあります。まずv2rayNの「設定」→「パラメータ設定」でローカルの待ち受けに関する項目を確認し、起動ログも参照してください。画面の項目はバージョンによって異なるため、実際の表示を優先してください。

PowerShellで以下のコマンドを実行します。まずポートが待ち受けているか確認し、次に curl.exe でプロキシを明示的に指定します。ここでは実行ファイル名まで指定しているため、一部のPowerShell環境で curl が別コマンドのエイリアスとして解釈されるのを防げます。接続先は疎通確認用です。確認したいHTTPSサイトに置き換えてもかまいません。

# サンプルポートの待ち受け状態を確認
Get-NetTCPConnection -State Listen -LocalPort 10808,10809 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

# HTTPプロキシ：プロキシの除外リストを無視し、待ち時間は最大20秒
curl.exe --noproxy "" --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/

# SOCKSプロキシ：接続先のドメイン名解決をプロキシ側で行う
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

HTTPプロキシ経由でHTTPSサイトに接続すると、通常は最初に 200 Connection established と表示されます。これはCONNECTトンネルが確立したことを示すだけです。続けてTLS接続が完了したか、接続先サイトから応答が返っているかを確認してください。サイトがHEADリクエストに対応していない場合は、-I を外して -o NUL -D - に変更すると、GETリクエストのレスポンスヘッダーを確認できます。

ブラウザー側の確認：システム設定、拡張機能、PAC

まず通常のブラウザーウィンドウでテストしてください。シークレットウィンドウでも、すべての拡張機能が無効になるとは限りません。シークレットウィンドウでの実行が許可されている拡張機能もあります。確実に切り分けるには、プロキシ関連の拡張機能を一時的に無効にするか、新しいブラウザープロファイルを使い、古いプロセスを完全に終了してから開き直してください。

1. システムプロキシを設定する

   v2rayNのタスクトレイメニューから「システムプロキシ」→「システムプロキシを自動設定」を選びます。コアが起動していることも確認してください。ここでの「自動設定」は、クライアントがシステム設定を書き換える操作です。PACを使うという意味ではありません。

2. システム側の接続先を確認する

   Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」に表示されているアドレスとポートを確認します。「セットアップスクリプトを使う」が有効な場合は、スクリプトのアドレスも記録し、現在使うべき設定かどうか確認してください。

3. 拡張機能による上書きを確認する

   Chromeではアドレスバーに chrome://extensions/、Edgeでは edge://extensions/ を入力し、プロキシ切り替え拡張機能を一時的に無効にします。次にブラウザーの「設定」→「システム」または「システムとパフォーマンス」からパソコンのプロキシ設定を開き、実際の接続先を確認してください。

4. ブラウザー独自の設定を確認する

   Firefoxで「設定」→「一般」→「ネットワーク設定」→「接続設定」を開き、テスト時は「システムのプロキシ設定を使用」を選びます。「手動でプロキシを設定する」や「自動プロキシ設定URL」が選択されていると、v2rayNが書き込んだ設定に従わない場合があります。

5. 同じ接続先で再テストする

   不要なPACスクリプトを一時的に無効にし、手動プロキシの接続先が実際のHTTPポートまたは混合ポートになっていることを確認します。そのうえで、コマンドラインのテストと同じ接続先にアクセスしてください。テスト後は元のスクリプト、拡張機能、除外ルールを元に戻しましょう。用途が分からない設定を削除したままにしないでください。

一部のドメインだけプロキシを経由しない場合は、PACが DIRECT を返していないか、システムプロキシの例外リストに含まれていないか、コアのルーティングルールが直接接続に一致していないかを確認します。PACによる判定はリクエストがコアに届く前、コアのルーティングは届いた後に行われます。該当時刻のアクセスログを確認すると、どちらの段階で振り分けられたか判断しやすくなります。

• ブラウザーでは開けないが、プロキシを指定したコマンドは成功する：拡張機能、ブラウザー独自のプロキシ設定、システムポリシーを確認します。
• ブラウザーでは開けるが、アクセスログに直接接続と表示される：ブラウザーのポート設定ではなく、コアのルーティングを確認します。
• スクリプトを無効にすると正常に戻る：PACのドメイン判定、スクリプトの接続可否、ブラウザーのキャッシュを確認します。

ターミナル側の確認：環境変数とツール独自の設定

ターミナルを使っているからといって、すべてのコマンドが同じ方法でネットワークに接続するわけではありません。curl.exe、パッケージ管理ツール、各種ランタイムでは、プロキシの扱いが異なる場合があります。まず、現在のPowerShellプロセスに設定されているプロキシ環境変数を一覧表示し、特に NO_PROXY に注意してください。プロキシアドレスが正しくても、除外リストに一致する接続先は直接接続されることがあります。

# 現在のターミナルプロセスのプロキシ環境変数を確認
Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

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

netsh winhttp show proxy の表示は、ブラウザーのシステムプロキシ画面をそのまま複製したものではありません。WinHTTPとユーザー単位のプロキシは別の設定体系です。ここに「直接アクセス」と表示されても、v2rayNがシステムプロキシを書き込んでいないとは限りません。また、一つのコマンドを直すために、安易にパソコン全体の設定を変更するのは避けてください。

以下のテストでは現在のPowerShellセッションだけを変更し、終了時に元の値へ戻します。ポートは実際のHTTPポートまたは混合ポートに置き換えてください。HTTPSサイトに接続する場合も、プロキシアドレスに http://127.0.0.1:10809 を使うのは正常です。ここでのプロトコルはローカルプロキシへの接続方法を示すもので、接続先サイトのプロトコルではありません。

$names = @('http_proxy', 'https_proxy', 'ALL_PROXY', 'NO_PROXY')
$saved = @{}
foreach ($name in $names) {
  $saved[$name] = [Environment]::GetEnvironmentVariable($name, 'Process')
}

try {
  $env:http_proxy = 'http://127.0.0.1:10809'
  $env:https_proxy = 'http://127.0.0.1:10809'
  Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
  Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

  curl.exe --connect-timeout 10 --max-time 20 -I https://example.com/
}
finally {
  foreach ($name in $names) {
    if ($null -eq $saved[$name]) {
      Remove-Item "Env:$name" -ErrorAction SilentlyContinue
    }
    else {
      Set-Item "Env:$name" $saved[$name]
    }
  }
}

このコマンドの成功で確認できるのは、現在の curl.exe がこれらの環境変数を参照できることだけです。他のツールで失敗する場合は、そのツールのプロキシ設定、設定ファイル、実行アカウントを確認してください。起動済みのターミナルは、後から変更されたユーザー環境変数を通常は自動で読み込みません。環境変数を永続化する必要があると確認できてからユーザー変数を変更し、ターミナルを再起動してください。最初からシステム全体の設定を変更して影響範囲を広げないようにしましょう。

エラー内容から原因を絞り、すべてを接続先ノードの問題と決めつけない

詳しい情報が必要な場合はテストコマンドに -v を追加し、接続先がローカルプロキシなのか、接続先サイトなのかを確認します。出力を共有する前に、プロキシの認証情報、サブスクリプションURLなどの機密情報を隠してください。curlでよくあるエラーには、それぞれ異なる対処が必要です。

ローカルの待ち受けが正常なのに、HTTPとSOCKSを明示したテストがどちらもプロキシ経由の接続段階で失敗する場合は、選択中のノード、システム時刻、リモート側の設定を確認してください。VLESSまたはVMessのノードでは、トランスポート方式、TLS、サーバー側のパラメーターも確認が必要です。これらの問題はシステムプロキシの切り替えでは解決しません。サブスクリプションを更新した後は、リストが更新されただけでなく、有効な設定が選択されていることも確認しましょう。

よくある質問と設定の復元

最後に、TUN、PAC、拡張機能、環境変数を元に戻します。一つ戻すたびに再テストしてください。基準として、動作する明示的なプロキシ指定コマンドを一つ残しておきましょう。次に問題が起きたときは、まずローカルの接続先とプロキシ経由の接続を確認し、その後アプリが通信を渡しているか調べられます。これで調査範囲を絞り、ブラウザー設定の問題をノードの問題と取り違えるのを防げます。