v2rayNのシステムプロキシが効かない場合：ブラウザーとコマンドラインの設定を個別に確認

1. システムプロキシは接続口。すべての通信を自動で中継するわけではない

v2rayNの「システムプロキシを設定」は、OSにプロキシ設定を書き込みます。ただし、その設定を使うかどうかはアプリによって異なります。ブラウザーはシステム設定に従う場合もあれば、拡張機能、起動オプション、組織のポリシーによって設定が上書きされる場合もあります。コマンドラインツールには独自のプロキシオプションや環境変数があるのが一般的です。ブラウザーでWebサイトを開けても、端末もプロキシ経由とは限りません。

確認すべき選択は2段階あります。まずアプリがローカルプロキシに接続するかを決め、次にコアがその接続をプロキシ経由にするか、直接接続にするかを決めます。アプリがv2rayNに接続していても、ルーティングルールによって直接接続されることがあります。VMessやVLESSはリモート接続に使うプロトコル設定であり、ブラウザーや端末にシステムプロキシを自動で読み込ませるものではありません。

• アプリがプロキシを回避：アプリがローカルの待ち受けに接続していません。システム設定、拡張機能、環境変数、プロキシ除外リストを確認してください。
• ルーティングによる直接接続：ローカルプロキシはリクエストを受信していますが、ルールによって直接接続が選ばれています。現在のルーティングモードとルールの順序を確認してください。
• アウトバウンド接続の失敗：リクエストはコアに届いていますが、リモートノードまたは接続先サービスへの接続に失敗しています。ノード、DNS、認証、トランスポートの設定を確認してください。

2. プロキシを明示してローカルの接続口を確認

まず、v2rayNに表示されているローカルの待ち受けアドレス、ポート、プロトコルを控えます。「設定」→「パラメーター設定」で待ち受け関連の設定を確認し、実際に動作しているコアの設定を基準にしてください。画面のレイアウトによって項目の位置は異なる場合があります。以下では、HTTPに対応するローカル接続口の例として127.0.0.1:10808を使用します。すべての環境での既定値ではありません。SOCKS待ち受けのみの場合は、対応するSOCKS用のテストコマンドを使ってください。

Windows PowerShellではcurl.exeを使い、旧バージョンのWindows PowerShellでcurlが別のコマンドのエイリアスとして解釈されるのを防ぎます。macOSとLinuxではcurlを使います。テスト用URLは例です。確認したい実際のHTTPSサイトに置き換えてください。パブリックネットワークへのプロキシ接続を確認する際、ローカルアドレスをテスト先にしないでください。

# Windows PowerShell：HTTPまたは混合待ち受け
curl.exe -v --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o NUL

# macOS / Linux：HTTPまたは混合待ち受け
curl -v --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

# このポートがSOCKS5に対応している場合のみ使用。接続先ドメインの名前解決はプロキシ側で行う
curl -v --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

--noproxy ""を指定すると、このテストではプロキシ除外リストを空にできます。詳細出力に127.0.0.1への接続が表示されることを確認してください。HTTPプロキシ経由でHTTPSにアクセスすると、CONNECTトンネルのネゴシエーションも表示されます。接続先サイトからHTTPレスポンスが返れば、少なくともサーバーの応答段階まで到達しています。ステータスコードが200以外でも、単純に「システムプロキシが効いていない」と判断することはできません。

3. ブラウザーがプロキシを回避する場合：設定の上書きを順に確認

確認中は接続先URLとノードを固定し、ノード、DNS、ルーティングを同時に切り替えないでください。「Webページが開くか」だけでは判断が粗すぎます。キャッシュ、既存の接続、サイト自体への直接接続によって、実際の通信経路が見えにくくなることがあります。リクエスト時のコアの接続記録を確認し、通信がローカルプロキシに届いているか判断してください。アクセスログを有効にしていない場合、ログがないことだけでリクエストがなかったとは断定できません。

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

   v2rayNのタスクトレイメニューにある「システムプロキシ」から、まず「システムプロキシを解除」を選び、次に「システムプロキシを自動設定」を選びます。使用中のバージョンでメニューがメイン画面の下部にある場合は、同じ名前の項目を選択してください。その後、OSに保存されたアドレスとポートを確認します。

