v2rayNのノード接続がタイムアウトする場合の対処法：6つの手順で確認

v2rayNに「タイムアウト」と表示されても、原因がノードサーバーにあるとは限りません。速度テスト、Xrayコア、リモートポート、トランスポートのハンドシェイク、ローカルの待受ポート、システムプロキシはそれぞれ異なる層にあります。どこか1つでも途切れると、Webページが開かない、またはテストがタイムアウトすることがあります。ノードを何度も切り替えるだけでは、本当の原因が隠れてしまいます。

安定して切り分けるには、決めた順番で確認します。まず端末の時刻、次にサブスクリプションの内容、その後に基本ネットワークとリモートポート、ローカルポートとコアの起動状態、プロトコル設定、最後に通信が実際にv2rayNへ入っているかを確認します。低コストで影響範囲の広い項目から始めるため、システムプロキシの状態が未確認のままノード設定を何度も変更する事態も避けられます。

手順1：端末の時刻・タイムゾーン・同期状態を確認する

VMess、TLS、REALITYなどの接続処理では時刻が判定に使われます。システム時刻が大きくずれていると、VMessリクエストが時間範囲の不一致で拒否されることがあります。また、TLS証明書を端末が「まだ有効でない」「期限切れ」と判定する場合もあります。こうした問題では、すべてのノードが同時に異常になることが多く、スリープからの復帰、マザーボードの電源断、仮想マシンの一時停止からの復帰、手動でのタイムゾーン変更後などに発生しやすい傾向があります。

まずタスクバーの時刻が正しいか確認し、システムの日付と時刻の設定でタイムゾーンが所在地と一致していることを確認して、今すぐ同期を実行します。時計を手動で「だいたい合っている」状態にするだけでは不十分です。分単位で合っていても、日付、年、タイムゾーンが誤っていればハンドシェイクに影響します。同期後はv2rayNを終了して再起動し、校正済みの時刻で新しい接続を確立してください。

この段階では、次のようなログの記述を重点的に確認します。コアのバージョンによって文言は多少異なりますが、意味はほぼ同じです。

invalid user
authentication failed
certificate has expired
certificate is not yet valid
TLS handshake error
rejected common/drain

invalid user は、UUIDの入力ミスだけを意味するわけではありません。VMessでは、端末の時刻ずれが認証失敗の原因になることもあります。これまで使えていた複数のVMessノードで同じ時刻に同じエラーが出た場合は、ノードを1つずつ編集する前に時刻を確認してください。ログに証明書の日付範囲の異常が明記されている場合は、トランスポートのセキュリティをすぐ無効にするのではなく、システムの日付とタイムゾーンも確認します。

手順2：サブスクリプションの有効性・更新結果・最新グループのノードを確認する

サブスクリプションURLを保存できても、含まれるノードが有効とは限りません。よくある原因は、サブスクリプションの有効期限切れ、更新リクエストの拒否、空の内容、サーバー側でのポート変更、更新後も旧グループの同名ノードを選択しているケースです。この場合、v2rayNのメイン画面にサーバー情報が残っていても、その情報自体が無効になっている可能性があります。

まず現在選択しているサブスクリプショングループを確認し、対象のサブスクリプションを更新します。リストに内容が残っているかだけでなく、サーバーの追加、削除、更新が明確に表示されたかを確認してください。更新後にサーバー数、ポート、ノード名が変わった場合は、そのグループ内のノードを選び直してアクティブサーバーに設定します。旧情報と新情報の名前が同じ場合、名前だけではどちらを使っているか判断できません。

サブスクリプションの更新に失敗した場合、ログや通知欄には次のキーワードがよく表示されます。

subscription update failed
unauthorized
forbidden
not found
timeout
empty subscription
failed to parse

unauthorized または forbidden は、サブスクリプションの認証状態やURLパラメータが無効になった可能性を示します。not found はリクエスト先のパスが変更された可能性を示し、failed to parse は返された内容がクライアントの想定するサブスクリプションデータではないことを示します。更新処理自体がタイムアウトする場合は、まず現在の直接接続でサブスクリプションのドメインを名前解決・アクセスできるか確認します。アクセス認証情報が含まれる可能性があるため、サブスクリプションURL全体を公開ログや公開ページに貼り付けないでください。

