システムプロキシを有効にしても機能しない：ブラウザーとターミナルを分けて確認

「プロキシを有効にした」の意味を分解する

「システムプロキシが有効」なのは、OS にプロキシアドレスが設定されていることを示すだけです。プロキシコアが動作していることや、すべてのアプリがその設定を読み取ることを保証しません。確認前に、アクセス経路を4段階に分けて考えます。アプリがリクエストを送信し、システムプロキシを使うか判断し、ローカルプロキシポートが接続を受け付け、V2Ray または Xray のコアがルーティング規則に従って通信を処理します。

どこか1段階でも途切れると、「ウェブページを開けない」「ターミナルが直接接続する」といった症状になります。たとえば v2rayN でシステムプロキシを設定していてもコアが起動していなければ、ブラウザーは待ち受けていないローカルポートへリクエストを渡します。また、ブラウザーは正常でも、コマンドラインアプリがシステムプロキシを読み取らなければ、ターミナルは対象サイトへ直接接続します。

ブラウザーの経路

デスクトップブラウザーは通常システムプロキシを読み取りますが、独自のプロキシ設定、拡張機能、セキュア DNS を使う場合もあります。まず、ブラウザーが実際にどの設定を使っているか確認します。

ターミナルの経路

curl、パッケージマネージャー、開発ツールは、環境変数や個別の設定ファイルを読み取ることがよくあります。システムプロキシのスイッチだけでは、これらのプログラムに自動適用されないのが一般的です。

v2rayN とローカル待ち受けポートを確認する

ブラウザーやターミナルを調整する前に、ローカルプロキシがリクエストを受け付けられることを確認します。デスクトップ版 v2rayN では、利用可能なサーバーを選択していること、コアが動作中であること、ローカルの HTTP または SOCKS ポートが待ち受け中であることの3条件を満たす必要があります。サブスクリプションをインポートするだけでは、これらは自動的に完了しません。

サーバーとコアの状態を確認する

サブスクリプションを更新したら、サーバー一覧から設定を1つ選び、現在のアクティブサーバーになっていることを確認します。
コアを起動し、メイン画面のステータスバーとログ欄を確認します。起動直後に終了する場合は、ポートの競合、設定項目、プロトコルパラメーターの誤りを先に解消します。
ローカルプロキシの設定を開き、HTTP、SOCKS、混合リスニングのポートを記録します。バージョンや設定の移行状況によって異なるため、古い手順のポート番号だけを頼りにしないでください。
待ち受けアドレスが本機のループバックアドレスであることを確認します。現在のコンピューターだけで使う場合、一般的なアドレスは 127.0.0.1 です。

以下のコマンドは、v2rayN のローカル HTTP プロキシポートが 10809 であることを前提にしています。画面に別のポートが表示される場合は、コマンド内の数字を実際の値に変更してください。このテストではブラウザーの設定を経由せず、curl から HTTPS リクエストをローカル HTTP プロキシへ直接渡します。

curl -I --proxy http://127.0.0.1:10809 https://example.com

HTTP レスポンスヘッダーが返れば、curl はローカルポートに接続でき、プロキシ経路で少なくとも1回リクエストが完了しています。127.0.0.1 への接続に失敗する場合は、コアの稼働状況、ポート番号の誤り、他プロセスによるポート占有を確認します。ローカルポートへの接続後にハンドシェイク、タイムアウト、サーバー拒否が発生する場合は、ブラウザーのスイッチを繰り返し切り替えるのではなく、v2rayN のログとサーバー設定を確認します。

HTTP ポートと SOCKS ポートを区別する

HTTP プロキシと SOCKS プロキシは同じ入口ではありません。SOCKS ポートをシステムの HTTP プロキシ欄に入力すると、アプリが TCP 接続までは確立できても、正しいプロキシネゴシエーションを完了できない場合があります。v2rayN の画面に2種類のポートが表示される場合は、種別に合わせて厳密に使い分けてください。SOCKS プロキシをテストするときは、curl で socks5h を指定できます。

