システムプロキシが効かないときの対処：ブラウザはプロキシ経由なのにターミナルは直結？状況別チェック

「ウェブページは開けるのに、ターミナルのコマンドは直結する」という現象は、ノード自体の障害ではなく、アプリごとにプロキシ設定の読み取り方が異なることが原因になりがちです。v2rayNでコアを起動すると、ローカルでSOCKS、HTTP、または混合プロキシのポートが待ち受けます。システムプロキシのスイッチは、その入口の一つをOSの設定に登録するだけで、すべてのプロセスに同じポートを強制するものではありません。

ブラウザ、デスクトップアプリ、PowerShell、コマンドプロンプト、Linux shellでは、システムプロキシの扱いが一致しません。切り分けでは、ローカルの待ち受けポートが存在するか、アプリがプロキシのアドレスを認識しているか、プロキシ要求が正しい出方向へルーティングされているかの3層に分けて確認します。ノードの遅延だけを調べても、この3層は確認できません。

システムプロキシ・ローカルポート・TUNの違いを整理する

v2rayNの動作は、「コアが待ち受ける段階」と「アプリが接続する段階」に分けられます。ノードを選択してサービスを起動すると、Xrayまたはv2flyコアがまずローカルに受信用ポートを作成します。ブラウザやターミナルがそのポートへリクエストを送って初めて、後続のVMess、VLESSなどのプロトコル接続が行われます。ノードのプロトコルとローカルプロキシのプロトコルは別物です。リモート側がVLESSでも、ターミナルがVLESSを理解する必要はなく、通常はローカルのHTTPまたはSOCKS入口へ接続します。

システムプロキシの影響を受けるのは、OSのプロキシ設定を自動的に読み取るアプリが中心です。一般的なブラウザはこの設定を読み取るため、v2rayNのシステムプロキシを有効にするとウェブページがすぐ開けるようになります。一方、多くのコマンドラインツールは独自の設定ファイル、またはHTTP_PROXY、HTTPS_PROXY、ALL_PROXY環境変数だけを参照するため、ターミナルが対象アドレスへ直接接続することがあります。

v2rayNのシステムプロキシと待ち受けポートを確認する

まずv2rayNのメイン画面で、現在のサーバーがアクティブノードに設定されていることと、画面下部の実行状態に継続的なエラーがないことを確認します。次にログを開き、コアが正常に起動を完了したかを確認してください。サブスクリプションをインポートしたり、一覧の行を選択したりしただけでは、プロキシが有効になったことにはなりません。サブスクリプションはノード設定を提供し、システムプロキシは対応アプリをローカル入口へ誘導します。

1. アクティブノードを確認する

   サーバー一覧からノードを一つ選び、右クリックメニューでアクティブサーバーに設定します。メイン画面下部にコアが実行中と表示されていることを確認し、起動失敗や設定解析エラーの状態で止まっていないか確認してください。

2. ローカルポートを確認する

   「設定」→「パラメータ設定」→「基本設定」を開き、ローカルの待ち受けアドレス、SOCKSポート、HTTPポート、または混合ポートを記録します。以降のコマンドでは、ここに表示された実際の値を使用してください。

3. プロキシモードを設定する

   「システムプロキシ」を開き、「システムプロキシを自動設定」または現在のバージョンに対応する有効化項目を選択します。以前の手動プロキシ設定が残っている場合は、まず「システムプロキシをクリア」を選択してから、もう一度有効にしてください。

4. ルーティングモードを確認する

   「設定」→「ルーティング設定」で現在のルールセットを確認します。テスト中は、対象ドメインが誤って直通の出方向へ送られていないかを確認し、問題がなければ必要な振り分けに戻します。

5. 対象アプリを再起動する

   ブラウザやデスクトップアプリを完全に終了してから再起動します。一部のアプリは起動時にしかシステムプロキシを読み取らないため、実行中にv2rayNのスイッチを切り替えても既存の接続はすぐ更新されません。

WindowsではPowerShellを使ってポートの待ち受けを確認できます。例のポートをv2rayNの画面に表示されている値へ変更してください。

Test-NetConnection 127.0.0.1 -Port 10808
Test-NetConnection 127.0.0.1 -Port 10809