同じサブスクリプション内で1つのノードだけがタイムアウトし、ほかのノードは接続できる場合、サブスクリプション全体の取り込みは成功している可能性が高く、原因はそのノードのリモートポートまたはパラメータにあると考えられます。グループ全体が同時に使えなくなった場合は、サブスクリプションの状態やサーバー側の変更通知を優先して確認します。サブスクリプション内のノードを手動で変更するのは一時的な検証に限ってください。次回更新で上書きされる可能性があるため、最終的な設定は配布元の内容と一致させます。

手順3：名前解決・リモートポート・現在のネットワークを分けて確認する

ノードのアドレスは通常、ドメイン名またはIPアドレスです。接続前に少なくとも、ドメイン名からアドレスを取得できるか、対象のTCPまたはUDPポートに現在のネットワークから到達できるかを確認します。遅延テストがタイムアウトしても、制限時間内にテスト経路が完了しなかったことしか分からず、プロトコル設定の誤りを直接証明するものではありません。

ノードがドメイン名を使用している場合は、まず名前解決の結果を確認します。Windowsでは次のコマンドを使用できます。

nslookup node.example.net

macOSまたはLinuxでも nslookup を使用できます。対応するシステムツールがあれば、dig でレコードを確認することも可能です。アドレスを取得できない、明らかなエラーが返る、ネットワークによって結果が大きく異なる場合は、先にDNSを確認してください。なお、ブラウザーでノードのドメインを直接開く方法は信頼できるテストではありません。VMessやVLESSなどのサービス用ポートは、通常のWebページを提供していないためです。

ドメイン名を解決できたら、次にリモートTCPポートを確認します。Windows PowerShellでは次を実行します。

Test-NetConnection node.example.net -Port 443

macOSまたはLinuxでは次を実行します。

nc -vz node.example.net 443

コマンド内のドメイン名とポートは、ノードの実際の値に置き換えてください。TCPの確認に成功しても、リモートポートとの基本接続を確立できることが分かるだけで、UUID、TLS、WebSocketパス、REALITYの設定が正しいとは限りません。確認が繰り返しタイムアウトする場合は、リモートサービスが待ち受けていない、現在のネットワークがそのポートを制限している、ファイアウォールが接続を破棄している、またはノードのアドレスが到達不能な場所を指している可能性があります。

ネットワークの切り替えは、非常に有効な比較テストです。同じ端末、同じノード、同じ設定が別のネットワークですぐ復旧するなら、クライアント設定自体はおそらく正常です。原因は元のネットワークのDNS、ポートポリシー、ルーティング経路、ゲートウェイ設定に絞られます。反対に、複数のネットワークで同じ段階に失敗する場合は、端末側のコアとノードパラメータを引き続き確認します。

手順4：ローカルポートの競合とXrayコアの起動結果を確認する

v2rayNは、端末上でSOCKS、HTTP、または混合プロキシ用のポートを待ち受ける必要があります。ポートが別のプロセスに占有されていると、Xrayコアの起動に失敗したり、v2rayNの画面は動作していてもローカルアプリがプロキシに接続できなかったりします。よくあるログには address already in use、failed to listen、bind、permission denied があります。

まずv2rayNの設定で現在のローカル待受ポートを確認し、次にそのポートを使用しているプロセスを特定します。以下では 10808 を例にしています。実際の確認では、画面に表示されているポートへ置き換えてください。

Windows：

netstat -ano | findstr :10808

macOS：

lsof -nP -iTCP:10808 -sTCP:LISTEN

Linux：

ss -lntp | grep 10808

占有しているプロセスがv2rayNで起動したコアでない場合は、競合しているプログラムを終了するか、v2rayNで未使用のローカルポートに変更します。ポートを変更した後は、プロキシアドレスを手動設定しているブラウザー、ダウンロードツール、端末の環境変数も更新してください。v2rayNのポートだけを変更してアプリ側に古いポートを残すと、「コアは正常なのにアプリはタイムアウトする」という別の問題が発生します。