curl -I --proxy socks5h://127.0.0.1:10808 https://example.com

socks5h の h は、対象ドメインの名前解決をプロキシ側で行うことを示します。これにより、ローカル DNS とプロキシ出口で解決結果が異なることによる影響を抑えられます。ここでの 10808 も例示値なので、実際にはクライアントの現在の設定を使ってください。

ブラウザーで機能しない：設定の出所を順番に確認する

多くのデスクトップブラウザーは初期状態で OS のプロキシ設定に従いますが、ブラウザー独自の設定、拡張機能、企業ポリシー、終了していない古いプロセスによって動作が変わります。最初からすべての設定を消去せず、ブラウザーがどこからプロキシ情報を取得しているかを確認しましょう。

ステップ1：システムプロキシのアドレスを確認する

OS のプロキシ設定を開き、アドレスとポートが v2rayN の現在の表示と一致するか確認します。アドレスは通常、本機を指すものであり、サブスクリプションのサーバーアドレスではありません。システムプロキシに設定するのはローカルの入口で、リモートサーバーの情報はクライアント設定とコアが処理します。

v2rayN のシステムプロキシ操作には通常、設定、解除、変更しないといった状態があります。「変更しない」は OS の既存値を書き換えないだけで、現在の値が正しいことを意味しません。過去にポートを変更した、設定フォルダーを切り替えた、別のプロキシツールも使っていた場合、OS に古いポートが残っている可能性があります。

ステップ2：ブラウザーのプロセスを完全に再起動する

表示中のウィンドウを閉じても、ブラウザーのバックグラウンドプロセスが残っていることがあります。プロキシ設定を変更したら、まずタスク管理画面からブラウザーを終了し、その後もう一度起動します。「システムプロキシ設定を使用する」項目がある場合は、手動プロキシや直接接続モードに切り替わっていないか確認してください。

プライベートウィンドウはキャッシュや一部の拡張機能の影響を切り分けるのに役立ちますが、プロセスの再起動の代わりにはなりません。プロキシ拡張機能が特定のドメインを直接接続にしたり、別のポートを使ったりすることもあります。テスト時は、プロキシ規則を書き換える拡張機能を一時的に無効にし、システムプロキシだけを使う明確な経路にします。

ステップ3：HTTP と HTTPS を個別にテストする

システム設定によっては、HTTP と HTTPS のプロキシを別々に入力できます。一方だけ設定すると、もう一方のアドレスへアクセスした際に直接接続したり、失敗したりすることがあります。現在のウェブページは HTTPS へリダイレクトされることが多いため、「トップページは開くのにログインページは開かない」場合も、2つのプロキシ欄の不一致が原因かもしれません。

ローカル HTTP プロキシでは、HTTPS サイトへの通信は通常 HTTP の CONNECT トンネルで転送されます。ここでローカルプロキシのアドレスを、リモートサイトの HTTPS アドレスとして書く必要はありません。重要なのは、ブラウザーが正しいプロキシ種別を使い、待ち受け中のポートへ接続することです。

ステップ4：バイパスリストを確認する

システムプロキシでは通常、プロキシを使用しないアドレスを設定できます。本機のアドレス、ローカルネットワークのドメイン、社内ドメインがバイパスリストに入っていることは珍しくありません。対象ドメインを手動で追加していたり、広範なワイルドカード規則に含まれていたりすると、ブラウザーは直接接続します。テスト時はリスト全体を確認し、先頭の1行だけを見ないでください。

ローカルサイトで localhost や 127.0.0.1 に直接接続するのは、通常は合理的な動作です。ローカル開発サービスをデバッグしている場合、「ローカルアドレスがプロキシを経由しない」ことを障害と考える必要はありません。確認すべきなのは、外部の対象が誤ってバイパス規則に追加されていないかどうかです。

ターミナルで機能しない：プロキシ環境変数を明示的に設定する

