V2Rayのノードに接続できない・タイムアウトする場合の確認手順｜時刻・ポート・TLSハンドシェイク

この記事の概要

ノードテストがタイムアウトする、ブラウザーでウェブページを開けない、サブスクリプションを更新できないといった場合に役立つチェックリストです。まず時刻とサブスクリプションを確認し、次にローカルの待ち受け状態、リモートポート、ハンドシェイク設定を調べます。各手順で確認できた結果を記録すれば、クライアントが通信を中継していないのか、ネットワークに到達できないのか、プロトコル設定が一致していないのかを切り分けられます。再インストールや複数設定の同時変更は避けましょう。

まずは3種類の「タイムアウト」を切り分ける

タイムアウトは、処理が制限時間内に完了しなかったことを示すもので、ノードの障害を直接意味するわけではありません。サブスクリプションの更新、ノードテスト、ブラウザーでのアクセスでは、それぞれ通信経路が異なります。サブスクリプションURLは通常HTTPSのインターフェースで、ノードへの接続にはノード固有のアドレス、ポート、認証情報を使います。ブラウザーの通信には、システムプロキシまたはTUNによる取り込みも必要です。まずどの操作が失敗したかを記録すると、その後の確認箇所を絞れます。

症状	まず確認する項目	この症状だけでは判断できないこと
サブスクリプションの更新がタイムアウトする	サブスクリプションのドメイン名解決、インターフェースへの到達性、更新時にプロキシを経由しているか	インポート済みのノードがすべて使えない
ノードテストがタイムアウトする	テストの種類、リモートポート、ハンドシェイク設定、テスト先	必ずローカルのシステムプロキシに問題がある
テストは成功するがウェブページを開けない	システムプロキシ、アプリのプロキシ設定、DNS、ルーティングルール	サーバーが必ず正常、または必ず異常である

TCP接続テストでわかるのは、ポートへの接続が確立できるかどうかだけです。UUIDやパスワード、アプリケーションデータの送受信までは検証しません。実際の接続テストはより多くの要素を確認しますが、テスト先のウェブサイトに到達できることも前提になります。2種類のテスト結果を混同しないでください。切り分ける際は、ノード、接続先、テスト方法をそれぞれ1つに固定し、失敗した時刻とコアのログを記録します。異なるテストの結果をつなぎ合わせて結論を出さないようにしましょう。

手順1：システム時刻を同期し、サブスクリプションの状態を確認

TLS証明書には有効期間の開始日時と終了日時があります。端末の時刻が実際の時刻から大きくずれていると、サーバーの証明書に問題がなくても、有効期間前または期限切れと判定されることがあります。VMessの一部の認証処理も時刻に依存します。タイムゾーンの表示が異なるだけなら問題とは限りません。システムに記録された実時刻が正しいか確認してください。

時刻を同期する

Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにします。「その他の設定」で「今すぐ同期」をクリックしてください。同期に失敗したら、まず通常のインターネット接続を確認しましょう。表示上の時刻だけを手動で変更しても解決しません。
プランを確認する

サブスクリプション提供元のアカウントページで、有効期限、残りの通信量、お知らせを確認します。サブスクリプションURLからデータを取得できても、アカウントに接続権限があるとは限りません。また、アカウントが有効でも、以前のノードアドレスが使えるとは限りません。
グループを更新する

v2rayNの「サブスクリプショングループ」メニューから該当グループを更新します。「プロキシを経由せずにサブスクリプションを更新」と「プロキシを経由してサブスクリプションを更新」の選択肢がある場合は、現在のネットワーク状況に応じて選んでください。使えなくなったノードを経由して更新しようとすると、「接続できないと修復できない」という状態に陥ります。
ノードを選び直す

更新が完了したら、グループ内のノードを選び直し、コアに新しい設定が読み込まれていることを確認します。サーバーアドレスやポートが変更されていないかも確認してください。メニューの表記はバージョンによって多少異なる場合があります。現在のバージョンのグループ更新機能を使ってください。

手順2：ローカルポートと通信の入口を確認

