ノードの遅延テストがタイムアウトする、起動後にWebページを開けない、サブスクリプションの更新に失敗する、ログに timeout が出続ける場合に適した内容です。本体のネットワークから始め、システム時刻、DNS、サブスクリプションの状態、サーバーアドレスとポート、VMess または VLESS の設定、転送方式、ローカルプロキシポートを順に確認し、「接続できない」原因を検証可能な具体的な箇所まで絞り込みます。
まず、タイムアウトが発生している層を確認する
「ノードのタイムアウト」は単一の障害ではありません。遅延テストの失敗は、テスト対象が応答できないだけの場合があります。コアのログでタイムアウトが出る場合は、通常、名前解決、TCP接続、TLSハンドシェイクのいずれかが制限時間内に完了していません。ノードは接続済みなのにWebページを開けない場合は、システムプロキシ、ルーティングルール、ローカルDNSが通信を正しく処理できていない可能性があります。まず現象を切り分けることで、後の確認が互いに干渉しません。
調査中はテスト対象のノードを1つだけ残し、システムプロキシやネットワークフィルタールールを同時に変更する他のプログラムは一時的に終了します。十数個のノードを連続して切り替えるのは避けてください。切り替えるたびにログ、DNSキャッシュ、接続状態が変わるためです。同じノードで一連のテストを完了すれば、問題がノード設定にあるのか、すべてのノードに影響する本体ネットワークにあるのかを判断できます。
- 遅延テストがタイムアウトする：まずコアのログを開き、実際にWebページへアクセスします。テスト結果だけを見てノードを削除しないでください。
- 起動直後にエラーが出る：ノードの各項目、ポート形式、コアの種類、ローカルポートの競合を優先して確認します。
- 数秒後にタイムアウトする：DNS、サーバーポートへの到達性、TLS、転送設定を重点的に確認します。
- 接続済みなのに通信がない：システムプロキシ、VPNの通信取得状態、ルーティングルール、DNSの振り分けを確認します。
ステップ1：本体のネットワーク、時刻、DNSを確認する
まずクライアントのプロキシモードを終了し、現在のネットワークから一般的なWebサイトへ正常にアクセスできることを確認します。直通のネットワーク自体が不安定なら、V2Ray、Xray、V2Flyのコアが外部接続を確立するときもタイムアウトします。デスクトップでは有線、無線、モバイルホットスポットをそれぞれ試せます。AndroidではWi-Fiとモバイルネットワークを一度切り替えてみてください。特定のネットワークだけで失敗する場合、原因は通常、ルーター、DNS、またはそのネットワークのポート制限にあり、サブスクリプションではありません。
システム時刻も正確でなければなりません。VMessの認証情報は時刻に関係し、TLS証明書の検証にも正しい日付とタイムゾーンが必要です。数分ずれると、認証失敗、ハンドシェイク異常、または一見通常の接続タイムアウトが発生することがあります。Windows、macOS、Android、Linuxでは、自動の日付・時刻・タイムゾーン設定を有効にし、同期後にクライアントを完全終了してコアを再起動してください。
直通接続を確認
まずクライアントの接続を切断してシステムプロキシを無効にし、ブラウザーで普段使うWebサイトを2つ開きます。ページが頻繁に読み込み中のままになる場合は、本体ネットワークの問題を先に解決し、ノード設定の変更は続けません。
時刻を同期
システムの日付と時刻の設定で自動同期を有効にし、日付、タイムゾーン、現在の分が正しいことを確認します。同期後、v2rayN、v2rayNG、v2flyNGを再起動してください。
ドメインを名前解決
デスクトップではターミナルを開いて名前解決コマンドを実行し、ノードのドメインからIPアドレスが返ることを確認します。タイムアウトが続く場合は、まずシステムDNSを変更してからDNSキャッシュを消去します。
ポートをテスト
WindowsではPowerShellの Test-NetConnection でサーバーポートを確認します。macOSとLinuxでは nc を使ってTCP接続をテストできます。ポートに到達できて初めて、コアがプロトコルのハンドシェイクを続行できます。
ネットワークを切り替える
別の信頼できるネットワークで同じノードを再テストします。新しいネットワークで接続できるなら、クライアント設定はそのままにして、元のネットワークのルーター、DNS、ファイアウォールルールを確認します。
nslookup server.example
Test-NetConnection server.example -Port 443
nc -vz server.example 443コマンド内のドメインとポートは、ノードの実際の値に置き換えてください。ドメインの名前解決に成功しても、DNSに結果があることを示すだけで、ポートが開いているとは限りません。TCPテストに成功しても、基礎接続を確立できたことを示すだけで、UUID、TLS、WebSocketパスなどのアプリケーション層パラメータが正しいとは限りません。両方に成功してもタイムアウトする場合に、プロトコル設定を確認します。
エラー：failed to find an available destination
原因と対処：外部接続先のサーバーアドレスを解決できないか、利用可能な宛先がありません。ドメインのスペルを確認し、システムDNSを切り替え、キャッシュを消去してからコアを再起動します。
エラー：dial tcp: lookup server.example: i/o timeout
原因と対処：DNSクエリが制限時間内に返ってきていません。まず直通ネットワークをテストし、ローカルDNS、ルーターの上位DNS、クライアントのDNS設定を確認します。
エラー：context deadline exceeded
原因と対処：接続またはハンドシェイクが待機時間を超えています。システム時刻が正確であることを確認し、対象ドメインの名前解決とポートへの到達性を個別に検証します。
ステップ2：サブスクリプション、ノードアドレス、ポートを確認する
本体ネットワークが正常になったら、サブスクリプションがまだ有効かを確認します。更新に成功しても、すべてのノードが利用可能とは限りません。クライアントがサブスクリプションを取得して内容を解析できたことを示すだけです。逆に、更新に失敗しても、既存ノードが直ちに無効になったとは限りません。サブスクリプションサーバーに一時的に到達できない可能性もあります。「ノード一覧の取得」と「特定ノードへの接続」は分けて考えてください。
まずサブスクリプショングループで更新を1回実行し、ノード数、名前、更新時刻に変化があるか確認します。更新後にノードが突然0件になった場合は、空の結果で既存リストを上書きして保存しないでください。サブスクリプションURLが完全にコピーされているか、有効期限が切れていないか、URL内のクエリパラメータがコピー時に途中で切れていないかを確認します。サブスクリプションURLは機密性の高い設定情報なので、公開ログや公開ページに貼り付けないでください。
| 確認項目 | 正常な状態 | 異常時の対応 |
|---|---|---|
| サブスクリプションの更新時刻 | 更新完了後に現在時刻が表示される | 完全なサブスクリプションURLをコピーし直し、ネットワークと有効期限を確認する |
| サーバーアドレス | ドメインのスペルが完全で、プロトコルの接頭辞や空白を含まない | サブスクリプションの原文と1文字ずつ照合し、ドメインを勝手に書き換えない |
| サーバーポート | 1～65535の範囲で、サーバー側の設定と一致する | 余分な空白を削除し、サーバーポートにローカルポートを入力していないことを確認する |
| ノードのプロトコル | VMessまたはVLESSの種類が元の設定と一致する | プロトコル名だけを変更せず、ノードの全パラメータを再インポートする |
| TLSの設定 | 有効・無効の状態、サーバー名、ノードの説明が一致する | SNI、トランスポート層のセキュリティ設定、対象ドメインを確認する |
ポートは最も間違えやすい項目です。サーバーポートはリモート側の待ち受けポートで、例として443があります。ローカルプロキシポートはクライアントが現在の端末上で待ち受けるポートで、v2rayNでは10808がよく使われます。用途は完全に異なります。10808をノードのサーバーポートに入力すると、継続的なタイムアウトや connection refused が発生しやすくなります。
- 同じサブスクリプション内のすべてのノードがタイムアウトする：サブスクリプションの状態、本体ネットワーク、DNS、クライアントのコアを優先して確認します。
- 1つのノードだけがタイムアウトする：そのノードのアドレス、ポート、プロトコルパラメータ、サーバー側の状態を優先して確認します。
- サブスクリプションの更新はタイムアウトするが、古いノードは使える：サブスクリプションの取得方法を確認し、接続済みの状態でクライアントの設定に従ってプロキシ経由の更新を試します。
- 更新後の新しいノードは使えず、古いノードは使える：新旧ノードのTLS、転送方式、サーバー名、パスの項目を比較します。
エラー：dial tcp server.example:443: i/o timeout
原因と対処：クライアントが待機時間内にリモートの443ポートへ接続できませんでした。ポートテストコマンドで再確認し、ネットワークを切り替えて本体側の出口制限を切り分けます。
エラー：connect: connection refused
原因と対処：リモートホストが接続を明示的に拒否しています。ポートの誤りやサービスが待ち受けていないことが主な原因です。サブスクリプションから再インポートし、推測でポートを変更して試すのは避けてください。
ステップ3：VMess、VLESS、転送パラメータを項目ごとに確認する
ノードのアドレスとポートに到達できる場合、タイムアウトは通常、プロトコルのハンドシェイクまたはトランスポート層で発生します。VMessとVLESSはいずれもクライアント側とサーバー側の項目を厳密に一致させる必要がありますが、認証方式と利用できる項目は異なります。プロトコルの種類は名称の変更で相互変換できません。サブスクリプションがVLESSを指定しているならVLESSのままにし、ユーザー識別子、暗号化オプション、フロー制御、転送パラメータを元の設定と照合します。
パラメータを確認するときは、記憶で手入力して補うのではなく、サブスクリプションから再インポートするのが基本です。手動設定で抜けやすいのは、TLSサーバー名、WebSocketパス、HTTP Host、gRPC serviceName、Reality公開鍵、shortIdです。1項目でも一致しないと、TCP接続後にハンドシェイク段階で止まることがあります。
プロトコルを確認
ノード編集画面を開き、種類がVMessかVLESSかを確認します。プロトコルのプルダウンだけを変更しないでください。種類が異なる場合はその複製を削除し、完全なサブスクリプションから再インポートします。
ユーザー識別子を確認
UUIDを1文字ずつ照合し、先頭、末尾、ハイフンに注意します。コピー時に空白や改行を含めないでください。VMessではサブスクリプションに指定された追加パラメータも保持します。
トランスポート層を一致させる
TCP、WebSocket、gRPCなどの転送方式が元の設定と一致していることを確認します。WebSocketではパスとHost、gRPCではserviceNameを重点的に確認します。
セキュリティ層を確認
TLSまたはRealityの有効状態を確認します。TLSではサーバー名、Realityでは公開鍵、shortId、フィンガープリントの項目も照合します。
ルーティングを元に戻す
一時的にクライアントのデフォルトルーティングルールで再テストします。デフォルトルールでは使えるのにカスタムルールで失敗する場合は、ドメインルール、IPルール、出力タグの参照を確認します。
エラー：invalid user
原因と対処：サーバーが現在のユーザー情報を認識していません。ノードを再インポートし、UUID、プロトコルの種類、アカウントの有効期限を確認します。認証項目を手動で変更しないでください。
エラー：remote error: tls: handshake failure
原因と対処：TLSハンドシェイクのパラメータが一致していません。システム時刻、サーバー名、対象ドメイン、ノードが要求するセキュリティ設定を確認します。
エラー：websocket: bad handshake
原因と対処：WebSocketリクエストがリモート側で想定どおり受け付けられていません。パス、Host、TLSの状態、サーバーポートがサブスクリプションと完全に一致しているか確認します。
エラー：failed to dial to serviceName
原因と対処：gRPCのサービス名または対象設定が一致していません。サブスクリプションの原文とserviceNameを照合し、WebSocketのパス項目を混用していないことを確認します。
ルーティングの振り分けも、ノード障害に似た現象を引き起こします。たとえば、カスタムルールが対象ドメインを存在しない出力タグへ送ったり、DNSクエリは直通なのに対象接続はプロキシ経由になったりすると、一部のWebサイトが読み込み中のままになることがあります。最も有効な確認方法は、一時的にデフォルトルーティングへ戻し、同じWebサイトをテストすることです。デフォルトルールで成功したら、ドメイン、IP、ルールセットをグループごとに戻します。
ステップ4：クライアントのコア、ログ、ローカルプロキシを確認する
設定項目がすべて正しい場合は、クライアントの実行環境を確認します。v2rayNは主にWindowsデスクトップ環境で使われ、一般的なバージョンでは「設定」→「パラメータ設定」からローカルポートとCoreの種類を確認できます。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。ノードをインポートしたら、クライアントにプロトコルに対応するコアを選択させ、違いを理解しないままCoreの種類を強制的に切り替えないでください。
v2rayN 7.xでよくある設定を例にすると、ローカルのmixedまたはSOCKS待ち受けポートには10808が使われ、HTTPポートは設定に応じて隣接するポートが割り当てられる場合があります。具体的な値は「設定」→「パラメータ設定」に表示される現在の値を確認してください。ブラウザーやシステムプロキシが古いポートを指したままだと、コアが正常に接続していてもWebページは現在のクライアントを経由しません。
- v2rayN：「設定」→「パラメータ設定」を開き、ローカルの待ち受けポートを確認します。続けて、システムプロキシが同じポートを指しているか確認してください。
- v2rayNG：「設定」→「パラメータ設定」を開き、ローカルプロキシポート、ドメイン戦略、DNSオプションを確認します。変更後はいったん接続を停止し、再起動してください。
- v2flyNG：サブスクリプション更新後、現在選択されているノードがまだ有効か確認します。実行ログから、失敗が名前解決、接続確立、プロトコルハンドシェイクのどこで発生したかを判断します。
- Windows：ログに address already in use と表示された場合は、同じポートを使用しているプログラムを終了するか、パラメータ設定で未使用のポートに変更します。
- macOSとLinux：システムのネットワーク設定またはターミナルで、プロキシのアドレス、ポート、環境変数を確認し、古いプロキシ値が引き続き有効にならないようにします。
Windows:
netstat -ano | findstr 10808
macOS / Linux:
lsof -i :10808ログレベルは、接続エラーを確認できる程度に設定します。最後に繰り返されるタイムアウトではなく、最初のエラーを重点的に読み取ってください。最初のエラーには通常、対象ドメイン、ポート、失敗した段階が含まれます。後続のエラーは、ブラウザーのリソース要求による連鎖結果にすぎない場合があります。1回のテストが終わったらログを消去してから単一のWebページを開くと、判断しやすくなります。
エラー：bind: address already in use
原因と対処：ローカルの待ち受けポートが別のプロセスに使用されています。10808など現在のポートを使用しているプロセスを調べ、競合するプログラムを終了するか、クライアントの待ち受けポートを変更します。
エラー：proxy connection ended unexpectedly
原因と対処：ローカルプロキシ接続が途中で閉じられました。コアが動作していること、システムプロキシのポートが一致していることを確認し、その直前のログから本当の原因を特定します。
エラー：no route for domain
原因と対処：カスタムルーティングに、対象へ対応する利用可能な出力先がありません。デフォルトルーティングに戻して再テストし、ルールに対応する出力タグを確認します。
よくある質問と基本の対処順
確認項目が多い場合は、手順を一言でまとめられます。まず直通接続、次に時刻とDNS、その後にサブスクリプションとポート、続いてプロトコルと転送パラメータ、最後にローカルプロキシとルーティングを確認します。「まだだめ」と曖昧に記録せず、「ドメインは解決できるが443ポートに到達できない」のように、各段階で明確な結論を残してください。
速度テストはタイムアウトするのに、Webページは開けます。対処が必要ですか？
まず実際の接続結果を基準にします。遅延テストの対象に到達できない場合や、テスト方法が実際の通信と異なる場合があります。実行ログを開いて2つのWebサイトにアクセスし、接続が安定していて連続したエラーがなければ、速度テストのタイムアウトだけを理由に設定を作り直す必要はありません。
サブスクリプションの更新がずっとタイムアウトします。どうすればよいですか？
サブスクリプションURLが完全にコピーされ、まだ有効であることを確認します。既存のノードに接続できるなら、サブスクリプション設定でプロキシ経由の更新を選択して再試行します。すべてのノードが使えない場合は、まず直通ネットワークでサブスクリプションURLにアクセスできるか確認します。
モバイルネットワークに切り替えると接続できます。何を意味しますか？
通常は、ノード設定が基本的に正しく、問題が元のネットワークのDNS、ルーター、ファイアウォール、ポート制限に集中していることを示します。現在のノードを維持し、元のネットワークでドメインの名前解決とサーバーポートを個別にテストします。
ノードは接続済みなのに、ブラウザーでWebページを開けません。
システムプロキシが有効になっているか確認し、プロキシアドレスが127.0.0.1、ポートがクライアントのパラメータ設定と一致していることを確認します。その後、デフォルトルーティングに戻し、カスタム振り分けルールが通信を誤った出力先へ送っていないか切り分けます。
複数のノードが突然同時にタイムアウトしました。最初に何を変更すべきですか？
ノードを1つずつ編集しないでください。まず直通ネットワーク、システム時刻、DNSを確認し、サブスクリプションを1回更新してコアを再起動します。複数のノードが同時に失敗した場合は、個別ノードのパラメータよりも本体環境やサブスクリプションの状態を優先して確認します。
調査が終わったら、最終的に有効だった設定を残し、テスト中に一時追加した重複ノード、古いプロキシポート、範囲の広すぎるルーティングルールを削除します。次にタイムアウトが発生したときは、ネットワーク、時刻、サブスクリプションの更新時刻、最初のログエラーを直接比較すれば、少ない手順で変化した箇所を見つけられます。