V2Rayノードがタイムアウトして接続できないときの対処法：ローカル設定からサーバーまでの確認手順

「ノードのタイムアウト」は、単独の障害とは限りません。ドメイン解決、TCP接続、TLSハンドシェイク、プロトコル認証、ローカルプロキシ転送のいずれの段階でも発生します。ノードを何度も切り替えて一時的に回避できても、原因が端末、ネットワーク、サブスクリプション、サーバーのどこにあるかは分かりません。

効率的な方法は、障害の切り分け範囲を順に狭めることです。まずクライアントのコアが動作しているか、次にローカルの待受ポートが使えるかを確認し、その後でノード設定、最後にリモートサーバーを調べます。各手順の後にログや接続結果を確認し、複数の項目を同時に変更しないでください。

まず「タイムアウト」が発生した段階を切り分ける

クライアントに赤い遅延表示が出たり、接続テストに失敗したり、ログに timeout が出たりしても、原因が同じとは限りません。1回の接続は少なくとも「クライアントプロセス → ローカルプロキシポート → ドメイン解決 → リモートポート → TLSまたはREALITYハンドシェイク → VMess/VLESS認証」という段階を経ます。前の段階が完了しなければ、次の段階は始まりません。

スクロールするログをいったん消去または一時停止し、問題のあるノードにもう一度接続して、その接続で出力された内容だけを確認します。v2rayNではメインウィンドウ下部のログ欄を確認できます。より詳細な記録が必要な場合は、「設定」→「パラメータ設定」→「基本設定」を開き、ログレベルを一時的に info に変更します。v2rayNGでは左上のメニューから「ログ」を開くと、現在のコアの出力を確認できます。

• すべてのノードで同時に失敗：まずシステム時刻、コア、システムプロキシ、ローカルポート、現在のネットワークを確認します。
• 1つのノードだけ失敗：まずそのノードのアドレス、ポート、通信方式の項目、サーバーの状態を確認します。
• 速度テストは失敗するがウェブページは開ける：テスト先に到達できない可能性があります。遅延結果だけでノードが無効だと判断しないでください。
• クライアントは接続済みだがウェブページを開けない：システムプロキシが有効か、ブラウザーがプロキシを迂回していないか、DNSリクエストが正しいアウトバウンドに送られているかを重点的に確認します。

第1段階：システム時刻、コア、ローカルプロキシポート

VMessは認証に時刻情報を使用し、TLSとREALITYのハンドシェイクも正確な時刻に依存します。システム時刻が数分ずれていると、ドメイン解決やポート接続まではできても、認証段階で失敗することがあります。まずシステム設定で時刻とタイムゾーンの自動設定を有効にし、同期が完了したらクライアントを完全に終了して再起動します。

2つ目の確認ポイントはコアの状態です。クライアントの画面は設定を管理しますが、実際に接続を確立するのはXrayまたはv2flyのコアです。画面に「起動済み」と表示されていても、コアが動作し続けているとは限りません。ポートが使用中の場合、起動直後に終了することがあります。ログに待ち受け成功の記録があるかを基準に判断してください。

1. 時刻を同期する

   システムの日付と時刻の設定を開き、自動時刻と自動タイムゾーンを有効にします。同期後、日付、タイムゾーン、分まで正しいことを確認します。

2. コアを確認する

   v2rayNで「設定」→「パラメータ設定」→「Coreタイプ」を開き、現在のノードに対応するXrayまたはv2flyコアが選択されていることを確認します。保存後、「サービスを再起動」を実行します。

3. ポートを確認する

   v2rayNで「設定」→「パラメータ設定」→「基本設定」を開き、ローカルの待受ポートを記録します。v2rayNGでは左上のメニューから「設定」→「ローカルプロキシポート」に進みます。

4. 使用中のポートを解放する

   ログに address already in use または Only one usage of each socket address が出ていないか確認します。表示される場合は、そのポートを使用している古いプロセスを終了するか、未使用のポートに変更します。

5. プロキシを再起動する

   v2rayNのシステムトレイメニューで、まずシステムプロキシを無効にし、その後「システムプロキシを自動設定」を選択します。Androidでは現在の接続を切断し、3秒待ってから再接続します。

第2段階：アドレス、ポート、ユーザー識別子、暗号化項目

ローカルの待受が正常になったら、ノード情報を一文字ずつ照合します。記憶を頼りに変更しないでください。ノード名はメモにすぎず、接続を左右するものではありません。認証に影響するのは、サーバーアドレス、ポート、プロトコル、ユーザー識別子、通信設定です。

VMessノードでは id、alterId、セキュリティ設定を重点的に確認します。現在の設定では通常 alterId: 0 を使用しますが、最終的にはサーバー設定に従ってください。VLESSノードではUUID、フロー制御、セキュリティレイヤーを確認します。XTLS Visionを使用する場合、一般的なフロー制御値は xtls-rprx-vision です。空欄とこの値を任意に入れ替えないでください。