結果のTcpTestSucceededがTrueなら、少なくとも一つのプロセスがそのポートへの接続を受け付けています。ただし、リモートノードが利用可能だと証明されたわけではありません。Falseの場合はv2rayNに戻り、コアの起動、ポートの競合、セキュリティソフトのルールを確認してください。ターミナルの環境変数設定を続けるのは後です。

• ポートが他のプログラムに使用されている場合、ログには通常、待ち受けに失敗したことやアドレスが使用中であることを示すメッセージが表示されます。
• 待ち受けアドレスが127.0.0.1の場合、接続できるのは同じ端末上のアプリだけで、LAN内の他のデバイスから直接利用することはできません。
• ポートを変更した場合はコアの再起動が必要です。以前から開いているターミナルの環境変数も忘れずに更新してください。
• システムプロキシに登録されたポートは、現在のHTTPまたは混合入口と一致していなければなりません。SOCKS専用の入口をHTTPプロキシとして指定しないでください。

ブラウザは正常だがターミナルが直結するときの対処

ターミナルは単なるコマンド実行環境であり、プロキシを読み取るかどうかを決めるのは個々のプログラムです。curl、パッケージマネージャー、スクリプト実行環境、リモートダウンロードツールでは、利用する変数が異なる場合があります。最も確実なのは、まず単一のコマンドでプロキシを明示する方法です。成功を確認してから、現在のセッション、ユーザー環境、またはツール独自の設定ファイルへ登録するか判断します。

まずcurlでプロキシを明示する

ローカル入口がHTTPまたは混合プロキシの場合は、次のコマンドを実行します。--connect-timeout 5で接続段階の待機時間を5秒に制限すると、ポート拒否とリモート応答の遅延を区別しやすくなります。

curl --proxy http://127.0.0.1:10809 --connect-timeout 5 https://example.com/

画面で10808がSOCKS5入口だと確認できた場合は、socks5hを使用します。末尾のhはドメイン名の解決もプロキシ側に任せる指定で、ローカルDNSの結果とプロキシ経路の不一致を避けられます。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 https://example.com/

現在のターミナルセッションに変数を設定する

PowerShellでは、環境変数は現在のウィンドウと、そのウィンドウから起動した子プロセスにだけ適用されます。ウィンドウを閉じると設定は消えるため、切り分けや一時的な作業に適しています。

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5h://127.0.0.1:10808"

curl --connect-timeout 5 https://example.com/

macOSやLinuxのshellでは、同名の変数を使用できます。一部のツールは小文字形式しか認識しないため、切り分けでは大文字と小文字の両方を設定すると確実です。

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export ALL_PROXY="socks5h://127.0.0.1:10808"

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

環境変数が効かないときの確認項目

変数名が正しくても、すべてのツールがそれを使うとは限りません。独自設定を優先するプログラム、HTTPプロキシにしか対応しないプログラム、起動後に変数をキャッシュするプログラムもあります。同じターミナルウィンドウで変数の値を確認し、すぐにリクエストを実行してください。「新しいウィンドウに継承されていない」問題と「プロキシサーバーが利用できない」問題を混同しないことが重要です。

現在のセッションで読み取られている値を確認する

# PowerShell
Get-ChildItem Env:HTTP_PROXY
Get-ChildItem Env:HTTPS_PROXY
Get-ChildItem Env:ALL_PROXY

# macOSまたはLinuxのshell
env | grep -i proxy

• 変数の値に全角引用符、末尾のコメント、改行が含まれていないことを確認してください。
• NO_PROXYまたはno_proxyに対象ドメインが含まれている場合、そのリクエストはプロキシを迂回します。
• デスクトップのショートカットから起動したターミナルは、別のターミナルで設定した変数を引き継ぐとは限りません。
• 起動済みの開発ツールは、後から変更されたシステム環境変数を自動的に読み取らないことが多いため、完全に終了してから再起動してください。
• HTTPプロキシのアドレスは、HTTPS対象へのCONNECTリクエストを処理できます。対象がHTTPSだからといって、存在しないTLS待ち受けポートへ変更する必要はありません。

特定のコマンドだけが動作せず、curl --proxyは成功している場合は、そのツールのプロキシ設定の優先順位を確認してください。システムプロキシ、環境変数、ツール設定に異なる3つのポートを同時に指定すると、リクエストが実際にどの入口へ入ったのかログで判断しにくくなります。

より多くのプログラムを引き受けるならTUNモードを検討する