ポート競合がないのにログでコアの設定読み込み失敗が示される場合は、エラーが起動段階と接続段階のどちらで発生したかを確認します。起動時に failed to load config、unknown field、failed to create server が出る場合、生成された設定に現在のコアが認識できないフィールドが含まれているか、ポート、ファイル権限、ルーティングルールに問題があることが多いです。まず最近変更したカスタム設定を元に戻し、コアを再起動してください。

ローカルポートが実際に待受状態になっているかも確認できます。v2rayNがコアを起動した後は、ポート確認で該当プロセスが表示されるはずです。コアを停止すると、その待受は消えます。画面上の状態とポートの状態が一致しない場合は、v2rayNを完全に終了し、残ったコアプロセスが終了したことを確認してから再起動します。v2rayNを複数起動すると、同じポートやシステムプロキシ設定を奪い合う可能性があるため、同時に起動しないでください。

手順5：プロトコル・トランスポート・セキュリティ設定を1項目ずつ確認する

リモートポートには接続できるのに、Xrayのログでハンドシェイク段階のエラーが出る場合、最も多い原因はクライアントとサーバーのパラメータ不一致です。ノード名とサーバーアドレスが同じでも、ほかのフィールドをそのまま使えるとは限りません。プロトコル、セキュリティ層、トランスポート方式、認証項目をひとまとまりとして確認してください。

VMessでは、サーバーアドレス、ポート、ユーザーID、セキュリティ設定、トランスポート方式を重点的に確認します。現在のVMess設定では通常AEADが使われるため、関連パラメータはサブスクリプションの内容に従ってください。VLESSでは、アドレス、ポート、ユーザーIDに加えて、暗号化フィールド、トランスポートセキュリティ、flowも確認します。XTLS Visionを使う設定では通常 xtls-rprx-vision が表示されます。クライアントのflowはサーバー設定と一致させる必要があり、別のVLESSノードが接続できるからといって、その設定をそのままコピーしてはいけません。

トランスポート層には、見落としやすい組み合わせの項目もあります。

• WebSocket：パス、Host、TLSの状態、サーバー名を確認します。パスのスラッシュ、大文字と小文字、追加のクエリ文字列も一致判定に影響します。
• gRPC：serviceName、トランスポートセキュリティ、サーバー名を確認します。serviceNameは通常のWebページのパスではないため、任意に置き換えられません。
• TCP：ヘッダーの種類と関連項目がサーバー側と一致していることを確認します。通常のTCPと、特定の偽装ヘッダーを使用する設定は同じパラメータではありません。
• TLS：SNI、証明書のドメイン名、安全でない証明書を許可するかどうかを確認します。通常の構成では、証明書と一致するサーバー名を使用します。
• REALITY：サーバー名、公鍵、shortId、フィンガープリント、flowを確認します。いずれかの項目が欠落している、または途中までしかコピーされていない場合、ハンドシェイクに失敗する可能性があります。

パラメータを確認するときは、記憶を頼りに再入力するのではなく、現在のノードとサブスクリプションの元データを項目ごとに比較するのがおすすめです。まずプロトコル、次にアドレスとポート、その後に認証項目、最後にトランスポートとセキュリティ層を確認します。1回に1つの差分だけ修正して再接続すれば、どの項目が原因だったか判断できます。

同じサーバーに異なるプロトコルの入口が複数ある場合も、ポートを入れ替えてはいけません。あるポートがTCPテストに応答しても、そこにサービスが存在することしか分からず、現在選択しているVMessまたはVLESS設定を受け付けるとは限りません。VLESSのパラメータをVMessの入口へ送ったり、WebSocket設定を通常のTCP入口へ送ったりすると、通常はハンドシェイク段階で切断されます。

手順6：システムプロキシ・ルーティングモード・アプリの通信経路を確認する

ここまでの5つの手順で確認したのは「コアがノードに接続できるか」です。最後に確認するのは「アプリが通信をコアへ渡しているか」です。ノードの遅延テストは成功するのにブラウザーでページを開けない場合は、ノードを交換し続けるのではなく、システムプロキシ、アプリのプロキシ設定、ルーティングルールを優先して確認します。