まずコアが正常に起動していることを確認し、次にブラウザーのリクエストがコアに渡されているか調べます。v2rayNの画面が開いていても、プロキシコアが待ち受けているとは限りません。「設定」→「パラメータ設定」でローカルの待ち受けポートを確認してください。バージョンによってHTTPとSOCKSのポートが別々の場合や、混合ポートを使う場合があります。実際の設定と起動ログを必ず確認しましょう。

10808

この記事でローカルSOCKSの確認に使うポート例

443

この記事でリモートTLSの確認に使うポート例

15秒

この記事で1回のHTTPテストに設定する上限

上記の数値は確認用の例であり、すべてのノードに共通する固定設定でも、実測速度でもありません。以下のコマンドでWindows PowerShellからローカルの待ち受け状態と、そのプロセスを確認します。実際のポートが10808と異なる場合は、先にコマンドを修正してください。結果が何も表示されない場合、その時点で該当するTCPの待ち受けはありません。まずコアの起動ログを確認しましょう。

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

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

別のプログラムがポートを使用している場合は、まずそのプロセスの用途を確認し、競合するプログラムを終了するかローカルポートを変更します。ポートを変更した場合は、アプリのプロキシ設定も同じポートに更新してください。待ち受けが正常になったら、Windows標準のcurl.exeでSOCKSプロキシを明示して、ブラウザーの設定を介さずにテストできます。

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

socks5hは、接続先のドメイン名をSOCKSプロキシ経由で解決する指定です。ローカルでの接続先ドメイン名の解決がテストに与える影響を抑えられます。ただし、ノードサーバー自体のドメイン名解決の問題は回避できません。
ここでのexample.comは一般公開されているサンプルサイトであり、ノードサーバーのアドレスではありません。テスト先にアクセスできない場合は、正常にアクセスできることを確認済みのHTTPSサイトに変更してください。
HTTPレスポンスが返れば、そのリクエストはプロキシ経路を通過しています。403などのステータスもレスポンスを受信したことを示しますが、接続先へのアクセスが許可されたという意味ではありません。
プロキシを明示したテストは成功するのにブラウザーで失敗する場合は、システムプロキシが同じポートを指定しているか、ブラウザーに個別のプロキシ設定があるかを確認してください。

手順3：DNSからリモートポートまで順に確認

ローカルの入口が正常なら、次にサーバーアドレスを確認します。ドメイン名の名前解決とTCP接続は別の段階です。以下のnode.example.comは架空のノードドメイン名です。実行前にサブスクリプションに記載された実際のサーバーアドレスに置き換えてください。443も実際のサーバーポートに変更します。

Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443 -InformationLevel Detailed

確認結果	意味	次の手順
ドメイン名を解決できない	リモートポートへの接続段階にまだ進んでいない	アドレスの入力ミス、DNSへの到達性、ドメイン名の有効性を確認する
TcpTestSucceeded が False	このネットワークから該当するTCPポートへの接続を確立できなかった	リモート側の待ち受け、ファイアウォール、ネットワーク経路、ポートの入力ミスを確認する
TcpTestSucceeded が True	TCPの3ウェイハンドシェイクに成功した	TLS、通信方式、プロトコル認証を引き続き確認する

サーバーがICMPに応答しない場合があるため、Pingの失敗だけでノードが使えないとは判断できません。反対に、Pingに成功してもサーバーポートが開いているとは限りません。上記のTCP確認はTCPを使うノードにのみ有効です。この結果からUDP通信の状態は判断できません。ドメイン名がIPv4とIPv6の両方を返す場合は、実際の接続でどちらのアドレスファミリーが使われたかにも注意してください。

まとめ：ネットワークを切り替えるときは変数を1つだけ変える

同じ端末、同じノード、同じポートを使い、通常のネットワークとスマートフォンのテザリングでそれぞれテストします。通常のネットワークだけで失敗するなら、そのネットワークの経路や制限を優先して確認します。両方で失敗する場合は、サーバーの状態と設定を確認してください。最初からプロトコルを変更するのは避けましょう。

