V2Rayのノードがタイムアウトして接続できないときの対処法|時刻・ポート・TLS・ルーティングを確認

ノードのテストがタイムアウトする、または接続できない場合は、システム時刻、ローカルポートの競合、TLS・SNI設定、ルーティング、サブスクリプションの有効期限を順に確認します。各項目の確認場所も紹介します。

この記事の要点

まず、コアが起動していないのか、ノードとのハンドシェイクに失敗しているのか、ブラウザーの通信がプロキシに届いていないのかを切り分けます。Windows版v2rayNを中心に操作方法を説明し、Androidでの確認場所も紹介します。時刻、待ち受けポート、TLS、ルーティング、サブスクリプションの順に確認範囲を絞り、変更は一度に1項目だけにして、同じ宛先で再テストしてください。ポート番号は確認例であり、すべてのクライアントの初期値を示すものではありません。

1. まずログを保存し、タイムアウトが発生した段階を特定する

「タイムアウト」は結果であり、障害箇所そのものではありません。TCPポートに接続できてもプロキシ認証が成功したとは限らず、実接続テストに失敗してもノードが停止しているとは限りません。テスト先に到達できない可能性もあります。まずv2rayNのメイン画面下部にあるログ欄で、今回の起動記録と失敗したリクエストの記録を保存し、使用したノード、テスト方法、発生時刻を控えてください。

アプリのリクエストローカル待ち受けルーティング判定ノードとのハンドシェイク宛先からの応答

診断中はノードとHTTPSの接続先を1つずつに固定します。ノード、DNS、コア、ルーティングを同時に切り替えると、次に成功してもどの変更が効いたのか判断できません。v2rayNの右クリックメニューから行うテストはクライアントが開始しますが、ブラウザーの通信はアプリのプロキシ設定またはTUNによる取り込みに依存します。ローカルプロキシに届くまでの経路は異なる場合があります。

2. システム時刻:時刻を同期してから再度ハンドシェイクする

システムの日付が明らかにずれている場合は、まず時刻を合わせてください。TLS証明書には有効期間があり、VMessの認証も時間の範囲に依存します。ノードがVLESSでも、外側のTLSに正しい時刻が必要な点は変わりません。タイムゾーンの表示が正しいだけでは不十分で、実際の日付と時刻も確認してください。

  1. 時刻の設定を開く

    Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、年・日付・現在時刻を確認します。Windows 10も「時刻と言語」から設定しますが、画面名が多少異なる場合があります。

  2. 時刻を同期する

    「時刻を自動的に設定する」をオンにし、「追加の設定」にある「今すぐ同期」を実行します。タイムゾーンは所在地に合わせてください。表示上のタイムゾーンが異なっていても、実際の時刻が正しければ、それだけでTLSが無効になることはありません。

  3. 再テストする

    同期が完了したことを確認してから、v2rayNで同じノードを再度有効にし、同じ方法でテストします。Androidではシステムの「設定」→「システム」→「日付と時刻」で自動設定を確認してください。機種によっては「その他の設定」にあります。

ログに証明書の期限切れが記録されている場合は、エラーに表示された現在時刻が正しいかを先に確認します。時刻を合わせても証明書の期限切れが続く場合は、ノードの提供元にサーバー証明書の確認を依頼してください。「証明書の検証をスキップ」を恒久的な対処として使うのは避けてください。

3. ポートの競合:ローカル待ち受けとリモートポートを区別する

ローカルポートはアプリからのリクエストを受け付け、リモートポートはノードサーバーへの接続に使います。両者は別のものです。例として、ローカルの混合待ち受けポートを10808、リモートのTLSポートを443とします。サーバー編集画面のポートを、ブラウザーに入力するローカルプロキシポートと取り違えないでください。

10808
ローカル待ち受けポートの例(実際の値は設定画面で確認)
443
リモートTLSポートの例(実際の値はノード設定で確認)