システムプロキシモードを使う場合は、v2rayNでシステムプロキシの設定が実行されていることを確認し、システムのプロキシアドレスが本機のループバックアドレスと現在の待受ポートを指しているか確認します。以前ポートを変更していると、システム設定に古い値が残っている可能性があります。システムプロキシをもう一度設定した後、対象アプリを終了して再起動し、起動時に読み込んだ古いプロキシ設定を使い続けないようにします。

システムプロキシに従うプログラムもあれば、独自のネットワーク設定を使うプログラムもあります。コマンドラインツールでは、HTTPまたはSOCKSプロキシを個別に設定する必要がある場合もあります。まずシステムプロキシに確実に従うブラウザーでテストし、その後、対象プログラムのプロキシ設定を確認して比較します。ブラウザーは使えるのに特定のプログラムだけがタイムアウトするなら、ノードとv2rayNのコアは通常動作しており、原因はそのプログラムのプロキシ設定にあります。

TUNモードを使う場合は、TUNが正常に起動していることを確認し、インターフェースの作成、ルートの追加、権限に関するエラーがログにないか確認します。permission denied、failed to create interface、operation not permitted は通常、仮想インターフェースまたはルートが確立されていないことを示します。この状態ではノード設定が正しくても、通信は想定どおりコアへ入りません。権限とインターフェースの起動問題を解決した後、DNSが現在のTUN設定で処理されているか確認します。

ルーティングによる振り分けも、「一部のWebサイトだけタイムアウトし、ほかは正常」という現象を引き起こします。v2rayNからリクエストを受けたXrayは、上から順にルールを評価し、直接接続、プロキシ、ブロックのいずれかへ振り分けます。対象ドメインが先に直接接続ルールへ一致し、現在のネットワークから直接接続できなければ、そのサイトだけがタイムアウトします。ブロックルールに一致した場合は、すぐに失敗します。切り分けでは、いったん単純なグローバルプロキシへ切り替えて、原因がノードとルーティングルールのどちらにあるか確認できます。原因を特定したら元のモードに戻し、テストモードを常用するのではなくルールの順序を修正してください。

DNSもルーティングモードの影響を受けます。名前解決で到達不能なアドレスが返る、DNSリクエストが想定した出口へ入らない、アプリが独自のセキュアDNSを有効にしている、といった状況では、通信が決められた経路を迂回することがあります。ログに対象ドメインのリクエストがまったく出ていないなら、通信がまだv2rayNに入っていない可能性があります。リクエストが確認できても最終的な出口が direct または block なら、振り分けルールを確認します。プロキシ出口へ入った後にタイムアウトすることが明確なら、手順3と手順5に戻ってリモート経路とハンドシェイクパラメータを確認します。

最後に一連の動作を再テストする

1. ネットワークリクエストを実行中のアプリを終了し、古い接続が結果に影響しないようにします。
2. v2rayNを再起動し、コアが正常に起動してローカルポートが待受状態になっていることを確認します。
3. パラメータを確認済みのノードを選択し、遅延テストを1回実行して対応するログを確認します。
4. システムプロキシを再設定するか、TUNインターフェースとルートが確立されていることを確認します。
5. 対象アプリを開き、テストリクエストを1つだけ送信して、ログにそのドメイン名または宛先アドレスが表示されるか確認します。
6. ログの出口、エラーが発生した段階、所要時間から、障害がアプリ、ローカルプロキシ、ルーティング、リモートノードのどこにあるか判断します。

6つの手順を終えると、原因は通常いくつかに絞り込めます。端末の時刻またはローカルポートの異常ですべてのノードが使えない、サブスクリプショングループの期限が切れている、現在のネットワークからリモートポートに到達できない、特定ノードのプロトコルパラメータが一致していない、またはノードは正常なのにアプリがシステムプロキシやルーティングを経由していない、といった結論です。ここで原因に応じた対応を取るほうが、手当たり次第に再インストールしたりノードを一括変更したりするより、有効な設定を保ちやすくなります。