この記事の概要

v2rayNでサーバーを選択し、コアも起動しているのに、ブラウザーがタイムアウトしたりプロキシエラーを表示したりする場合が対象です。まず通信がローカルプロキシに届いているかを確認し、ポートとルーティングを調べてから、DNSとシステム時刻を確認します。Windowsデスクトップを例に、プロキシを明示したリクエストとログを使って、ブラウザー設定・ローカルの待ち受け・リモート接続の問題を切り分けます。一度に変更する項目は一つだけにし、結果を確認してから次に進んでください。

1. コアの起動とWebリクエストの成功を切り分ける

メイン画面に稼働中と表示されても、確認できるのはクライアントが起動処理を行ったことだけで、目的のWebサイトに接続できるとは限りません。サーバー一覧の遅延測定にも限界があります。TCP接続ができてもプロトコル認証の成功を意味せず、テスト用の特定アドレスに接続できても、すべてのサイトに接続できるわけではありません。原因を調べる際は同じ接続先を使い、サイトごとの通信環境の違いを設定変更の効果と取り違えないようにしてください。

現在の設定を保存し、使用中のサーバー、システムプロキシの状態、ルーティングモード、ローカルポート、テスト時刻を記録します。以下の数値は再現テスト用のコマンド引数であり、速度測定の結果でも、すべての環境におけるデフォルト値でもありません。クライアントに表示される待ち受けポートが異なる場合は、以降のコマンドも実際の値に変更してください。

127.0.0.1
ローカルのループバックアドレス。リモートサーバーではありません
10808
この記事でのプロキシポートの例。実際の待ち受けポートを確認してください
15秒
1回のリクエストに設定する合計タイムアウト。失敗したテストを早く終了できます

2. システムプロキシ：ブラウザーの通信がv2rayNに届いているか確認する

システムプロキシとサーバーの選択は別々の設定です。サーバーを選択していても、システムプロキシが解除されていれば、システム設定に従うブラウザーは通常、直接接続します。逆にクライアント終了後もシステムプロキシの設定が残っていると、ブラウザーは待ち受けを停止したローカルポートに接続し続けることがあります。

  1. システムプロキシを有効にする

    v2rayNの「システムプロキシ」メニューから「自動設定システムプロキシ」を選択します。デスクトップ版ではバージョンによってメニューの場所が変わる場合があるため、項目名と実際の状態を確認してください。

  2. システム設定を確認する

    Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシ セットアップ」のアドレスとポートを確認します。クライアントが提供するHTTPまたは混合プロキシの待ち受け設定と一致している必要があります。リモートノードのアドレスを入力するものではありません。

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

    プロキシ切り替え拡張機能を一時的に無効にし、ブラウザー側で別のプロキシが指定されていないか確認します。プロキシを個別に設定するブラウザーは、システムプロキシを使う設定に変更してから、テストページを開き直してください。

  4. 終了時の状態も確認する

    クライアントを終了して直接接続をテストする場合は、「システムプロキシ」→「システムプロキシを解除」から設定を戻します。ウィンドウを閉じただけではタスクトレイに残っている場合があります。ウィンドウが消えたことだけでコアの終了を判断しないでください。

「自動設定システムプロキシ」はクライアントのメニュー操作であり、Windowsで自動構成スクリプトのURLを手動入力する必要があるという意味ではありません。組織から配布されたスクリプトやプロキシポリシーがある場合は、上書きして結果を推測することは避けてください。コマンドラインのプログラムも、必ずしもWindowsのシステムプロキシを使用するとは限りません。次のセクションでは、プロキシを明示する引数を使ってこの不確実性を避けます。

3. ローカルポート：待ち受けを確認してからプロキシを明示してテストする

ポート番号は現在の設定または起動ログから確認してください。バージョンや以前の設定、カスタマイズによってポートが異なることがあります。古いガイドのHTTPポートを、現在の混合ポートにそのまま使わないでください。Windows PowerShellで次のコマンドを実行し、まず例示したポートで待ち受けているか確認します。

netstat -ano -p tcp | findstr ":10808"

ローカルアドレスが127.0.0.1:10808で、状態がLISTENINGの行を探します。最後の列がプロセスID（PID）です。待ち受けアドレスが異なる場合は、実際の設定に基づいて判断してください。次に「タスク マネージャー」→「詳細」でPIDに対応するプロセスを確認し、別のプログラムの待ち受けをv2rayNのコアと取り違えないようにします。

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://www.example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://www.example.com/

