このチェックリストは、ノードを導入済みで v2rayN のコアも起動できるものの、ウェブページやターミナルのコマンドが接続に失敗する場合に役立ちます。まずローカルプロキシのポートが待ち受け中か確認し、ブラウザとコマンドラインツールを個別に検証します。最後に DNS、ルーティング、リモートノードを確認すれば、問題がアプリ、システムプロキシ、ローカルインバウンド、リモートアウトバウンドのどこにあるか特定できます。
再現可能なローカルプロキシの基準を作る
「システムプロキシが有効」という表示は、OS にプロキシアドレスが保存されていることを示すだけです。v2rayN のローカルポートが動作中であることや、すべてのアプリがその設定を読み取ることまでは保証しません。確実に切り分けるには、コアが起動中であること、ローカルのインバウンドポートが待ち受け中であること、テスト対象のアプリが実際にそのポートへリクエストを送っていることを確認します。
v2rayN 7.x の一般的な設定では、HTTP プロキシが 127.0.0.1:10809、SOCKS プロキシが 127.0.0.1:10808 で待ち受けることがあります。これらはあくまで代表例で、実際にはクライアント画面のローカルリスニング設定を確認してください。バージョンアップ、バックアップの読み込み、手動でのポート変更後は、古い記事のポート番号が使えない場合があります。
- v2rayN のメイン画面で、対象ノードが現在のアクティブサーバーに設定されていることを確認します。コアの状態が起動失敗や再起動の繰り返しになっていないかも確認してください。
- 「設定」→「パラメータ設定」を開き、ローカル HTTP と SOCKS のリスニングポート、およびリッスンアドレスを記録します。バージョンによってメニュー名が異なる場合は、「ローカルポート」または「インバウンド設定」を含む画面を探してください。
- トレイメニューで「システムプロキシを設定」に相当する有効状態を選び、「システムプロキシを解除」や「システムプロキシを変更しない」を選ばないようにします。切り替え後、テスト用ブラウザを完全に終了してから再起動してください。
- まずは遅延テストを完了できるノードを一つ選び、確認しやすいプロキシモードにルーティングを切り替えます。基準テストに成功したら、元の分流ルールへ戻してください。
ブラウザで確認する：システムプロキシが実際に読み込まれているか
多くのデスクトップブラウザは標準で OS のプロキシ設定を読み込みますが、ブラウザ独自のプロキシポリシー、拡張機能の設定、古いプロセスが影響することもあります。システムプロキシを変更した後にページを更新するだけでは不十分な場合があります。バックグラウンドプロセスが起動時に読み込んだ設定を使い続けることがあるため、ブラウザを完全に終了してから再起動すると、この種の古い状態を切り分けられます。
テストでは通常ウィンドウを使い、プロキシ方式を変更するブラウザ拡張機能を一時停止し、これまで開いたことのないアドレスを選びます。一般的なウェブページにはアクセスできるのに特定のドメインだけ失敗する場合、ローカルプロキシ経路はおそらく接続済みです。次はルーティングの判定、DNS 解決、リモート側を確認し、システムプロキシのオン・オフを繰り返さないでください。
| 確認結果 | 考えられる問題箇所 | 次に行うこと |
|---|---|---|
| すべてのウェブページですぐに接続拒否になる | ローカルポートが待ち受けていない、またはポート番号が間違っている | v2rayN のローカルポートとコアの起動ログを確認する |
| ページが長時間待機した後にタイムアウトする | ノードのアウトバウンド、ネットワーク接続、ルーティングルール | 既知の正常なノードへ切り替え、アウトバウンドのタイムアウト記録を確認する |
| 一方のブラウザは使えるが、もう一方は使えない | ブラウザ独自のプロキシ設定またはバックグラウンドプロセス | 「システムプロキシを使用」を選び、完全終了してから再起動する |
| ドメインは失敗するが、テスト用 IP へ直接アクセスすると応答がある | DNS の問い合わせ経路またはドメインルール | クライアントの DNS 設定とドメインの分流ルールを確認する |
| ブラウザは使えるが、ターミナルのコマンドは直接接続に失敗する | ターミナルツールがシステムプロキシを読み込んでいない | 現在のターミナルにプロキシ環境変数を設定する |
結論：ブラウザで成功しても、すべてのプログラムがプロキシ経由とは限らない
ブラウザのテスト成功で確認できるのは、「ブラウザ→システムプロキシ→ローカルインバウンド→リモートアウトバウンド」という経路が使えることだけです。ターミナル、バックグラウンドサービス、独自にネットワーク接続を管理するプログラムは、プロキシの参照元を個別に確認する必要があります。
ブラウザが直結する場合に確認すること
- ブラウザのネットワーク設定を開き、「システムプロキシを使用」が選択されていることを確認します。手動で入力した古いアドレスになっていないか注意してください。
- システムプロキシのアドレスが
127.0.0.1で、ポートが v2rayN の現在の HTTP ポートと一致しているか確認します。 - プロキシ設定を上書きする可能性のある拡張機能を無効にし、通常ウィンドウでテストを繰り返します。
- システム時刻とタイムゾーンが正確か確認します。時刻のずれが大きいと TLS 接続に失敗し、プロキシが機能していないように見えることがあります。
- v2rayN の実行ログを確認します。ウェブページを更新しても新しい接続記録がまったく増えない場合、リクエストがローカルプロキシに入っていない可能性が高いです。
ターミナルで確認する：環境変数または明示的な引数でプロキシを指定する
コマンドラインのターミナルはプログラムを起動するための入れ物にすぎず、すべてのネットワーク接続を自動的にシステムプロキシへ渡すわけではありません。実際にプロキシを使うかどうかは個々のツールが決めます。HTTP_PROXY と HTTPS_PROXY を読むもの、コマンド引数だけを受け付けるもの、独自の設定ファイルへの記述が必要なものがあります。そのため「ブラウザは開けるのに、ターミナルはタイムアウトする」という場合、ノードが突然使えなくなったのではなく、両者が異なるネットワーク経路を使っていることが多いです。
HTTP プロキシの環境変数に対応するツールでは、まず現在のターミナルセッションだけに一時設定できます。プロキシアドレスのプロトコルは http:// と記述します。アクセス先が HTTPS サイトでも、ツールは HTTP プロキシ経由で CONNECT トンネルを確立するためです。以下では引き続き 10809 を例にしますが、実行前に画面に表示された実際のポートへ置き換えてください。
Windows PowerShell で一時設定する
$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:NO_PROXY="localhost,127.0.0.1"この3行が影響するのは、現在の PowerShell プロセスと、そこから起動する子プロセスだけです。ウィンドウを閉じると設定は自然に消えるため、トラブルシューティングには適していますが、長期的な利用には向きません。現在の値を確認するには $env:HTTPS_PROXY を実行し、削除するには Remove-Item Env:HTTP_PROXY と Remove-Item Env:HTTPS_PROXY を使います。
Windows コマンドプロンプトで一時設定する
set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
set NO_PROXY=localhost,127.0.0.1macOS と Linux の現在の Shell で一時設定する
export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export NO_PROXY="localhost,127.0.0.1"ツールが SOCKS5 に対応している場合は、明示的な引数で 10808 ポートを確認できます。socks5h の h は、プロキシ側で対象ドメインを解決することを示します。これにより「ローカル DNS の失敗」と「プロキシ経路の失敗」を切り分けやすくなります。すべてのプログラムが ALL_PROXY を読み込むわけではないため、初回の検証には明示的な引数が適しています。
curl -v --proxy socks5h://127.0.0.1:10808 https://example.com/
curl -v --proxy http://127.0.0.1:10809 https://example.com/- 明示的なプロキシ指定では成功するのに通常のコマンドは失敗する場合、ツールがシステムプロキシを読み込んでいません。コマンド引数を残すか、プロキシ環境変数を設定してください。
- HTTP プロキシは成功するのに SOCKS5 が失敗する場合、SOCKS ポートとローカルインバウンドの種類を確認してください。2つのポートを入れ替えないようにします。
- 2種類の明示的なプロキシ指定がどちらも失敗する場合、v2rayN に戻って待ち受け状態、アクティブノード、実行ログを確認してください。
- コマンドは接続できるのにダウンロード途中で切断される場合、リモート接続のリセット、ノードの安定性、対象サービスの制限を確認してください。ローカルポートだけを調べても解決しません。
実際のエラーから問題の層を特定する
ターミナルの詳細出力は、「アクセスできない」という表示よりも有用です。curl -v を使う場合、まず 127.0.0.1 と想定ポートへ接続しているか確認し、次にプロキシが対象サイトへのトンネルを確立できたかを確認します。最初の接続で失敗するなら問題はローカルにあります。ローカル接続後にタイムアウトするなら、問題は通常ルーティングまたはアウトバウンド側にあります。
エラー：curl: (7) Failed to connect to 127.0.0.1 port 10809
原因と対処：ローカル HTTP ポートが待ち受けていないか、コマンドで間違ったポートを指定しています。「設定」→「パラメータ設定」でポートを確認し、v2rayN のコアが正常に起動していることを確認してください。
エラー：curl: (5) Could not resolve proxy: 127.0.0.1:10809
原因と対処：プロキシ変数の形式が間違っている可能性があり、ツールが値全体をプロキシのホスト名として扱っています。値を http://127.0.0.1:10809 と記述し、余分な引用符、空白、重複したプロトコルヘッダーを削除してください。
エラー：Proxy CONNECT aborted
原因と対処：HTTP プロキシはリクエストを受け取りましたが、トンネルの確立に失敗しています。ポートの種類を SOCKS と取り違えていないか確認し、v2rayN のアウトバウンドログとアクティブノードを確認してください。
エラー：connection refused
原因と対処：対象アドレスから接続を拒否されています。拒否されたアドレスが 127.0.0.1 ならローカルの待ち受けを確認し、ログにリモートサーバーからの拒否と出ているなら、ノードのアドレス、ポート、プロトコルパラメータを確認してください。
エラー：context deadline exceeded
原因と対処：リクエストが制限時間内に完了していません。まず既知の正常な別ノードへ切り替え、その後 DNS、パケットロス、ルーティングによって対象が誤って直結アウトバウンドへ送られていないかを確認してください。
実行ログを確認する順番
- インバウンド：テストコマンドの実行時に、本機からの新しい接続が記録されているか確認します。記録がまったくなければ、アプリがプロキシを使っていないか、ポートの指定が間違っています。
- ルーティング：対象ドメインまたは IP がプロキシ、直結、遮断のどのアウトバウンドへ送られたか確認します。分流モードでは、ノードの遅延よりルールの一致結果が重要です。
- アウトバウンド：接続タイムアウト、接続拒否、ドメイン解決失敗、認証パラメータの誤りがないか確認します。ここで発生するエラーが、リモートノードに直接関係します。
- レスポンス：トンネル確立後、すぐにリセットされていないか確認します。特定の対象だけで発生する場合は、対象サービスの接続ポリシーも考慮してください。
ブラウザは使えるのに一部のコマンドが失敗する：DNS と分流を確認する
同じドメインでも、ブラウザとターミナルでは異なる名前解決経路を使うことがあります。ブラウザは独自のセキュア DNS 設定を使う場合がありますが、ターミナルツールは通常 OS のリゾルバーを呼び出します。socks5:// ではローカルで解決し、socks5h:// ではプロキシ側で解決することがあります。解決場所が異なれば、取得するアドレスやルーティングの一致結果も変わります。
分流ルールも、「使えるプログラムと使えないプログラムがある」という状態を生みます。V2Ray または Xray のコアは、ドメイン、IP、ポート、インバウンドタグに基づいてアウトバウンドを選択します。対象ドメインが直結ルールに分類されると、アプリがローカルプロキシへ接続していても、リクエストは直結経路から送信されることがあります。この場合、システムプロキシが無効なのではなく、修正すべきなのはルーティングの判定です。
- まずテスト対象を、安定していてアクセスできることが確認済みのアドレスに変更し、単一サイトの障害をプロキシ障害と取り違えないようにします。
socks5h://127.0.0.1:10808とhttp://127.0.0.1:10809をそれぞれ1回ずつテストし、ローカル解決経路だけが失敗していないか比較します。- v2rayN のルーティング設定で、対象ドメインに一致したルールを確認し、一時的により単純なプロキシモードへ切り替えて比較します。
- カスタムルールを有効にした場合だけ失敗するなら、ドメインサフィックス、IP 範囲、ルールの順序を一つずつ確認します。前方のルールがリクエストを先に捕捉している可能性があります。
- DNS やルーティングを変更した後はコアを再起動し、新しいターミナルウィンドウを開きます。古い接続や環境変数が結果に影響するのを防ぐためです。
結論：リクエストがローカルインバウンドに入っているかを先に確認する
実行ログに新しい接続がない場合は、アプリのプロキシ設定を確認します。インバウンドはあるのに利用可能なアウトバウンドがない場合は、ルーティングとノードを確認してください。この境界で切り分けるほうが、ノードを何度も変更するより安定した結論にたどり着けます。
よくある問題と復旧方法
テストが終わったら、一時的な変更を整理して元に戻します。次回起動時に古い変数、古いポート、新しい設定が上書きし合うのを防ぐためです。特に環境変数へ長期保存した設定があると、v2rayN を終了してもコマンドラインツールが元のローカルポートへ接続し続け、接続拒否が繰り返されることがあります。
システムプロキシは有効なのに、ブラウザが直結するのはなぜ？
まずブラウザを完全に終了し、ブラウザのネットワーク設定で「システムプロキシを使用」が選択されていることを確認します。ページの更新と同時に v2rayN のログも確認してください。新しいインバウンド記録がなければ、リクエストはまだローカルプロキシに入っていません。
ブラウザは正常なのに、curl がずっとタイムアウトするのはなぜ？
まず --proxy http://127.0.0.1:10809 を付けたコマンドを実行します。明示的なプロキシ指定で成功したら、現在のターミナルに HTTP_PROXY と HTTPS_PROXY を設定してください。
HTTP ポートと SOCKS ポートは混用できますか？
できません。HTTP クライアントは HTTP インバウンドへ、SOCKS5 クライアントは SOCKS インバウンドへ接続します。例としてポートが 10809 と 10808 の場合でも、入力時はクライアントの実際の設定を優先してください。
v2rayN を終了した後、ターミナルでネットワークに接続できない場合は？
現在のセッションまたはシステムに保存されたプロキシ環境変数を削除し、新しいターミナルを開きます。ツールに独自のプロキシ設定がある場合は、127.0.0.1 の古いポートを指す項目も削除してください。
1つのドメインだけ開けない場合、クライアントを再インストールする必要はありますか？
通常は必要ありません。まずそのドメインの DNS 結果とルーティングの一致を確認し、単純なプロキシモードで比較します。他の対象に問題がなければ、ローカルの待ち受けと基本的なプロキシ経路は通常利用できます。
トラブルシューティング後の仕上げチェックリスト
- 一時的に切り替えたグローバルプロキシモードを、元のルーティング分流設定へ戻します。
- テストにだけ使用した
HTTP_PROXY、HTTPS_PROXY、ALL_PROXYの環境変数を削除します。 - システムプロキシのポートが、v2rayN の現在のローカル HTTP ポートと一致していることを確認します。
- 正常なノード、ポート番号、テストコマンド、重要なエラーをテキストで記録しておきます。次回は失敗した層からすぐに確認できます。
- ノードを変更して復旧した場合は、しばらく様子を見て、一時的なネットワーク変動とノード設定の誤りを区別します。