v2rayN デスクトップ版、v2rayNG・v2flyNG Android版で接続がタイムアウトする場合の確認手順を解説します。まず失敗したテストの種類を確認し、時刻、ローカルの待ち受け、アプリからの接続経路を調べます。次にサーバーアドレス、TLS、通信設定を確認し、最後にサーバーの待ち受けとファイアウォールを検証します。各手順でログと再テストの結果を記録し、複数の設定を同時に変更して原因が分からなくなるのを防ぎましょう。
1. テストのタイムアウトと実際の接続失敗を切り分ける
ノード一覧に「タイムアウト」と表示されても、ノードのすべての機能が使えないとは限りません。TCP接続テストで確認できるのはTCP接続の確立までです。プロキシ経由でテスト用サイトにアクセスする場合は、プロトコル認証、TLS、名前解決、接続先サイトの応答も関係します。まず、どのテストを実行したか記録し、異なるテスト結果を同じ指標として扱わないようにしましょう。
- 一覧のテストだけ失敗する：対象ノードを選び、ブラウザーで確実に利用できるサイトにアクセスしながら、クライアントのログを確認します。実際のアクセスに成功する場合は、テスト用URLとテストリクエストのルーティングを優先して確認してください。
- テストは成功するがブラウザーから接続できない：ブラウザーのリクエストがローカルプロキシを経由しているか、ブラウザー拡張機能に個別のプロキシ設定がないかを確認します。
- すべてのノードで同時に失敗する：ノードごとの設定を変更する前に、コアが起動しているか、時刻が正しいか、現在のネットワークでWeb認証が必要かを確認します。
- 特定のノードだけ失敗する：正常なノードを比較対象として残し、失敗するノードのアドレス、ポート、通信設定、サーバーの状態を重点的に確認します。
作業を始める前に、クライアントのバージョン、使用中のコア、OS、テスト時刻、失敗時のログを記録します。v2rayN の画面はバージョンによって異なります。以下のデスクトップ版のメニュー名は従来の Windows 画面を基準にしています。画面が異なる場合は、同じ設定項目を探してください。場所をそのまま当てはめる必要はありません。
2. まず端末の時刻とネットワークを確認する
端末の時刻が大きくずれていると、TLS証明書の有効期間の判定に影響し、VMessの時刻に関係する認証に失敗することもあります。VLESSにVMessと同じ時刻判定をそのまま当てはめることはできませんが、外側の通信にTLSを使う場合は正確な時刻が必要です。表示上のタイムゾーンを変更するだけでは、実際の時刻のずれは直りません。
-
システム時刻を同期する
Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にして「今すぐ同期」を実行します。Androidではシステム設定から「日付と時刻」を検索し、自動設定をオンにします。設定項目の名前や場所はシステムによって異なる場合があります。
-
ネットワーク接続を確認する
プロキシ接続を一時的に切断し、現在のネットワークでWeb認証が必要か確認します。公衆ネットワークの認証ページが表示される場合は、先に認証を済ませてからクライアントを起動してください。ネットワーク自体がつながっていない状態で、ノードを何度も更新する必要はありません。
-
ネットワークを切り替えて一度だけ再テストする
ノードと設定はそのままにして、ネットワークだけ一度切り替えて再テストします。同じノードが別のネットワークで使える場合は、元のネットワークのDNS、外向き通信のポリシー、アクセス制限を優先して調べます。それだけでサーバー側の障害と断定することはできません。
Windowsでは、ターミナルから時刻同期の状態を確認することもできます。以下のコマンドは状態を表示するだけで、ノード設定は変更しません。時刻サービスが実行されていないと表示された場合は、システムの時刻設定に戻り、サービスと同期状態を確認してください。
w32tm /query /status3. ローカルの待ち受けとアプリからの接続経路を確認する
サーバーに接続が届く前に、ローカルのコアが起動に失敗している可能性があります。v2rayN の従来の画面では、「設定」→「パラメータ設定」からローカルの待ち受け設定を確認し、メイン画面でシステムプロキシの状態を確認します。実際の画面と起動ログを基準にしてください。バージョンによっては混合待ち受けを使うため、SOCKSとHTTPのポートが個別に設定されているとは限りません。
上記のポートはコマンド例に使う値であり、どのクライアントバージョンでも既定値だと示すものではありません。実行前に、自分の設定でプロトコルとポートを確認してください。ローカルのSOCKS待ち受けが 127.0.0.1:10808 の場合、Windowsではまず待ち受けを確認し、次にプロキシを明示してリクエストを送信できます。
Get-NetTCPConnection -LocalPort 10808 -State Listen
curl.exe -I --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 https://example.com/1つ目のコマンドはPowerShellで実行します。待ち受けが見つからない場合は、リモート証明書ではなく、コアの起動ログとローカルポートを先に確認してください。2つ目の example.com は接続先の例です。実際の確認では、利用できることを確認済みのHTTPSサイトに置き換えられます。socks5h は接続先のドメイン名をプロキシ側で解決する指定です。10秒と20秒はこのコマンドで明示したタイムアウトの上限であり、速度測定の結果ではありません。
判断の目安：プロキシを明示した接続に成功したら、アプリ側の接続経路を確認する
コマンドでHTTPレスポンスを受け取れるのに、ブラウザーで同じ接続先にアクセスできない場合は、システムプロキシ、ブラウザー独自のプロキシ設定、ルーティングルールを優先して確認します。HTTP 403などのステータスも、応答を受け取ったことを示します。接続タイムアウトと混同しないでください。
- v2rayN：システムプロキシの設定が適用されるのは、その設定に従うアプリだけです。プロキシを明示したコマンドはシステムプロキシの接続経路を通りませんが、コア内のルーティングルールは引き続き適用されます。
- v2rayNG、v2flyNG：AndroidのVPN接続権限が許可されていることと、別のVPN接続に置き換えられていないことを確認します。アプリごとのプロキシを有効にしている場合は、接続先のアプリが対象に含まれているか確認してください。
- 画面ロック後だけ失敗する：Androidのバックグラウンド実行とバッテリー制限を確認し、画面ロックの前後で接続ログが記録されているか確認します。バックグラウンドのプロセスが停止する問題に対して、サーバーのポートを先に変更する必要はありません。
4. サーバーアドレス、DNS、ポートを確認する
ここで確認するのは「ノードサーバーのドメイン名を解決できるか」であり、ブラウザーが最終的にアクセスするサイトの名前解決ではありません。両者では名前解決の経路が異なる場合があります。サーバーアドレスの入力ミス、期限切れのDNSレコード、現在のネットワークから到達できないIPv6アドレスだけが返されることなどが、ノードのタイムアウトにつながります。
| 確認項目 | 確認方法 | 結果から分かること |
|---|---|---|
| サーバーアドレス | ノードの提供元情報と照らし合わせて、ドメイン名の入力ミス、空白、ポートを確認する | 通常、アドレス欄にWebページの完全なURLや通信パスを入力する必要はありません |
| ドメイン名の名前解決 | Resolve-DnsNameでノードのドメイン名を調べ、AレコードとAAAAレコードを比較する | システムで名前解決できても、コアが使う経路で成功するとは限りません |
| リモートTCP接続 | Test-NetConnectionで実際のノードアドレスとポートをテストする | TCP接続の確認に限られ、プロトコルのハンドシェイクやUDPの利用可否は分かりません |
| ネットワークの比較 | 同じ端末・同じ設定のままネットワークを切り替えて再テストする | ネットワークだけを変え、DNSや通信設定を同時に変更しない |
PowerShellでは入力を促す方法を使うと、例示用ドメイン名を実際のノードと取り違えずに済みます。ここでの 443 は、リモート側が実際にそのポートで待ち受けているノードに限って使えます。ポートが異なる場合は、コマンド内の数値を変更してください。
$server = Read-Host "ノードサーバーのドメイン名を入力"
Resolve-DnsName $server
Test-NetConnection -ComputerName $server -Port 443TcpTestSucceeded : True で分かるのは、そのアドレスのTCPポートに接続できたことだけです。ノードがCDNを使っている場合、CDNエッジまでの接続が成功しただけで、オリジンサーバーの確認にはなっていない可能性があります。Pingに失敗しても、ネットワーク機器がICMPに応答しない場合があるため、それだけでノードが停止しているとは判断できません。
5. TCP接続に成功したらTLSと通信設定を確認する
TCP接続に成功してもプロキシ経由のリクエストが失敗する場合は、プロトコル認証とハンドシェイクの設定を確認します。信頼できる元のノード情報を参照し、すべてのノードを経験則で同じ通信方式に変更しないでください。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。設定が動作するかどうかは、プロトコル、機能、コアのバージョンによって異なります。インポートできたことだけで互換性を判断することはできません。
- プロトコルと認証情報：VMessまたはVLESSの種類が正しいこと、ユーザーID、暗号化、フロー制御の設定がサーバー側と一致していることを確認します。サブスクリプションの更新後にサーバー側の設定が変更されていると、古いノード情報がローカルの一覧に残っている場合があります。
- TLS：TLSの有効・無効、サーバー名のSNI、証明書の対象ドメイン、サーバーが要求するALPNを確認します。接続先アドレスをIPアドレスに変更しても、正しいTLSサーバー名を指定する必要があります。証明書検証のスキップは、通常の解決策として使わないでください。
- WebSocket：パスとHostを確認します。パスの先頭にある
/や大文字・小文字も照合に影響する場合があります。リバースプロキシにも、該当するパスとプロトコルのアップグレード転送を設定してください。 - gRPC：serviceNameがサーバー側と一致していることと、リバースプロキシが該当するHTTP/2転送に対応していることを確認します。WebSocket用の転送設定をそのまま流用しないでください。
- REALITY：サーバーから提供された公開鍵、shortId、サーバー名などの項目を確認し、クライアントとコアが使用する設定に対応していることを確かめます。通常のTLSノードとして扱わないでください。
エラー：connection refused
原因：接続先から明示的に拒否されています。ポートで待ち受けていない場合や、ファイアウォールが接続を拒否している場合によく起こります。対処：まずログに記録されたアドレスがローカルかリモートか確認し、それぞれローカルのコアまたはリモートの待ち受けを調べます。ノードの期限切れとすぐに判断しないでください。
エラー：i/o timeout
原因：ネットワークの読み書きが制限時間内に完了しませんでした。接続開始、ハンドシェイク、応答の読み取りなど、さまざまな段階で発生する可能性があります。対処：前後のログからタイムアウトした対象を確認し、ポートテストとネットワーク比較を行います。この1行だけでは、どちら側に原因があるか特定できません。
エラー：x509: certificate has expired or is not yet valid
原因：現在の時刻が証明書の有効期間外です。端末の時刻が誤っている場合と、サーバー証明書の有効期限が切れている場合があります。対処：まずシステム時刻を同期します。それでも解決しない場合は、サーバーの管理者に証明書の有効期間と適用状況を確認してもらってください。
エラー：websocket: bad handshake
原因：WebSocketへのアップグレードで期待した応答が得られていません。パス、Host、リバースプロキシの設定が一致していない場合によく起こります。対処：ノードの各項目と照らし合わせて接続口を確認し、サーバー側で該当するリクエストが正しい転送先に届いているか確認してください。
これらはログに出る可能性のあるエラー例です。表示される文言はコアやバージョンによって異なります。一時的にログの詳細度を上げて失敗を一度だけ再現し、該当する時間帯のログを保存してください。確認後は元のログレベルに戻し、記録が長期間にわたって増え続けないようにします。
6. 最後にサーバーの待ち受けと転送経路を確認する
サーバーの管理権限がない場合は、クライアントのバージョン、失敗時刻、エラーの一部、異なるネットワークでのテスト結果を管理者に伝えれば十分です。調査のために管理パスワードを尋ねたり、送信したりしないでください。Linuxサーバーの管理権限がある場合は、待ち受け、プロセスのログ、ホストのファイアウォール、クラウド側の受信ルールの順に確認します。
sudo ss -lntp
sudo ss -lnup1つ目のコマンドはTCPの待ち受け、2つ目はUDPの待ち受けを確認します。すべてのノードにTCPとUDPの両方の待ち受けを求めるのではなく、設定で実際に使うプロトコルとポートを確認してください。手前にリバースプロキシがある場合、外部ポートはリバースプロキシのプロセスが受け付け、コアは内部のローカルポートだけで待ち受ける構成もあります。それ自体は異常ではありません。
- 待ち受けアドレスを確認：待ち受け先がループバックアドレスか外部向けアドレスか、ポートがクライアント側と一致しているかを確認します。コンテナ環境ではポートマッピングとプロトコルの種類も確認してください。
- 該当するログを確認：実際のサービス名を使ってサービスの状態と最近のログを調べ、設定の読み込みに失敗したまま古いプロセスが動いていないか確認します。クライアントで再テストし、同じ時間帯に接続やハンドシェイクの記録があるか確認してください。
- 2段階の許可設定を確認：ホストのファイアウォールとクラウドのセキュリティグループをそれぞれ確認し、実際に必要なプロトコルとポートだけを許可します。調査のためにファイアウォール全体を無効にしないでください。
- 転送経路の後半を確認：接続口でリクエストを受け取っているのに502、504、またはハンドシェイクエラーが返る場合は、リバースプロキシからコアへの接続、パスの照合、証明書、転送先への到達性を確認します。
判断の目安：接続口にリクエストが届いているなら、転送経路の後半を調べる
同じ時間帯に接続口のログでリクエストを確認できた場合は、ローカルの待ち受けポートを手当たり次第に変更するのではなく、認証、リバースプロキシ、外向き通信を追跡します。接続口にログがないことだけで、通信が届いていないとは断定できません。ログレベルと記録場所も確認してください。
7. 条件をそろえて再テストし、結果を記録する
設定を1つ変更するたびに、同じノード、同じ接続先、同じテスト方法で再テストします。タイムアウトを長くしても待ち時間の上限が変わるだけで、ポートやTLS設定の誤りは直りません。小さなリクエストは成功するのにダウンロードや特定のサイトだけ失敗する場合は、接続先サイト、ルーティング、DNS、パスMTUまで原因を絞り込みます。すぐにクライアントを再インストールする必要はありません。
- 記録する情報：実際のテスト日時とタイムゾーン、クライアントとコアのバージョン、接続中のネットワーク、失敗した段階、直近の変更を記録します。
- 最低限の証拠：起動結果、ローカルの待ち受け結果、リモートポートのテスト結果、実際のリクエストに関連するログを1回分保存します。
- 共有前に機密情報を削除：サブスクリプションURL、ユーザーID、アクセストークン、ノード共有情報を削除します。サーバーアドレスは、原因特定に必要な場合に限り、信頼できる相手とのやり取りで共有してください。
- 効果のない変更を止める：証拠からリモートの待ち受けやサーバー設定に原因があると分かったら、再現可能な現在の状態を保って管理者に引き継ぎます。ローカル側の変更をさらに重ねないようにしてください。
調査完了の目安は、一覧の遅延時間が戻ることではなく、同じ経路でリクエストが安定して応答を得られることです。再びタイムアウトした場合も、今回の記録と変化を照らし合わせれば、すべての設定を試し直すより原因を見つけやすくなります。