この確認手順は、v2rayN、v2rayNG、v2flyNGにノードを読み込んでいるものの、遅延テストがタイムアウトする、起動後にウェブページを開けない、またはログに接続エラーが繰り返し表示される場合に適しています。まずローカルネットワークを確認し、次に時刻、サブスクリプション、プロトコル設定、サーバー状態を確認します。各段階が終わるたびに再テストすると、問題の発生箇所をより早く特定できます。
1つ目：ローカルネットワークとプロキシの入口を確認する
「ノードのタイムアウト」は、クライアントが規定時間内に期待した応答を受け取れなかったことを示すだけで、ノードが無効になった証拠ではありません。ブラウザーからリモートサーバーへのリクエストは、システムプロキシ、ローカル待受ポート、V2RayまたはXrayのコア、DNS、ルーター、現在のネットワークを経由します。どこか1か所でも接続できなければ、クライアント上ではタイムアウトとして表示されます。
まずクライアントを完全に終了し、普段そのまま開けるウェブサイトをブラウザーで2つ確認します。通常のウェブサイトも開けない場合は、ルーターへの再接続、別の利用可能なネットワークへの切り替え、ログイン確認が必要な公衆ネットワークのページの確認など、ローカルネットワークを先に復旧します。この状態でサブスクリプションを何度更新しても結果は変わりません。サブスクリプションの取得自体にも、正常な基礎ネットワークが必要だからです。
基礎ネットワークが正常になったらクライアントを起動しますが、タスクトレイのアイコンだけで判断しないでください。v2rayN 7.xを例にすると、メインウィンドウの下部またはログ欄でコアが起動しているか確認し、現在選択されているサーバーも確認します。一般的なローカル待受ポートはSOCKSが10808、HTTPが10809ですが、バージョンや個別設定によって異なります。「設定」→「パラメーター設定」に表示されるポートを基準にしてください。ポートが他のプログラムに使用されていると、コアの起動に失敗してもシステムプロキシは古いポートを参照し続けることがあります。
古いプロセスを終了する
v2rayNを終了したらタスク管理ツールを開き、以前のV2RayまたはXrayコアのプロセスが終了していることを確認してからクライアントを再起動します。古いプロセスによるローカルポートの占有を防ぐためです。
待受ポートを確認する
「設定」→「パラメーター設定」を開き、ローカルのSOCKS、HTTP、または混合プロキシのポートを控えます。そのうえで、ブラウザーや他のアプリに設定されているポートがクライアントと一致しているか確認します。
システムプロキシを再設定する
まずシステムプロキシをクリアし、その後もう一度有効にします。クライアントの異常終了後に残った古いアドレスやポートを修正できます。
ローカルネットワークを切り替える
可能であれば別のネットワークで同じノードをテストします。元のネットワークでは3回連続でタイムアウトする一方、別のネットワークでは1～3秒で接続できる場合、原因は元のネットワークまたはルーターにある可能性が高くなります。
2つ目：システム時刻とタイムゾーンを調整する
VMessの認証処理は時刻に依存するため、端末の時計が大きくずれていると認証に失敗することがあります。TLSを使用するVMess、VLESS、その他の設定でも、証明書の有効期間が確認されます。端末の日付、タイムゾーン、自動時刻合わせに問題があると、ノード接続に失敗するだけでなく、サブスクリプションページで証明書の時刻エラーが表示されることもあります。
時刻が1分しかずれていないように見えても、対処する価値があります。通常は端末で時刻とタイムゾーンの自動取得を有効にし、画面に表示された時刻だけを手動で変更しないでください。タイムゾーンの変更後、長時間のスリープ後、マザーボードの時計の異常、ルーターによる時刻同期の阻止などがあると、表示時刻と実際の標準時刻が一致しないことがあります。
Windows
「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」を有効にして、「今すぐ同期」をクリックします。完了後、v2rayNを終了して再起動します。
macOS
「システム設定」→「一般」→「日付と時刻」を開き、「日付と時刻を自動的に設定」を有効にして、現在のタイムゾーンが所在地と一致していることを確認します。
Android
システムの「設定」で日付と時刻の項目を開き、「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」を有効にします。その後、v2rayNGまたはv2flyNGを完全に停止して再起動します。
時刻を合わせた後は、遅延テストをもう一度行うだけでなく、クライアントのコアを再起動してください。失敗した接続、DNSキャッシュ、古いセッションがプロセス内に残っている可能性があります。時刻を合わせる前はすべてのノードに失敗し、合わせた後に複数の異なる地域のノードが同時に復旧したなら、原因はサブスクリプション内の特定サーバーではなく端末の時刻にあると判断できます。
エラー: x509: certificate has expired or is not yet valid
原因と対処:TLS証明書が実際に期限切れになっている場合もあれば、端末の日付が実際の時刻とずれている場合もあります。まずシステム時刻とタイムゾーンを同期してください。1つのノードだけエラーが続く場合は、サーバー管理者に証明書を確認してもらいます。
エラー: invalid user
原因と対処:認証情報がサーバーに受け付けられていません。VMessの場合はまず時刻を合わせ、UUID、alterId、サブスクリプションの内容が完全か確認します。複数のパラメーターを一度に変更すると、原因を追跡できなくなるため避けてください。
結論：すべてのノードが同時に失敗するなら、端末に共通する条件を確認する
同じ端末上の複数の独立したノードが同時刻にすべてタイムアウトする場合は、ネットワーク、システム時刻、ローカルポート、コアの状態を優先して確認します。単一のリモートサーバーが同時に故障しただけでは、この一貫した現象を説明できません。
3つ目：サブスクリプションが有効で、実際に更新されているか確認する
サブスクリプションURLをクライアントに追加できても、含まれるノードが常に有効とは限りません。期限切れ、通信量の上限到達、アクセス認証情報の変更、新しいノードが生成されたのにクライアントが前回のキャッシュ済みリストを使い続けている、といった可能性があります。サブスクリプションの更新とノードのテストは別の操作です。前者は設定を取得し、後者で初めて設定内のサーバーへの接続を試みます。
v2rayNでは、「サブスクリプショングループ」から対象グループを選び、「すべてのサブスクリプションを更新」を実行します。現在のプロキシが使えない場合は、クライアントが無効なノードを使って新しいサブスクリプションを取得しないよう、まず「プロキシを経由しない」での更新を試してください。更新後はノード数、サーバーアドレス、更新時刻が変わったか確認します。「更新完了」と表示されたことだけを見て終わらせないでください。
サブスクリプションにアクセスできるか確認する
基礎ネットワークが正常な状態でサブスクリプションを再更新し、クライアントの表示が成功、HTTPエラー、解析失敗、接続タイムアウトのどれなのかを確認します。結果によって対処方法は異なります。
グループの内容を確認する
現在使用しているサブスクリプショングループを更新していることを確認します。複数のグループがあると古いノードがリストに残ることがあり、似た名前のため選択を間違えやすくなります。
ノードを選び直す
更新後、新しいリストからサーバーを選び、アクティブサーバーとして明示的に設定します。リストを更新しただけでは、現在のアクティブ項目が新しい設定に切り替わるとは限りません。
3つのノードをテストする
異なるアドレスまたは地域のノードを3つ選び、それぞれ2回テストします。1つだけ失敗するなら単一ノードの問題である可能性が高く、3つとも近い時間帯にタイムアウトするなら、引き続き設定やサービス状態を確認します。
エラー: unexpected EOF
原因と対処:サブスクリプションの応答またはリモート接続が完了前に切断されています。まずサブスクリプションを再取得してください。更新には成功したのに接続時もこのエラーが出る場合は、トランスポート層の設定とサーバー状態を確認します。
エラー: failed to parse config
原因と対処:インポートした内容が、現在のクライアントまたはコアが想定する設定形式に合っていません。直前にインポートした異常なコピーを削除し、サブスクリプションを再更新します。ウェブページのURL、説明文、途中で切れた内容をノード設定として読み込んでいないことも確認してください。
エラー: failed to find an available destination
原因と対処:アウトバウンドの接続先を確立できていません。サーバーのドメイン名を解決できない、利用可能なアウトバウンド経路がない、といった手がかりが考えられます。ノードアドレスの綴り、DNS設定、アクティブなアウトバウンドを確認してからコアを再起動します。
4つ目：プロトコル、トランスポート、TLS設定を1項目ずつ確認する
ノードのアドレスとポートに到達できても、プロトコル設定が正しいとは限りません。VMessとVLESSでは認証情報の項目が異なり、TCP、WebSocket、gRPCなどのトランスポート方式も相互に置き換えられません。UUID、ポート、トランスポート方式、パス、サービス名、TLSの有効化、サーバー名のいずれか1つでも一致しなければ、接続がタイムアウトしたり、すぐ切断されたり、ハンドシェイクで失敗したりします。
確認時に、経験だけでポートをすべて443へ変更したり、WebSocketだからといってパスを適当に入力したりしないでください。ポート443はTLSでよく使われますが、サーバーは別のポートで待ち受けることもあります。WebSocketのHostとPath、gRPCのserviceNameは、サーバー設定と一致していなければなりません。サブスクリプションから読み込んだ設定は通常そのまま維持し、明確なパラメーターを確認できた場合にだけ項目ごとに修正します。
| 確認項目 | VMess | VLESS | よくある症状 |
|---|---|---|---|
| ユーザー識別子 | UUID、最新の設定ではalterIdは通常0 | UUID、一部の設定にはflowも含まれる | 認証失敗、接続直後に切断 |
| トランスポート方式 | TCP、WebSocket、その他指定された方式と一致させる | TCP、WebSocket、gRPCなど指定された方式と一致させる | ハンドシェイクのタイムアウト、unexpected EOF |
| TLS設定 | TLSの有効化とサーバー名を確認する | TLS、サーバー名、サブスクリプションで指定されたセキュリティ設定を確認する | TLS handshake timeout、証明書名のエラー |
| 追加フィールド | WebSocketではHostとPathの確認が必要なことが多い | gRPCではserviceNameの確認が必要なことが多い | サーバーから拒否される、または接続待ちが続く |
クライアントで使用するコアがその設定を処理できることも確認してください。v2rayNでは「設定」→「パラメーター設定」→「Coreタイプ」から使用中のコアを確認または変更できます。メニュー名はバージョンによって多少異なります。VLESS固有の機能を含む設定は、通常、互換性のあるXrayコアで処理します。Androidでは、v2rayNGはXrayコア、v2flyNGはv2flyコアを使用するため、両者がすべての設定項目に完全対応しているとは限りません。
設定がサブスクリプション由来の場合は、元のノードを残し、コピーを1つ作って項目ごとに変更するのが最も安全です。1回につき1項目だけ変更して、コアを再起動します。たとえば、まずポート、次にトランスポート方式、その後にTLSとサーバー名を確認します。UUID、パス、ポート、TLSを一度に変更すると、接続が復旧しても本当の原因を特定できません。
エラー: TLS handshake timeout
原因と対処:TCP接続は確立していても、TLSハンドシェイクが制限時間内に完了していない可能性があります。サーバー名、TLSの有効化、ポート、システム時刻を確認し、ネットワークを切り替えて経路上の問題を切り分けます。
エラー: dial tcp: i/o timeout
原因と対処:TCP接続の確立時に、クライアントが時間内に応答を受け取れていません。サーバーアドレス、ポート、ローカルネットワーク、ファイアウォールを確認します。そのアドレスだけ失敗する場合は、リモート側のポートが停止していないか確認します。
エラー: connection refused
原因と対処:対象ホストが接続を明確に拒否しています。通常はアドレスに到達できるものの、そのポートでサービスが待ち受けていないか、入口のルールが意図的に拒否しています。ポートを確認したうえで、サービス管理者に待受状態を確認してもらいます。
結論：タイムアウトと接続拒否は分けて対処する
i/o timeoutはリクエストに適時応答がなかったことを示し、connection refusedは対象が明確に接続を拒否したことを示します。前者はネットワーク経路とアドレスを先に確認し、後者はポートとサーバーの待受状態を優先して確認します。
5つ目：相互テストでサーバー状態を判断する
最初の4段階を終え、基礎ネットワークが正常、時刻も正確、サブスクリプションも更新済みで設定が一致しているなら、リモートサーバーがメンテナンス中か、ポートの待受が停止しているか、特定のネットワークからだけ到達できないかを確認します。ここでクライアント設定を無作為に変更し続けるのではなく、比較可能なテスト結果を作ることが重要です。
有効な比較には、同じ端末でノードを変更、同じノードでネットワークを変更、同じサブスクリプションを別の端末で使用、という3つの観点があります。一度に1つの条件だけを変えてください。たとえば、同じWindows端末でノードAが10秒以上のタイムアウトを3回続け、同じグループのノードBとCは2秒以内にウェブページを開けるなら、ノードAに問題がある可能性が高くなります。A、B、Cが現在のネットワークですべて失敗し、ネットワークを変えるとすべて復旧するなら、元のネットワーク経路が原因である可能性が高いでしょう。
- 1つのノードだけ失敗：ログに記録された時刻、サーバーアドレス、エラーの種類を控え、サーバー側の復旧を待つか、同じサブスクリプション内の別ノードを使用します。
- 同じ地域のノードが集中して失敗：そのグループの入口または経路に問題がある可能性があります。まず別のアドレスへ切り替えてテストし、クライアントを何度も再インストールしないでください。
- 1つのネットワークでだけ全ノードが失敗：ルーター、DNS、ネットワークのアクセス制限、ファイアウォールポリシーを確認し、別のネットワークで再テストします。
- すべての端末で同じサブスクリプションが使えない：サブスクリプションの有効期限、通信量の状態、サービスからの告知を確認し、各端末のローカルポートを変更し続けないでください。
- 1台の端末だけ失敗：ローカル待受、システムプロキシ、時刻、コア設定に戻り、正常な端末との違いを重点的に比較します。
ログを見るときは、後から繰り返される連鎖エラーではなく、最初に発生した失敗に注目します。v2rayNの実行情報には通常、対象アドレス、接続段階、コアからの返答が記録されます。v2rayNGとv2flyNGでもログ欄から最近の接続結果を確認できます。現在のログ位置を控えるかログを消去してからアクセスを実行すると、古い記録の影響を減らせます。
エラー: context deadline exceeded
原因と対処:コアまたはクライアントに設定された待機時間を超えた操作があります。この1行だけでは根本原因を特定できません。同じリクエストでそれより前に出たDNS、TCP、TLSのエラーを上へたどり、該当する段階に応じて対処します。
エラー: context canceled
原因と対処:接続タスクが上位処理によってキャンセルされています。ノードの切り替え、コアの再起動、先行する接続失敗後の後処理などでよく発生します。より具体的なエラーの直後に表示されている場合は、前のエラーを主な手がかりにしてください。
エラー: network is unreachable
原因と対処:システムに対象ネットワークまでの利用可能な経路がありません。端末がネットワークに接続されているか、ルーターが正常か、ネットワークインターフェースが切り替わっていないかを確認します。残存するプロキシや仮想ネットワーク設定が経路に影響していないことも確認してください。
手順全体は、まず端末が正常にネットワークへ接続できることを確認し、次にシステム時刻を信頼できる状態にする、続いてサブスクリプションが実際に更新されたことを確認してノードのプロトコル設定を点検する、最後に複数ノード・複数ネットワーク・複数端末で比較してサーバー側の状態を判断する、という流れです。操作を増やすことが目的ではありません。ローカルネットワークの障害時にサブスクリプションを作り直したり、リモート側のメンテナンス時に正しいクライアント設定を何度も変更したりするのを防ぐためです。