{
  "address": "node.example.net",
  "port": 443,
  "id": "ノード情報と一文字ずつ照合",
  "security": "reality",
  "flow": "xtls-rprx-vision"
}

第3段階：通信方式、TLS、REALITYパラメータ

アドレスとユーザー識別子が正しくても、ノードがハンドシェイクを完了できるとは限りません。WebSocket、gRPC、TCP、HTTPUpgradeでは項目の構成が異なります。クライアントとサーバーで同じ通信方式を選び、パス、ホスト名、サービス名などの文字列も一文字ずつ一致させてください。

TLSを使用する場合、serverName は通常ハンドシェイクに使うドメイン名です。接続先アドレスと同じとは限りませんが、サーバーの構成に適合している必要があります。REALITYでは publicKey、shortId、serverName、フィンガープリントも確認します。どれか1つでも一致しないと、接続直後に切断されたり、ハンドシェイクがタイムアウトしたりします。

第4段階：サブスクリプションの期限と古いノードのキャッシュを確認する

サブスクリプションURLを開けても、含まれるすべてのノードが有効とは限りません。サーバー側でアドレス、ポート、UUIDが変更され、クライアントの一覧には前回更新時のキャッシュが残っていることがあります。古いノードを手動編集しても一時的な修正にとどまり、次回の更新で上書きされる可能性があります。

v2rayNでは、まず「サブスクリプショングループ」でURLを確認し、「サブスクリプショングループ」→「すべてのサブスクリプションを更新」を実行します。現在のネットワークからURLに直接アクセスできない場合、利用可能なノードがあれば環境に応じてプロキシ経由で更新します。v2rayNGでは左上のメニューから「サブスクリプショングループ設定」を開き、URLを保存してノード一覧に戻り、「サブスクリプションを更新」を実行します。

1. 古い一覧を残す

   更新前に問題のあるノードのアドレス、ポート、更新時刻を記録します。比較材料を失わないよう、先にすべての設定を削除しないでください。

2. URLを確認する

   サブスクリプショングループ設定を開き、URLに改行、空白、コピー漏れがないことを確認します。サービス提供者から新しいURLが案内されている場合は、古いURLを置き換えて保存します。

3. サブスクリプションを更新する

   「すべてのサブスクリプションを更新」を実行し、ログのHTTPステータスと所要時間を確認します。30秒を超えても応答がない場合は、直接更新とプロキシ経由の更新を個別に試します。

4. 項目を比較する

   更新後のノード詳細を開き、旧記録のaddress、port、id、network、securityと比較して、サーバー移行の有無を確認します。

5. 3回再テストする

   更新後のノードを1つ選び、5秒間隔で実際の接続テストを3回実行します。1回成功して2回タイムアウトする場合は、ネットワークのパケットロスとサーバー負荷を引き続き確認します。

第5段階：ネットワークを切り替えてローカルとサーバーの境界を切り分ける

クライアントとノード項目の確認が終わってから、ネットワークの切り分けに進みます。最も簡単な比較テストは、ノード設定を変えずに接続ネットワークだけを切り替える方法です。デスクトップでは現在の固定回線からモバイルホットスポットへ、Androidでは現在のWi-Fiからモバイル通信へ切り替えます。ネットワークを変えてすぐ復旧するなら、原因は元のネットワークのDNS、ルーティング、ポートへのアクセス経路にある可能性が高いです。

逆に、同じノードが2つの独立したネットワークでどちらもタイムアウトし、同じクライアントの他のノードは正常に接続できる場合は、そのノードのサーバーに注目します。この状況でクライアントを再インストールしたり、システムプロキシを何度も切り替えたりしても、通常は結果は変わりません。

• リモートドメインを解決できない場合は、まずノードアドレスがまだ有効か確認し、その後DNSの変更を試します。ドメインを解決後のIPに直接変更しないでください。TLSやREALITYがドメイン名に依存している可能性があります。
• リモートポートが明確に接続を拒否する場合、サーバー管理者はプロセスが動作しているか、待受アドレスが正しいか、受信ポートが許可されているかを確認します。
• リモートポートには到達できるのにプロトコルのハンドシェイクに失敗する場合は、クライアントとサーバーのプロトコル、UUID、セキュリティレイヤー、通信方式の項目を重点的に比較します。
• サーバーログに接続記録がまったくなく、クライアントだけが継続してタイムアウトする場合、問題は通常、サーバーに到達する前のネットワーク経路で発生しています。

よくある質問：速度テスト、システムプロキシ、更新後の異常

決められた順序で確認すると、多くの問題はローカル待受、ノード設定、サブスクリプションキャッシュ、ネットワーク経路、サーバー状態のいずれかに分類できます。次の現象は混同しやすいため、個別に対処してください。