v2rayNで「設定」→「パラメーター設定」を開き、Coreの基本設定に関する画面でローカル待ち受けポートを確認します。バージョンによって項目の分類名は多少異なりますが、混合待ち受けは通常「ローカル混合待ち受けポート」と表示されます。例の値をそのまま使わないでください。次にWindowsターミナルで以下の読み取り専用コマンドを実行し、数字を画面に表示された実際のポート番号に置き換えます。

netstat -ano | findstr ":10808"

ローカルアドレスの列に調べているポートがあるか、状態が LISTENING かを確認します。リモートアドレスにそのポートが含まれている接続を、待ち受けとして誤認しないでください。最後の列はPIDです。「タスクマネージャー」→「詳細」でプロセスを照合します。PID列が表示されていない場合は、列見出しを右クリックして該当する列を選択してください。

4. TLSとSNI:元のノード設定を項目ごとに照合する

v2rayNのサーバー一覧で対象ノードを右クリックし、「サーバーを編集」を開きます。まずアドレス、ポート、プロトコルを確認し、続けてTLSと転送の設定を確認します。アドレスは接続先を指定し、SNIはTLSハンドシェイクで使うサーバー名です。常に同じ値とは限らないため、提供元の設定に従ってください。アドレスがIPアドレスだからといって、SNIもIPアドレスに変更してはいけません。

項目確認する内容よくある誤設定
アドレスとポート現在のサブスクリプションにあるノードと一致し、ポートはサーバー側の実際の接続口になっていることローカルポート10808をノードのポート欄に入力する
TLSとSNITLSの種類とサーバー名が提供元の指定と一致していることよく知られたウェブサイトのドメインを適当に入力する
転送設定WebSocketのHostとPath、またはgRPCのserviceNameを確認するアドレスとUUIDだけをコピーし、転送パラメーターを省略する
認証情報UUID、パスワード、プロトコル固有のパラメーターを確認するVMessとVLESSをそのまま置き換えられるプロトコルとして扱う
REALITYのパラメーター公開鍵、shortId、serverNameなど、提供元が指定した項目を確認する一般的なTLS設定と同じように、パラメーターを独自に省略する

WebSocketのHostとTLSのSNIは異なるレイヤーの設定であり、常に同じ項目として扱えるわけではありません。REALITYを使う場合は、選択したコアが現在の設定に対応しているかも確認してください。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用するため、ノード設定への対応を同一とみなすことはできません。v2rayNでは「設定」→「パラメーター設定」のCoreタイプ設定画面で、プロトコルに対応するコアを確認できます。

x509: certificate has expired or is not yet valid

原因:端末の時刻がずれている、またはサーバー証明書の有効期間に問題があります。対処:まずシステム時刻を合わせます。時刻が正しいのにエラーが続く場合は、提供元に証明書の確認を依頼してください。

tls: handshake failure

原因:TLSのネゴシエーションが拒否されています。SNI、サーバー側のポリシー、接続口の設定などが関係している可能性があります。対処:元のサブスクリプション設定とTLS・SNIを照合し、提供元にサーバーログを確認してもらいます。このメッセージだけで原因を一つに特定することはできません。

5. ルーティングと通信の取り込み方法:テスト成功後にアプリの通信を確認する

実接続テストは成功するのにブラウザーで開けない場合は、まずリクエストがクライアントに届いているか確認します。v2rayNのメイン画面下部にある「システムプロキシ」で「システムプロキシを自動設定」を選び、ブラウザー側に別の固定プロキシが設定されていないか確認してください。システムプロキシに従わないアプリは、システムプロキシを有効にしただけでは通信を取り込めません。

  1. まず通信の取り込み方法を固定する。一般的なブラウザーの問題を調べる場合は、ほかのプロキシソフトを終了し、TUNを一時的に無効にして、システムプロキシで再テストします。TUNを確認する必要がある場合は、メイン画面の「TUNを有効にする」の状態と、起動ログに仮想ネットワークアダプターや権限に関するエラーがないかを確認してください。
  2. 次にルーティングを確認する。メイン画面下部の「ルーティング」で現在の設定を確認します。比較のため、対象の通信をプロキシ経由にする全体ルールを一時的に選び、元の設定を控えてからテストし、終了後に元に戻してください。
  3. 適用されたルールを確認する。「設定」→「ルーティング設定」で現在のルールの順序を確認します。コアはルールの順番に沿って照合するため、先にある直接接続またはブロックのルールが、想定していたプロキシルールより先に適用されることがあります。
  4. 最後にDNSを確認する。ドメイン名の解決エラー、特定のドメインだけの異常、または解決結果とルーティングの不一致がある場合に限り、DNSを調べてください。ブラウザーのセキュアDNS、システムDNS、コアのDNSがそれぞれ使われる場合があるため、一度にすべてを変更しないでください。