2. プロキシ拡張機能を一時停止

   ChromeまたはEdgeで「拡張機能」→「拡張機能を管理」を開き、プロキシを変更できる拡張機能を一時的に無効にします。通常のシークレットウィンドウでは、すべてのプロキシ設定が分離されるとは限りません。ブラウザーの全プロセスを終了してから再起動し、もう一度確認してください。

3. ブラウザーの設定元を確認

   Chromeでは「設定」→「システム」→「パソコンのプロキシ設定を開く」を選択します。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」を開き、システムのプロキシ設定を使用していることを確認してください。「プロキシーを使用しない」や古い手動プロキシが選択されていないかも確認します。

4. プロキシ除外リストを確認

   システムプロキシの例外、自動構成スクリプト、ブラウザーのルールを確認します。リストに接続先ドメイン、範囲の広すぎるドメインサフィックス、ワイルドカードが含まれていたら、元の値を記録してから範囲を絞ってください。イントラネットやループバックアドレスは通常、プロキシの対象外です。テスト先をそれらだけにしないでください。

5. ポリシーによる上書きを確認

   Chromeではchrome://policy、Edgeではedge://policyを開き、プロキシポリシーが設定されているか確認します。管理対象デバイスで強制されている設定は、管理者に相談してください。ポリシーに上書きされるシステム設定を何度も変更しないでください。

特定のブラウザーだけで問題が起きる場合は、起動用ショートカットにプロキシ関連のオプションが付いていないかも確認してください。ブラウザーのセキュアDNS設定は、プロキシを有効にするスイッチではありません。一部の名前解決に影響しますが、HTTPまたはSOCKSの接続口の設定には代わりません。まずプロキシ設定元を確認し、その後でDNSの問題を個別に調べ、2つの設定を同時に変更しないようにしましょう。

4. 各OSで現在のシステムプロキシを確認する方法

システム設定画面とコマンドの出力を照らし合わせて確認してください。以下のコマンドは設定の読み取りが中心で、システムプロキシを変更するものではありません。サーバーアドレス、ポート、有効状態、自動構成スクリプト、例外リストが、v2rayNの現在の接続口と一致しているかを確認します。

Windows：現在のユーザー設定とWinHTTPを分けて確認

# PowerShell：現在のユーザーのプロキシ設定を確認
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# WinHTTPの別のプロキシ設定を確認
netsh winhttp show proxy

ProxyEnableが1の場合、静的プロキシが有効です。ProxyServerの実際の値も確認してください。自動構成スクリプトは別の設定経路です。netsh winhttp show proxyの結果が直接接続でも、ブラウザーがプロキシを使っていないとは限りません。WinHTTPと現在のユーザーのインターネット設定は別の設定です。表示を一致させるためだけに、設定をむやみにインポートしないでください。

macOS：現在有効なプロキシ設定を確認

scutil --proxy

HTTPEnable、HTTPSEnableと、それぞれのサーバーおよびポートを確認します。ProxyAutoConfigEnableと例外リストも確認してください。Wi-Fi、有線ネットワーク、その他のネットワークサービスを切り替えた場合は、設定を再度読み取ります。以前使用していたネットワークサービスのプロキシ設定が、現在の接続でも使われているとは限りません。

Linux GNOME：デスクトップのプロキシ設定を確認

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy.http host
gsettings get org.gnome.system.proxy.http port
gsettings get org.gnome.system.proxy.https host
gsettings get org.gnome.system.proxy.https port
gsettings get org.gnome.system.proxy ignore-hosts

これらのコマンドは、対応する設定機構を備えたGNOMEセッション向けであり、すべてのLinux環境で使える共通インターフェースではありません。SSHセッション、コンテナー、バックグラウンドサービスは、通常デスクトップのプロキシ設定をそのまま引き継ぎません。デスクトップ側の設定が正しくても、コマンドライン側の環境変数を別途確認してください。

5. 端末のhttp_proxyとhttps_proxyは個別に設定