ローカルのファイアウォールでは、現在のコアプロセスによる外向き接続がブロックされていないか確認します。アップデート後にプログラムのパスが変わった場合は特に注意が必要です。サーバー側では、クラウドファイアウォールやセキュリティグループ、OSのファイアウォール、実際に待ち受けているポートをそれぞれ確認します。すべてのファイアウォールを無効にする方法を恒久的な解決策にしないでください。通常、ローカルプロキシはループバックアドレスのみで待ち受けさせ、認証のない入口をLANに公開しないようにします。

手順4：TLS、通信方式、認証設定を確認

リモートポートに到達できても失敗する場合は、「接続できるか」から「双方のプロトコル設定が一致しているか」へ確認の重点を移します。VLESSとVMessはプロキシプロトコル、TCP、WebSocket、gRPCなどはトランスポート設定、TLSとREALITYは通信の保護に関わる設定です。プロトコル名だけを変更してほかの古い設定を残すと、別のハンドシェイクエラーが発生しがちです。

設定項目	確認する内容	よくある誤解
プロトコルと認証	VMessまたはVLESS、UUID、サーバーが要求するその他の認証設定	ポートが開いていれば認証も必ず正しいと思い込む
TLS serverName	サーバーが要求するSNI名と、証明書の対象となるドメイン名	接続先アドレス、SNI、HTTP Hostにすべて同じ値を設定する
WebSocket	path、Host、リバースプロキシの転送ルール	pathの先頭のスラッシュを忘れる、または古いpathを使い続ける
gRPC	serviceName、TLS、リバースプロキシでのHTTP/2対応	WebSocketのpathをそのままserviceNameとして使う
REALITY	サーバー指定のserverName、公鍵、shortId、使用するflow	REALITYの認証確認に通常のTLS証明書テストを使う

REALITYはXrayエコシステムの機能で、この設定をそのままV2Flyコアに渡して使うことはできません。Androidでは、v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。選択する前に、利用するコアのバージョンが対象のプロトコルや各設定項目に対応しているか確認してください。デスクトップ版のv2rayNでも、クライアント名だけで判断せず、実際に動作中のコアとログを確認しましょう。

通常のTLSノードであれば、OpenSSLをインストールしたLinuxまたはmacOSのターミナルで、証明書とTLSハンドシェイクを個別に確認できます。以下の2つのドメイン名は架空の例です。実際の接続先アドレスと、サーバーが要求するSNIにそれぞれ置き換えてください。

openssl s_client -connect node.example.com:443 -servername tls.example.com -verify_hostname tls.example.com -verify_return_error < /dev/null

このコマンドではVMessやVLESSの認証、WebSocketのパス、gRPCのサービス名は検証できません。
証明書の検証に失敗した場合は、まずシステム時刻、ドメイン名の一致、証明書チェーンを確認してください。証明書検証を長期的に無効にして問題を隠すのは避けましょう。
REALITYでは専用の設定項目を正しく合わせる必要があります。通常のTLSツールでレスポンスを確認できても、REALITYノードが使える証拠にはなりません。
接続先にIPアドレスを指定している場合でも、serverNameには別のドメイン名が必要なことがあります。サーバー設定に従ってください。

手順5：ログの原文から失敗箇所を特定

コアを再起動し、失敗するリクエストを1回だけ実行して、その前後のログを取得します。エラーメッセージはOSやコアのバージョンによって異なることがあるため、接続先アドレス、宛先ポート、アウトバウンドのタグを含む前後の記録も確認してください。以下はよくあるエラーの一部であり、すべての環境で出力される完全なログ行ではありません。

エラー：bind: address already in use

原因：ローカルの待ち受けアドレスとポートが使用中のため、コアが入口をバインドできませんでした。

対処：ポートを調べるコマンドで使用中のプロセスを特定し、競合を解消してからコアを再起動します。ポートを変更した場合は、システムプロキシとアプリの設定も更新してください。

エラー：no such host

原因：ドメイン名の名前解決に失敗しています。ノードのドメイン名の場合も、リクエスト先のドメイン名の場合もあります。