この2つのコマンドを使えるのは、該当ポートがHTTP、SOCKS、または両方に対応している場合です。混合ポートなら順番にテストできます。待ち受けが分かれている場合は、それぞれ実際のポートに置き換えてください。--noproxy ""はプロキシ除外リストの影響を避けるための指定です。socks5hでは接続先ドメインの解決をプロキシ側に任せますが、実際にどこで名前解決されるかはコアの設定にも左右されます。テスト用ドメインは比較のために固定しているだけで、どのネットワークでも接続できることを保証するものではありません。

結果まず確認すること次に行うこと
待ち受けがなく、接続がすぐ拒否されるコアが起動していない、ポートの指定ミス、または待ち受けの失敗起動ログとポートの使用状況を確認する
プロキシを明示したリクエストは成功するが、ブラウザーでは失敗するシステムプロキシとブラウザー独自の設定に違いがある可能性システム設定に戻り、プロキシ拡張機能を無効にして再テストする
ローカルの待ち受けは正常だが、リクエストがタイムアウトするルーティング、サーバー接続、名前解決のいずれかに問題がある可能性同じ時刻のコアログと照らし合わせる
接続先サイトからHTTPレスポンスを受信したそのリクエストはHTTPサーバーに到達しているネットワーク接続の成否と、サイト側によるアクセス拒否を切り分ける

4. ルーティングルール：プロキシへの受け渡しと、プロキシ経由の通信を切り分ける

ブラウザーからローカルプロキシにリクエストが渡った後も、コアはルーティング設定に従って、プロキシ経由・直接接続・ブロックのいずれかを選びます。そのため「システムプロキシが有効」でも、すべてのドメインがリモートサーバーを経由するとは限りません。特にカスタムルールを読み込んでいる場合、範囲の広すぎる直接接続ルールによって、接続先へのリクエストがローカルから直接送信されることがあります。

ルーティングにおけるドメインの名前解決方法は、IPアドレスに基づくルールの適用にも影響します。ドメインの解決結果が異なれば、別のルールに一致する可能性があります。すべての問題をノードのせいにするのは適切ではありません。受信・ルーティング・出力の関係を確認したい場合は高度な設定を参照してください。ただし、今回のテストで現在のコアに合わない設定一式をそのまま貼り付けないでください。

5. DNS：サーバーアドレスと接続先ドメインを分けて確認する

名前解決の対象は少なくとも2つあります。リモートサーバー自体のドメインと、ブラウザーがリクエストする接続先ドメインです。前者を解決できない場合、通常はリモートサーバーへの接続前に失敗します。後者の解決に失敗した場合は、一部のサイトだけ開けないことがあります。また、ブラウザーのセキュアDNS、システムDNS、コアのDNSはそれぞれ別の設定です。一つを変更しても、他の経路まで同時に変わるとは限りません。

nslookup www.example.com
ipconfig /flushdns

最初のコマンドで、現在のシステムのリゾルバーが接続先ドメインに返す結果を確認します。ノード設定に記載されている実際のサーバードメインも同様に確認してください。サーバーがIPアドレスで指定されている場合、そのドメイン名の解決は不要です。2つ目のコマンドはWindows DNSクライアントのキャッシュを消去しますが、ブラウザーやコア独自のキャッシュは自動的に消去されません。システムで名前解決できても、プロキシ側での解決が成功した証明にはなりません。

エラー：curl: (5) Could not resolve proxy

原因と対処：プロキシのホスト名を解決できていません。問題は接続先サイトではなく、プロキシの入口にあります。コマンドのプロキシアドレスを確認してください。ローカルでテストする場合は、実際のループバック待ち受けアドレスを指定し、リモートノードのドメインをHTTPプロキシの入口に誤って設定しないようにします。

エラー：curl: (6) Could not resolve host

原因と対処：現在のリクエスト経路で接続先ホストを名前解決できていません。まず、想定どおりプロキシを使ったリクエストになっているか確認します。次にシステムの名前解決、コアのDNS、ブラウザーのセキュアDNS設定を比較してください。ページを何度も再読み込みするだけで復旧を判断しないでください。

