V2Rayの接続がタイムアウトする原因と対処法｜時刻・ポート・TLSハンドシェイクを確認

この記事の概要

v2rayNでノードのテストがタイムアウトする、ブラウザーでページを開けない、v2rayNGは接続済みなのに通信できない場合に役立ちます。まずテスト通信がクライアントを経由しているか確認し、時刻、ローカルの待ち受け、サーバーポート、ハンドシェイク設定の順に調べます。一度に変更するのは1項目だけにし、同じ接続先で再テストしましょう。システムプロキシの問題をノード障害と取り違えにくくなります。

1. まずタイムアウトが発生している箇所を特定する

画面に「タイムアウト」と表示されても、それだけでは原因は分かりません。通信はアプリのプロキシ設定、ローカルの受け入れ口、名前解決、リモート接続、プロトコルのハンドシェイクを順に通ります。前の段階で失敗していれば、TLS設定を正しくしても解決しません。失敗した時刻、ノードのプロトコルとサーバーポート、そのときシステムプロキシとTUNのどちらを使っていたかを記録してください。

アプリのプロキシ設定ローカルの待ち受けリモートアドレスの名前解決サーバーへの接続プロトコルとハンドシェイク

v2rayNはデスクトップクライアントで、実際の接続処理は選択したコアが行います。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。プロトコル、クライアント、コアはそれぞれ異なるものです。トラブル時は「V2Rayが使えない」とだけ記録せず、実際に使用しているコアとバージョンを確認しましょう。

ブラウザーだけで失敗する場合：ブラウザーのプロキシ拡張機能、システムプロキシ、ルーティングルールを確認します。すぐにクライアントを再インストールする必要はありません。
どのアプリでも同じノードに接続できない場合：クライアントのログを確認し、ローカルポート、リモートアドレス、ハンドシェイクの順に調べます。
遅延テストだけ失敗する場合：テスト方式とテスト先を確認します。テスト先に到達できないだけでも、利用可能なノードがタイムアウトと表示されることがあります。
サブスクリプションを更新できない場合：サブスクリプションURLへの接続に関する問題です。インポート済みのノードがすべて使えないとは限りません。

2. システム時刻を合わせてハンドシェイクを再試行する

日付、時刻、タイムゾーンの設定が正しくないと、証明書の有効期間の判定やVMessの時刻ベースの認証に影響することがあります。VLESSではVMessと同じ方式の時刻認証は使いませんが、TLSを有効にしている場合はサーバー証明書の検証が必要です。VLESSだからといって、時刻の確認を省略しないでください。

日付と時刻を確認する

Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、年月日と現在時刻を確認して「時刻を自動的に設定する」をオンにします。タイムゾーンも地域に合っているか確認してください。タスクバーに表示される時刻だけで、システム時刻が正しいと判断しないようにしましょう。
時刻を同期する

同じ画面で「今すぐ同期」をクリックします。同期できない場合は、現在のネットワークから時刻サービスにアクセスできるか確認してください。スリープからの復帰後、仮想マシンのスナップショット復元後、マザーボードの電池に問題がある場合も、時刻を再確認しましょう。
同期状態を確認する

PowerShellを開いて以下の確認コマンドを実行し、時刻ソースと最後に同期が成功した時刻を確認します。再同期する場合は、2つ目のコマンドを管理者として実行してください。サービスが起動していない、または時刻データを取得できない場合は、表示された内容に応じて対処します。
リクエストを再実行する

時刻を修正したら、クライアントの接続をいったん停止して再起動し、同じノードとテスト先で再テストします。Androidではシステム設定で「日付と時刻」を検索し、自動設定をオンにしてください。設定画面の場所は端末によって異なります。

w32tm /query /status
w32tm /resync

3. ローカルポートが実際に待ち受けているか確認する

システムプロキシを有効にしても、コアが正常に起動したとは限りません。システムプロキシの接続先ポートで待ち受けがなければ、ブラウザーは通常すぐに接続エラーを表示します。別のプロセスがそのポートを使用している場合、クライアントがローカルの待ち受けを開始できないこともあります。まずv2rayNの「設定」→「パラメーター設定」で、ローカルの待ち受けポートと受け入れ方式を確認します。メニュー名はバージョンによって異なる場合があるため、現在の画面に表示されている項目を確認してください。

127.0.0.1

ローカルのループバックアドレス。リモートノードではありません

10808

以下はローカルポートの例です。実際の設定を確認してください

443

TLSでよく使われるサーバーポート。固定ではありません

以下ではローカルポート10808を例にします。最初のコマンドで待ち受けプロセスのIDを確認し、2つ目で該当プロセスを調べます。クライアントで別のポートを設定している場合は、コマンド内の数字も変更してください。何も表示されなければ、そのTCPポートで待ち受けているプロセスは見つかっていません。

Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

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

原因：Windowsで、別のプロセスまたは重複起動したクライアントがローカルポートを使用しているときによく発生します。