全体ルールを有効にするとアクセスが回復した場合、UUIDの再発行ではなく、振り分けルールや名前解決の経路を重点的に確認します。ログにリクエストがまったくない場合は、通信の取り込み方法を見直してください。ただし、ログレベルが低いと個々の接続が表示されないことがあります。「記録が見えない」ことだけを根拠に判断しないでください。一時的にログの詳細度を上げた場合は、アクセス内容が長時間記録されないよう、確認後すぐに元へ戻してください。

6. サブスクリプションの期限切れとサーバー障害:比較テストで確認する

サブスクリプションの更新に成功したという表示は、クライアントが設定内容を取得できたことを示すだけです。アカウントに通信量が残っていることや、すべてのノードが稼働していることまでは保証しません。v2rayN上部の「サブスクリプショングループ」メニューから該当するサブスクリプションを更新してください。現在のプロキシが使えない場合は、「現在のサブスクリプションを更新(プロキシを使用しない)」を選び、直接接続での更新を試せます。サブスクリプションのURLに直接アクセスできない場合も、既存のノードを何度も削除せず、まず現在の設定を保存してください。

Android版v2rayNGでは、メイン画面右上のメニューにある「サブスクリプショングループ設定」でサブスクリプションURLを確認し、「サブスクリプションを更新」から更新できます。ノードの編集画面は各ノードのカードから開きます。バージョンによってはグループのメニューに更新操作があるため、更新結果はログとノード一覧の変化で判断してください。スクリーンショットを共有する前に、サブスクリプションURL、UUID、パスワード、QRコードを隠してください。これらの情報があれば接続権限を取得されるおそれがあります。

7. エラーメッセージを読み、再現可能な調査記録を作る

エラーは前後のログとあわせて確認してください。同じ接続拒否のメッセージでも、ローカルの待ち受けアドレスで発生した場合と、リモートノードのアドレスで発生した場合では対処がまったく異なります。以下のメッセージは問題が起きた段階を特定する手がかりになりますが、完全なログの代わりにはなりません。

bind: address already in use

原因:コアがバインドしようとしたローカルアドレスとポートが、すでに使用されています。対処:待ち受けプロセスを特定し、重複したインスタンスを終了するか、ローカル待ち受けポートを変更します。Windowsでは、同じ意味のソケットアドレス使用中エラーが表示されることもあります。

connection refused

原因:接続先から拒否されました。サービスが待ち受けていないか、ポリシーによって明示的に拒否されている可能性があります。対処:まず接続先アドレスを確認します。ローカルアドレスならコアが動作しているか、リモートアドレスならノードのポートとサービスの状態を調べてください。

context deadline exceeded

原因:処理が制限時間内に完了しませんでした。接続の開始、ハンドシェイク、応答の読み取りのいずれかで発生した可能性があります。対処:直前の接続先とエラーの流れから発生段階を確認し、タイムアウト値を延ばして問題を隠さないでください。

no such host

原因:現在の名前解決経路で、対象ホストの有効な解決結果を取得できていません。対処:エラーにあるドメインがノードのアドレスなのかアクセス先なのかを確認し、スペル、ドメインの状態、対応するDNS設定を調べてください。

一通りの確認が終わったら、少なくとも以下の情報を記録してください。再テストに役立ち、提供元との確認の往復も減らせます。設定ファイル全体や、そのままインポートできるノード共有リンクは送らないでください。

v2rayN をダウンロード対応OSとインストール方法を確認