エラー：bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

原因と対処：待ち受けの起動時に、アドレスまたはポートが競合しています。ポートを検索してPIDを特定し、プロセスの所有元を確認してから、重複しているインスタンスを終了するか、待ち受けポートを変更してシステムプロキシの設定も合わせます。見覚えのないシステムプロセスをそのまま終了しないでください。

通常のSOCKSリクエストは失敗するのにsocks5hのリクエストは成功する場合、ローカルでの接続先ドメインの名前解決を重点的に確認します。ただし、これは切り分けの手がかりであり、原因を確定するものではありません。暗号化DNSを使っている場合、リゾルバーへの通信経路がプロキシに依存することもあります。プロキシの確立に必要なサーバードメインの名前解決が、まだ確立していないプロキシに依存する構成は避けてください。変更後はコアを再起動し、同じ接続先で再テストします。

6. 時刻同期とハンドシェイク：検証を無効にしてエラーを回避しない

時刻のずれは証明書の有効期間の判定に影響し、VMessなどのプロトコル認証にも影響する場合があります。VLESS自体と、その外側で使われるTLSやREALITYなどの通信セキュリティ設定は分けて考えてください。プロトコル認証エラー、証明書エラー、通信タイムアウトは、それぞれ個別に対処する必要があります。「起動中」と表示されていても、これらの問題がないとは限りません。

  1. Windowsの「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にします。タイムゾーンを確認し、「今すぐ同期」を実行してください。
  2. 同期に失敗する場合は、まずシステム時刻サービスと時刻ソースへのアクセス条件を確認します。組織管理の端末については管理者に確認してください。表示上のタイムゾーンだけを変更し、システム時刻そのものを見落とさないようにします。
  3. もう一度リクエストを送信し、ログに証明書の期限切れ・有効期間前・ハンドシェイク失敗のメッセージが残っていないか確認します。
  4. ノード情報に記載されたサーバーアドレス、ポート、ユーザーID、通信パラメーターを確認します。TLSのサーバー名やREALITYの公開鍵などはサーバー側の設定と一致している必要があります。推測で変更しないでください。

7. よくある質問とトラブルシューティングのまとめ

遅延に数値が出るのに、Webサイトがタイムアウトするのはなぜ？

遅延テストで確認できるのは、そのテストが使う通信経路だけです。まずプロキシを明示したコマンドで固定のURLにアクセスし、対応するログを確認してください。TCPの遅延測定に成功しても、ユーザーIDやTLSパラメーター、接続先サイトへのアクセスが成功したとは限りません。

TUNを有効にすると使えるのは、システムプロキシの故障？

必ずしもそうではありません。アプリがシステムプロキシに従わない場合や、独自のプロキシ設定を使っている場合があります。まずTUNを無効にし、ブラウザーとプロキシを明示したリクエストをそれぞれテストします。プロキシを明示したリクエストは成功し、ブラウザーだけ失敗する場合に、アプリ側の接続設定を優先して見直してください。

別のノードに切り替えたら直った。元のノードが使えなくなったと判断できる？

分かるのは、2つの設定の違いが問題に関係している可能性があることだけです。サーバードメイン、ポート、プロトコル、通信パラメーターを比較して、同じテストを繰り返してください。サブスクリプションの更新でサーバー情報が変わった可能性もあります。配信元を確認して該当するグループを更新し、サブスクリプションURL全体を公開の場に投稿しないでください。

v2rayNを終了した後、すべてのWebサイトが開けなくなった場合は？

まずWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、ローカルプロキシの設定が残っていないか確認します。必要であればv2rayNを再起動し、「システムプロキシ」→「システムプロキシを解除」を実行してから、直接接続をテストしてください。組織管理のプロキシ設定は自分で削除しないでください。

トラブルシューティングが終わったら、一時的に無効にした機能を元に戻し、最終的に動作した設定を保存します。追加のサポートを求める際は、クライアントとコアのバージョン、OS、待ち受けポート、ルーティングモード、発生時刻、個人情報を伏せたログを提示してください。サブスクリプショントークン、ユーザーIDなどの認証情報は削除し、エラーの種類と発生順序は残します。「接続済み」と表示された画面のスクリーンショットだけより、こうした記録のほうが原因を特定しやすくなります。