端末ウィンドウがプロキシを一括設定するわけではありません。設定を読み取るのは、ウィンドウ内で実行するプログラムです。curl、パッケージマネージャー、開発ツールでは、プロキシの対応方法が異なる場合があります。まずcurlで条件をそろえて確認し、その後に各ツールのプロキシ設定を調べましょう。1つのツールで成功しても、端末全体がプロキシ経由になったとは限りません。

macOS / Linux：環境変数の確認と一時設定

# 大文字・小文字の環境変数とプロキシ除外リストを確認
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

# 現在のシェルと、そこから起動する子プロセスにのみ設定
export http_proxy=http://127.0.0.1:10808
export https_proxy=http://127.0.0.1:10808

# 今回のテストではプロキシ除外リストを空にし、終了後に元の設定へ戻す
curl -v --noproxy "" --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

https_proxyのhttpsは、接続先URLのプロトコルを指します。変数の値もhttps://で始める必要があるという意味ではありません。一般的なローカルHTTPプロキシではhttp://127.0.0.1:10808を使い、CONNECTでHTTPSの接続先にアクセスします。プロキシの接続口自体がTLSに対応している場合に限り、HTTPSプロキシのアドレスを指定してください。

• http_proxy：HTTPの接続先にプロキシを使用します。curlではこの変数の小文字形式のみが使われるため、大文字のHTTP_PROXYだけを設定しないでください。
• https_proxy：HTTPSの接続先にプロキシを使用します。他のプログラムでは大文字・小文字の扱いが異なる場合があるため、各ツールのドキュメントを確認してください。
• all_proxy：一部のツールで使われる共通のフォールバックプロキシです。SOCKSアドレスも指定できます。通常はプロトコル別の変数が優先されます。互いに矛盾する値を同時に設定しないでください。
• no_proxy：プロキシを経由しない接続先のリストです。curlでは値を*にすると、すべての接続先がプロキシを回避します。「変数を設定したのに直接接続する」場合に重点的に確認してください。

Windows PowerShell：現在のプロセスに環境変数を設定

# 現在のプロセスに設定されたプロキシ環境変数を確認
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'

# 現在のPowerShellと、そこから起動する子プロセスに設定
$env:http_proxy = 'http://127.0.0.1:10808'
$env:https_proxy = 'http://127.0.0.1:10808'

curl.exe -v --noproxy "" --connect-timeout 5 --max-time 15 https://example.com/ -o NUL

この設定は、すでに起動しているプログラムには反映されず、新しく開いた別の端末にも引き継がれません。継続して使う場合は、ユーザー環境変数またはシェルの設定ファイルを検討してください。setxで保存した値は主に後から起動するプロセスで読み込まれ、現在のPowerShellにはすぐ反映されません。検証が済む前に、誤ったポートを永続的に保存しないでください。

6. よくあるエラーから確認すべき段階を特定

以下はcurlでよく見られるエラーの例です。具体的なアドレスや表示内容は、OSやバージョンによって異なります。最初に失敗した段階から対処してください。ローカルポートに接続できない状態でリモートプロトコルを変更しても意味はありません。接続先からTLSエラーが返っている場合も、「システムプロキシが設定されていない」とは限りません。

証明書の検証エラーが発生しても、検証を長期的に無効にして対処しないでください。システム時刻、証明書の信頼チェーン、ネットワーク上のHTTPS検査装置を確認します。プロキシトンネルを確立できているのにTLSで失敗する場合は、「端末がプロキシ変数をまったく読み込んでいない」問題とは別の段階です。

7. 結果を比較して次の対応を決める。すぐにTUNを有効にしない

TUNは仮想ネットワークインターフェースを使って通信を取り込み、システムプロキシに従わないアプリへの対応に適しています。ただし、権限、ルーティング、DNSなど、新たな確認項目も増えます。システムプロキシの検証に必須ではありません。プロキシを明示した接続がまだ成功していない段階でTUNを有効にすると、原因の切り分けが難しくなります。まずローカル接続口とリモートへのアウトバウンド接続を確認してください。