対処：まずログで名前解決に失敗したドメインを確認し、入力ミスと該当するDNS経路を調べます。接続先ドメインの解決失敗をサーバー停止と誤認しないようにしてください。

エラー：connect: connection refused

原因：接続が明示的に拒否されています。ポートでサービスが待ち受けていない場合や、ファイアウォールが接続を拒否している場合によく発生します。

対処：サブスクリプションに記載されたポートを確認します。サーバーを管理できる場合は待ち受け状態とファイアウォールを調べ、管理できない場合は個人情報を伏せた結果を提供元に送ってください。

エラー：i/o timeout

原因：接続または読み書きの段階でタイムアウトしています。このメッセージだけでは、ネットワーク、ハンドシェイク、接続先の応答のどれに問題があるか特定できません。

対処：前後のログからタイムアウトした段階を特定し、まずリモートTCPポートへの接続を確認します。次にハンドシェイク設定を見直し、別のネットワークでも変数を1つに絞って再テストしてください。

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

原因：証明書の有効期間の判定に失敗しています。端末時刻の誤り、またはサーバー証明書の実際の期限切れが原因として考えられます。

対処：まずシステム時刻を同期します。時刻が正しくてもエラーが続く場合は、サーバー管理者に証明書の更新と証明書チェーンの確認を依頼してください。

ログレベルを上げる場合は、短時間の再現テスト中だけ有効にして、終了後に元へ戻します。詳細ログには接続先のドメイン名や接続情報が含まれることがあり、ディスクへの書き込みも増えます。公開の場で相談するときは、操作した時刻、クライアントとコアのバージョン、失敗した段階、エラーの原文を記載し、設定ファイル全体は投稿しないでください。

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

サブスクリプションの更新に成功したのに、ノードがタイムアウトするのはなぜですか？

サブスクリプションの取得とノードへの接続は別の通信経路です。まずアカウントが有効か確認し、新しいノードが選択されているかを確認してください。リモートポートのテストで、ネットワークに到達できないのか、ハンドシェイクに失敗しているのかを切り分けます。設定を取得できたことと、設定が正常に使えることを混同しないでください。

テスト結果は出るのにブラウザーで開けない場合はどうすればよいですか？

まずこの記事のcurl.exeを使い、プロキシを明示して同じ接続先をテストします。成功したら、システムプロキシが有効か、ポートが一致しているか、ブラウザーに個別のプロキシ設定があるかを確認してください。一部のサイトだけ失敗する場合は、該当するルーティングとDNSを調べます。すぐにすべてのノードを変更する必要はありません。

タイムアウト時間を延ばせば直りますか？

接続に時間がかかっても最終的には完了する場合に限り、待ち時間を延ばす意味があります。ポートの誤り、UUIDの不一致、証明書のドメイン名の誤りは、数秒長く待っても解決しません。まず失敗した段階を特定し、その後でテスト時間を調整するか判断してください。

TUNを有効にするとネットワークに接続できません。どこを確認すればよいですか？

まずTUNを無効にし、ローカルSOCKSプロキシを明示して基本的なノード接続を確認します。基本の接続が成功したら、TUNに必要な権限、ルーティングの取り込み、DNS設定を調べてください。TUNとシステムプロキシを何度も切り替えながらノード設定も同時に変更すると、同じ障害を再現しにくくなります。

まとめ：「タイムアウト」のスクリーンショットより、失敗した段階の記録が重要

「時刻とアカウント → ローカルの待ち受け → ドメイン名とポート → TLSと通信方式 → アプリへの通信の受け渡し」の順に結果を記録します。最初に失敗が確認できた箇所が、次に対処すべきポイントです。修正後はその段階から再テストし、最後にブラウザーで実際にアクセスできるか確認しましょう。

修復が完了したら、一時的に変更したログレベルやテスト設定を元に戻し、ローカルの入口が必要な範囲だけに公開されていることを確認します。原因を特定できない場合は、サイト内の接続トラブルシューティングを参照してください。サブスクリプションの更新経路に関する問題は、サブスクリプション管理の説明をご覧ください。問い合わせる際は、すでに確認した内容を明記すると、やり取りや不要な設定変更を減らせます。