ターミナルは単なるコマンド実行環境で、プロキシを使うかどうかを実際に決めるのは個々のプログラムです。curl、言語パッケージマネージャー、ビルドツール、ダウンローダーは異なる変数を読み取ったり、独自設定を持っていたりします。最も一般的な入口は HTTP_PROXY、HTTPS_PROXY、ALL_PROXY です。

PowerShell の現在のセッション

以下の設定は、現在の PowerShell セッションと、そこから起動する子プロセスにだけ影響します。ウィンドウを閉じると通常は無効になるため、切り分けや一時的なダウンロードに適しています。

$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
curl.exe -I https://example.com

対象アドレスが HTTPS でも、HTTPS_PROXY の値には http://127.0.0.1:10809 を指定できます。これはアプリがローカルプロキシへ接続する際のプロトコルであり、対象ウェブページのプロトコルではありません。現在のセッションから変数を削除するには、次を実行します。

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue

Windows コマンドプロンプトの現在のセッション

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
curl -I https://example.com

変数を削除するときは、等号の後を空欄にします。

set HTTP_PROXY=
set HTTPS_PROXY=
set ALL_PROXY=

macOS と Linux の現在の Shell

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
curl -I https://example.com

多くのコマンドラインツールは小文字の変数名を使います。さまざまなプログラムとの互換性を高めるため、現在のセッションで小文字の形式も同時に設定できます。

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"

テストが終わったら変数を削除します。

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

SOCKS 入口を使う

ツールが SOCKS に対応している場合は、ALL_PROXY で入口を指定できます。ここでも SOCKS ポートを 10808 と仮定します。

export ALL_PROXY="socks5h://127.0.0.1:10808"
curl -I https://example.com

すべてのプログラムが socks5h に対応しているわけではなく、ALL_PROXY を読み取るとも限りません。ツールが環境変数を無視する場合は、そのツール独自のプロキシ設定を確認してください。curl が成功したからといって、すべてのパッケージマネージャーが同じ設定を自動的に使うとは限りません。

NO_PROXY でローカルアドレスをバイパスする

開発環境では、本機のサービス、コンテナの入口、ローカルネットワークのインターフェースを直接接続にしたいことがあります。NO_PROXY でバイパス範囲を指定できます。

export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

ドメインのサフィックス、ワイルドカード、ネットワーク範囲の記法に対する対応は、ツールによって完全には一致しません。まずは明確なホスト名とループバックアドレスから始め、広すぎるサフィックスをいきなり指定しないでください。外部ドメインが常に直接接続される場合は、NO_PROXY に誤って追加されていないかも確認します。

プロキシがリクエストを受けた後は、ルーティングと DNS も確認する

ブラウザーや curl がローカルポートへ接続できたら、問題は「アプリがプロキシを使うか」から「コアがリクエストをどう処理するか」へ移ります。V2Ray と Xray は、ドメイン、IP、ポート、プロトコルなどの条件に基づいてルーティングを分岐できます。リクエストがコアに入った後も、直接接続、プロキシ接続、ブロックのいずれかへ送られる可能性があります。

ログでインバウンドとアウトバウンドを確認する

v2rayN のログを開き、対象を明確にしたリクエストをもう一度送信します。ログに新しい接続がまったく現れない場合、アプリがローカルプロキシへ通信を渡していない可能性が高いため、ブラウザー設定や環境変数に戻って確認します。対象ドメインや接続記録が表示されるなら、インバウンドは正常です。対応するアウトバウンドとエラー情報を確認してください。

サブスクリプションが提供するのはサーバー設定の集合で、どのリクエストに現在のサーバーを使うかはクライアントのルーティング規則が決めます。両者は別の層です。サーバーを切り替えても、対象ドメインを明示的に直接接続へ送るローカル規則は修正できません。

ルーティング規則を一時的に簡略化する