TUNモードは仮想ネットワークインターフェースでより多くのIPトラフィックを捕捉するため、各アプリがシステムプロキシを自発的に読み取る必要がありません。対象プログラムがシステムプロキシを明確に無視する、環境変数を設定できない、または複数のコマンドラインプロセスをまとめて制御したい場合は、個別設定よりTUNの方が直接的です。ただし、変わるのはトラフィックの入口であり、ノード設定、証明書のドメイン、DNS、ルーティングルールが自動的に修正されるわけではありません。

1. まず、通常のHTTPまたはSOCKS入口から、プロキシを明示したリクエストが成功することを確認します。
2. v2rayNのTUN関連設定で仮想ネットワークアダプターのモードを有効にし、ネットワークインターフェースの作成に必要な権限を、システムの案内に従って許可します。
3. ルーティングルールで、LAN、ループバックアドレス、必要なローカルサービスが直通として保持されているか確認します。
4. ターミナルのリクエストを再テストし、ログに記録された受信タイプ、対象アドレス、出方向のタグを確認します。
5. インターネット全体に接続できなくなった場合は、まずTUNを無効にしてシステムのデフォルトルートが戻ることを確認し、その後DNSと仮想インターフェースの状態を調べます。

TUNはシステムプロキシを読み取らないプログラムに適していますが、ブラウザとターミナルの挙動が一致しないからといって、最初から有効にする必要はありません。プロキシを明示したコマンドなら、ローカルポートが通るか、プロトコル接頭辞が正しいか、ノードが出方向を確立できるかをすばやく確認できます。これらの基本項目が正常であって初めて、TUNの切り分けを明確に始められます。

症状からルーティング・DNS・サブスクリプションの問題を特定する

ブラウザとターミナルの両方がすでにv2rayNへ接続されているのに結果が異なる場合は、ドメイン名の解決とルーティングの照合を確認します。ブラウザは独自のキャッシュを使い、ターミナルはシステムDNSを呼び出すことがあります。両者が異なる対象アドレスを取得すると、geoip、ドメイン、プライベートアドレスのルールも別々に適用される可能性があります。

サブスクリプションリンクが提供するのはノードの一覧です。更新後もアクティブサーバーを選択する必要があります。ノード一覧の更新に成功しても、コアのログに設定を起動できないと表示される場合、システムプロキシが有効なままでも、ブラウザのリクエストは正常に動作していないローカル入口へ送られるだけです。まず起動ログにある最初の設定エラーを解決してください。

切り分け後の検証と復旧

修正後は、一つのウェブページだけで判断しないでください。少なくともローカルポート、明示的なプロキシ、通常のターミナルリクエスト、ブラウザの4項目を確認し、v2rayN終了後にシステムプロキシが解除されることも確認します。これにより、現在のウィンドウでは直ったように見えても、システムに古いポートが残っている事態を防げます。

1. 待ち受けポートを再テストする

   Test-NetConnectionまたは同等のツールで現在のポートへ接続できることを確認し、テスト対象のポートがパラメータ設定に表示された値と完全に一致することを確認します。

2. 明示的なリクエストを実行する

   HTTPまたはsocks5h入口をそれぞれ使ってcurl --proxyを一度ずつ実行し、ローカル入口とプロキシ経路の両方でリクエストが完了することを確認します。

3. 通常のリクエストを実行する

   コマンドから明示的なプロキシ引数を削除し、現在のセッションの環境変数を使ってもう一度リクエストします。成功して初めて、ターミナルのプロキシ設定が有効になったと判断できます。

4. 振り分けログを確認する

   同じ時間帯のアクセスログを確認し、対象ドメインが想定したルールに一致して、プロキシ経由または直通の出方向へ送られていることを確認します。

5. 終了後の復旧をテストする

   v2rayNで先にシステムプロキシをクリアしてから、クライアントを終了します。ブラウザやシステムネットワークが、すでに停止した127.0.0.1ポートを引き続き指していないことを確認してください。

切り分けの順番は一言でまとめられます。まずローカルポートが待ち受けているか確認し、次に明示的なプロキシで経路を検証し、その後ターミナルの環境変数を設定し、最後にTUN、DNS、複雑なルーティングを検討します。ブラウザがプロキシを使えるのは、ブラウザが一つの入口を正常に読み取ったことを示すだけで、すべてのプロセスが制御下にあることを意味しません。

よくある質問