対処：まずログに記録されたバインド先のアドレスとポートを確認します。不要な重複プロセスを終了するか、ローカルの待ち受けポートを変更し、アプリ側のプロキシ設定も合わせて更新してください。

判断の目安：待ち受けを確認してからシステムプロキシを設定する

ローカルポートで待ち受けていない場合は、まずコアの起動ログを確認します。待ち受けがあり、プロセスも正しい場合は、アプリがHTTP、SOCKS、混合のどの受け入れ方式を使っているか確認してください。SOCKS専用ポートをHTTPプロキシとして指定しないでください。

4. DNSとサーバーポートを分けてテストする

ローカルの待ち受けに問題がなければ、ノードのサーバーアドレスを確認します。サーバーアドレスは接続先を指定し、TLSのSNIはハンドシェイクで使うサーバー名を指定します。両者は異なる場合があります。ノードの編集画面でサーバーアドレスを確認し、サブスクリプションURLやWebSocketのパスをテストに使わないでください。

以下のコマンドはWindows PowerShellで実行します。表示に従ってサーバーのホスト名またはIPアドレスと、ノード設定のリモートポートを入力してください。入力内容はローカルでの診断にのみ使用します。個人のノード情報を含む出力全体を公開ページに貼り付けないでください。

$server = Read-Host "ノードのサーバーのホスト名またはIPアドレスを入力"
$port = [int](Read-Host "ノードのリモートポートを入力")

Resolve-DnsName -Name $server
Test-NetConnection -ComputerName $server -Port $port -InformationLevel Detailed

名前解決に失敗する場合：入力ミス、サブスクリプションの更新状況、現在のDNSが利用できるかを確認します。IPアドレスを入力した場合は、その後のポート接続結果を確認してください。DNS検索の結果だけでノードの状態を判断しないでください。
TcpTestSucceeded : Falseの場合：サーバーが稼働しているか、ポートが正しいか、リモート側のファイアウォールで許可されているか、現在のネットワークで接続が制限されていないかを確認します。
TcpTestSucceeded : Trueの場合：そのときのTCP接続が成功したことを示すだけです。UUID、通信方式、TLS、プロキシ経由の外部接続が使えることまでは証明しません。
ドメインにIPv4とIPv6の両方がある場合：実際に接続したRemoteAddressを確認します。片方のアドレスファミリーで経路に問題があると、断続的にタイムアウトすることがあります。違いを確認してから、アドレスの選択方法を調整してください。

5. TLS、通信方式、認証の順に確認する

リモートのTCPポートに接続できてもプロキシが使えない場合は、ハンドシェイクの設定を確認します。「どちらも443番ポートだから同じ設定」とは限りません。同じポートで異なるサービスを提供できます。また、リバースプロキシはホスト名、パス、サービス名などに応じて通信を転送する場合があります。

確認項目	具体的な設定	よくある間違いと対処
TLS	セキュリティ方式、SNI、証明書名	SNIはサーバー側の設定に合わせます。証明書に含まれる名前とサーバーのIPアドレスは異なる場合があり、任意に置き換えることはできません。
通信方式	TCP、WebSocket、gRPC	クライアントとサーバーで同じ方式を設定する必要があります。通信方式の切り替えは、タイムアウト全般に有効な対処ではありません。
WebSocket	Host、パス	パスの先頭のスラッシュ、大文字・小文字、末尾の文字列は、リバースプロキシのルーティングに影響する場合があります。HostをSNIと同じものとして扱わないでください。
gRPC	serviceName、ALPN	サービス名はサーバー側の設定と一致させます。TLSベースのHTTP/2を使う場合、サーバー側でh2を正しくネゴシエートできる必要があります。
プロトコル認証	UUID、パスワード、flow	実際のプロトコルに応じて認証情報を確認します。VLESSのflowはクライアントとサーバーで同じ設定にする必要があります。
REALITY	公開鍵、shortId、serverName	REALITYには固有のハンドシェイク設定があります。通常のTLS証明書の問題としてだけ扱わないでください。

サブスクリプションから追加したノードの場合は、現在の設定を保存してから該当のサブスクリプションを更新し、変更内容を比較します。手動で変更したノードは次回の更新で上書きされる可能性があるため、変更点を記録してください。SNI、通信方式、サーバーアドレスを一度に変更すると、接続が戻っても原因を特定できません。

エラー：x509: certificate has expired or is not yet valid

原因：PCの時刻が正しくない、またはサーバー証明書が有効期間外です。

対処：まずPCの時刻を合わせ、次にサーバー管理者へ証明書の有効期間と配置状況の確認を依頼してください。

エラー：remote error: tls: handshake failure

原因：接続先がTLSハンドシェイクを拒否しています。SNI、プロトコルのネゴシエーション、サーバー設定などが関係する可能性がありますが、このログだけでは原因を特定できません。