カスタム規則が多い場合は、まず現在の設定を保存し、理解しやすいテスト規則で検証します。ノード、DNS、システムプロキシ、ルーティングの4箇所を同時に変更しないでください。成功しても、どの手順が効いたのか判断できなくなります。基本のプロキシ経路を確認した後、ドメイングループ、IP 規則、アプリごとの振り分けを1つずつ戻します。

VMess と VLESS はクライアントからサーバーへの通信に使うプロトコル設定です。システムプロキシと環境変数は、アプリがローカルのインバウンドへ接続する方法にすぎません。ブラウザーが VMess や VLESS を理解する必要はなく、HTTP または SOCKS リクエストをローカルの待ち受けポートへ渡せば十分です。この2つの層を分けて考えると、プロトコル項目の中からブラウザーのプロキシスイッチを探すといった混乱を避けられます。

DNS 経路の違いを見極める

ブラウザーが独自のセキュア DNS を有効にしている場合や、OS にローカルの名前解決キャッシュがある場合があります。SOCKS 使用時には、ドメインをローカル側またはプロキシ側で解決することもあります。経路が一致しないと、同じドメインでもブラウザーとターミナルで異なる結果になる可能性があります。

IP アドレスへの直接アクセスには応答があるのに、ドメイン名では失敗する場合は DNS を重点的に確認します。curl で SOCKS をテストするときは socks5h を選び、プロキシ側で名前解決させることができます。ブラウザーでは、DNS 設定がシステムの動作を上書きしていないか確認します。変更後はブラウザーを再起動し、新しいリクエストでログを確認してください。キャッシュ済みのページを更新するだけでは不十分です。

決まった順番で原因を絞り込む

プロキシ障害では、複数の項目を同時に変更するのが最も危険です。以下の手順はローカルポートから始め、各ステップで1つの事実だけを確認します。失敗した段階で止まり、その層を対処してください。

コアの稼働を確認する。サーバーを選択して v2rayN を起動し、プロセスがすぐ終了していないことを確認します。
実際のポートを記録する。クライアント画面から HTTP と SOCKS の待ち受けポートを読み取り、古いスクリーンショットの番号を使い回さないでください。
ローカルプロキシを明示的にテストする。curl の --proxy 引数でローカルポートへ接続し、システムプロキシや環境変数の影響を切り分けます。
ブラウザーの設定元を確認する。ブラウザーがシステム設定に従っていることを確認し、プロキシを書き換える拡張機能を無効にして、プロセスを完全に再起動します。
ターミナル変数を確認する。HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を読み取り、設定するとともに、NO_PROXY も確認します。
コアのログを確認する。リクエストがローカルインバウンドに入り、最終的にどのルーティング出口へ送られたかを確認します。
最後に DNS を確認する。ドメイン名の解決に異常がある場合に限り、ローカルでの解決結果とプロキシ側の解決結果を比較します。

よくある3つの症状を直接判断する

ブラウザーは成功するが、curl は失敗する: ブラウザーはシステムプロキシを読み取っている可能性が高く、curl は環境変数を読み取っていないか、設定されていません。まず --proxy で明示的にテストします。
curl の明示的なプロキシは成功するが、ブラウザーは失敗する: ローカルポートとコアはおおむね正常です。システムプロキシのポート、ブラウザー独自の設定、拡張機能の規則、バックグラウンドプロセスを重点的に確認します。
ローカルポートには接続できるが、リクエストがタイムアウトする: アプリはプロキシの入口を見つけています。サーバー設定、ルーティング分岐、DNS、ログに記録されたリモート接続エラーを引き続き確認します。

確認が終わったら、一時的な環境変数を削除するか、日常の開発用に有効化・無効化のコマンドを明確に残しておきましょう。設定変更でプロキシポートが変わることがあり、古いポートを永続的に書き込むと、次の障害が Shell の起動ファイルに隠れてしまいます。ポート、プロキシ種別、変更箇所を1か所に記録するほうが、固定の番号だけを覚えるより確実です。