対処：TLS関連の項目を1つずつ照合し、同じ時刻のサーバーログも確認して拒否された原因を調べます。

エラー：websocket: bad handshake

原因：期待したWebSocketへのアップグレード応答を受信できていません。パス、Host、リバースプロキシの転送設定が一致していない場合によく発生します。

対処：ノードのWebSocket設定を確認し、サーバー側でアップグレードリクエストが正しい受け入れ先に転送されているか調べます。

6. 同じリクエストでプロキシ経路を確認する

設定を確認したら、接続先を固定してリクエストを送ります。以下のコマンドは、10808でSOCKS接続を受け付けることを確認済みのローカル受け入れ口を対象にしています。ポートが異なる場合は、実際の設定に合わせて置き換えてください。socks5-hostnameを使うと、接続先のホスト名をプロキシ側で処理できるため、PC上での対象サイトの名前解決がテストに影響しません。

curl.exe --proxy socks5-hostname://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

ここでの10秒と20秒は、診断コマンドで設定する接続タイムアウトと全体の制限時間であり、ノードの性能基準ではありません。正常なHTTPレスポンスヘッダーを受け取れれば、そのリクエストがローカルのSOCKS受け入れ口を経由して処理されたことが分かります。成功以外のステータスコードが返っても、必ずしもプロキシの失敗とは限りません。レスポンスの内容も確認してください。失敗した場合は、同じ時刻のコアのログをすぐに確認します。

ローカルのcurlは成功するが、ブラウザーは失敗する場合：ブラウザーの拡張機能がシステムプロキシを上書きしていないか、システムプロキシのアドレスとポートが正しいか確認します。
ブラウザーでは成功するが、ターミナルでは失敗する場合：ターミナルのアプリがシステムプロキシを参照しているとは限りません。まずプロキシを明示するオプションでテストし、その後環境変数を確認してください。
v2rayNGは接続済みなのにアプリで通信できない場合：AndroidのVPN接続許可、アプリごとのプロキシ対象リスト、別のVPN接続が動作していないかを確認します。
一部のドメインだけ失敗する場合：ルーティングルールの適用結果、接続先のDNS、対象サイトの状態を確認します。ルールによる直接接続の失敗を、ノード全体のタイムアウトと取り違えないようにしてください。

TUNや複雑なルーティングを使っている場合は、テストの通信が実際にどの経路を通るかも確認してください。ローカルプロキシを明示すると、アプリがシステムプロキシを参照しているかどうかの違いを切り分けられますが、クライアント内部のルーティングルールを自動的に回避するわけではありません。ルールの優先順位についてはルーティングと分流の解説をご覧ください。

7. 複数の条件で確認してからリモート側の障害を判断する

ローカルの待ち受け、システム時刻、リモートアドレス、ハンドシェイク設定をすべて確認したら、条件を限定して切り分けます。同じ端末とノードのまま、利用可能な別のネットワークで試します。次に同じネットワークのまま、利用できることが分かっている別のノードを試します。一度に変更する条件は1つだけにしてください。そうすれば結果を解釈できます。

エラー：i/o timeout

原因：読み込みまたは書き込みが制限時間内に完了していません。接続、ハンドシェイク、データ転送のどの段階でも起こり得るため、前後のログから発生箇所を特定する必要があります。

対処：ログに記録された接続先がリモートノードなのか最終的なWebサイトなのかを確認し、該当する段階でポートテストまたは条件を変えた検証を行います。

エラー：connection refused

原因：接続先のポートで待ち受けがないか、接続が明示的に拒否されています。応答がないまま時間切れになるタイムアウトとは異なります。

対処：拒否されたのがローカルの受け入れ口かリモートポートかを確認し、それぞれコアの起動状態、またはサーバーの待ち受けとファイアウォール設定を調べます。

判断の目安：再現できる段階まで問題を絞り込む

同じノードがネットワークを変えると復旧する場合は、まず元のネットワーク経路を確認します。同じネットワークで1つのノードだけ失敗する場合は、そのノードの設定とリモート側の状態を優先して確認してください。いずれも切り分けの手掛かりにすぎません。ログと照合し、速度制限やブロックが原因だと即断しないようにしましょう。

環境を記録：OS、クライアントのバージョン、実際に使っているコアとバージョン、システムプロキシまたはTUNモード。
状況を記録：失敗した時刻、テスト方法、すべてのアプリで失敗するか、最近変更した設定項目。
必要なログを共有：失敗の前後数行を残し、サブスクリプションのトークン、UUID、パスワード、個人のサーバー情報は隠してください。
診断用の設定を元に戻す：調査後は通常のログレベルに戻し、一時的なプロキシ環境変数を解除し、不要になったテストルールを削除してください。

原因を特定できない場合は、トラブルシューティングの手順も確認してください。「どの段階で」「どんなエラーが」「どうすれば再現するか」を把握するほうが、サブスクリプションの更新やコアの切り替え、クライアントの再インストールを繰り返すより解決につながります。