V2Rayの接続がタイムアウトする原因と対処法｜ローカルプロキシからサーバーまでの5段階チェック

この記事の要点

切り分けの目的は、「接続できない」原因がローカルの待ち受け、通信の入口、ノード設定、時刻とハンドシェイク、リモートネットワークのどこにあるかを特定することです。この記事ではWindows版v2rayNを中心に、Android版v2rayNGとv2flyNGで確認すべき違いも紹介します。一度に変更する条件は一つに絞り、同じリクエストで再テストしてください。ノードやルーティング、DNSをまとめて変更すると、何が効いたのか判断できなくなります。

手順1：ローカルプロキシのポートが待ち受け中か確認する

ローカルの入口：クライアント画面が開いていても、プロキシのコアが起動しているとは限りません。v2rayNは設定と管理を担い、実際の接続は選択中のコアが処理します。コアの設定読み込みに失敗したり、ポートが使用中だったりすると、ブラウザーにプロキシを設定してもリクエストはノードに届きません。まずクライアントのログで起動結果を確認し、次に待ち受けポートを調べます。

ポートの確認：v2rayNの「設定」→「パラメータ設定」を開き、ローカルの待ち受けアドレスとポート、対応するインバウンドの種類を確認します。画面の項目名やグループ分けはバージョンによって異なる場合があります。以下ではSOCKSインバウンドの127.0.0.1:10808を例にします。10808はすべての環境で共通の値ではなく、サーバー側のポートでもありません。実行前に実際の待ち受けポートに置き換えてください。

netstat -ano | findstr ":10808"

出力がない：実際のポートが異なっていないか、コアが終了していないか、設定の解析や起動に失敗したログがないか確認します。待ち受けていない状態をブラウザーの設定変更で解決しようとしないでください。
LISTENINGがある：行末のPIDを確認し、「タスクマネージャー」→「詳細」でプロセスを特定します。別のプログラムがポートを使用している場合もあるため、ポート番号が一致するだけで正常と判断しないでください。
待ち受けアドレスが異なる：127.0.0.1はIPv4のループバックアドレスです。[::1]だけで待ち受けている場合、IPv4のループバック接続も使えるとは限りません。テストには待ち受けアドレスと同じものを指定してください。

エラー：bind: address already in use

原因：使用しようとしたローカルアドレスとポートがすでに使用されています。複数のインスタンスを起動した場合や、別のプロキシプロセスが動作中の場合によく発生します。

対処法：PIDからポートの使用元を特定し、重複したインスタンスを終了するか、ローカルの待ち受けポートを変更します。コアを再起動した後、アプリのプロキシ設定も同じ値に更新してください。

Androidでの違い：v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。まずアプリで接続を開始し、システムVPNの使用が許可されていることを確認してください。AndroidのVPNによる通信の取り込みは、Windowsのシステムプロキシとは仕組みが異なります。Windowsでのポート確認の結果をそのまま当てはめないでください。

手順2：システムプロキシ、アプリのプロキシ、TUNを切り分ける

通信経路：システムプロキシが影響するのは、その設定に従うアプリだけです。一方、TUNは仮想ネットワークアダプターを通じて通信を取り込みます。ブラウザーでは開けるのにほかのプログラムで失敗しても、ノードの問題とは限りません。逆に、クライアントの遅延テストに成功しても、ブラウザーがプロキシを使っているとは限りません。

アプリのリクエストローカルの入口ルーティング判定ノードへの接続接続先サービス

切り分けテスト：現在のシステムプロキシとTUNの状態を記録し、TUNを一時的にオフにして、SOCKSプロキシを明示したコマンドでリクエストを送ります。アプリがシステムプロキシに従うかどうかという不確定要素を避けられますが、クライアント内部のルーティングルールの影響は残ります。プロキシ経由の接続を確認する場合は、実際に選択されたアウトバウンドもログで確認してください。

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raymark.com/

パラメータの意味：socks5hでは接続先のドメイン名をプロキシ側で解決します。この指定だけでローカルのDNSが正常だとは判断できません。10秒は接続処理の上限、20秒はリクエスト全体の上限です。いずれも今回の診断用の設定であり、ネットワーク性能の基準ではありません。403や405が返ってきた場合もHTTP応答を受信できています。接続タイムアウトとして扱い続けないでください。

入口の状態を記録

v2rayNの待ち受けポート、選択中のノード、システムプロキシの状態、TUNの状態を記録し、失敗時の条件を残しておきます。
プロキシを明示してテスト

TUNをオフにして上記のコマンドを実行します。ローカルへの接続が拒否された場合は、手順1に戻ってポートとSOCKSインバウンドの種類を確認してください。
システムプロキシを元に戻す

プロキシを明示したテストに成功したら、v2rayNの「システムプロキシ」で「システムプロキシを自動設定」を選択します。次にWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、クライアントの状態と一致しているか確認してください。
TUNを個別に確認

TUNが必要な場合にのみ有効にし、クライアントの案内に従って権限とネットワークアダプターの状態を確認します。TUNだけが失敗する場合は、ノードのパラメータをすぐ変更せず、ルーティング、DNS、ほかのVPNとの競合を調べてください。

判断の目安：明示したプロキシで成功したら、アプリの入口を確認

プロキシを明示したリクエストが成功してもブラウザーで失敗する場合は、まずブラウザーの拡張機能、アプリ固有のプロキシ設定、システムプロキシのアドレスを確認します。この場合、サーバーを変更してもローカルの入口が機能していない問題は解決しません。

手順3：サブスクリプション設定と使用中のノードを確認する

設定の取得元：サブスクリプションの更新に成功したからといって、すべてのノードが有効とは限りません。更新に失敗しても、現在のノードがすぐに使えなくなるわけではありません。まず選択中のノードがどのサブスクリプショングループに属しているか、更新前の古い項目を使っていないかを確認します。次に、サービス提供元がアドレス、ポート、認証情報を変更していないか確認してください。

コアの違い：v2rayNでは、実際に呼び出されているコアとそのログを確認します。Androidでは、v2rayNGとv2flyNGを名前だけが異なる同一アプリとして扱わないでください。Xrayとv2flyでは、プロトコルの拡張機能や設定項目の対応状況が完全には一致しません。画面から設定をインポートできても、コアですべて正常に動作するとは限りません。特にVLESSやREALITYを使う設定では、実際の対応状況を確認してください。

確認項目	確認する内容	よくある誤り
サーバーアドレスとポート	ノードのアドレスとサーバー側の待ち受けポートを確認します。443は一般的な設定例にすぎません。	ローカルの10808を接続先ポートに設定してしまう
プロトコルと認証	VMess、VLESSの種類と、ユーザー識別子などの対応する項目	ノード名だけを見て、認証情報が更新されたことを見落とす
通信方式のパラメータ	TCP、WebSocket、gRPCなど、実際の通信方式と必要な項目を確認します。	通信方式の不一致を見落とし、DNSだけを変更する
TLSの設定	TLSの有効・無効、サーバー名、証明書の要件を確認します。	TCPポートに接続できればハンドシェイクも正常だと思い込む
ルーティングとアウトバウンド	テストリクエストが直結やブロックではなく、想定したプロキシを選択しているか確認します。	接続先サイトへの直結失敗をノードのタイムアウトと誤認する

更新手順：v2rayNの「サブスクリプショングループ」で対象のグループを更新し、更新後にノードを選び直してログを確認します。使用中のバージョンにプロキシ経由・プロキシを使わない更新の両方がある場合は、サブスクリプションURLへの実際の接続性に応じて選択してください。利用可能なノードが一つしかなく、それが無効になっていると、そのノード経由でサブスクリプションを取得しようとして失敗を繰り返すことがあります。サブスクリプションURLとノード設定一式は機密情報です。調査用のスクリーンショットでは認証情報を隠してください。

手順4：システム時刻を同期し、TLSハンドシェイクの失敗を見分ける

時刻の影響：システム時刻が大きくずれていると、証明書がまだ有効でない、または期限切れと判定されたり、VMessの時刻に関連する認証に影響したりすることがあります。VLESSにVMessの時刻検証の仕組みをそのまま当てはめることはできませんが、TLSを有効にしている場合は証明書の有効期間が検証されます。タイムゾーンの表示を変更しても、システム時刻自体が修正されるとは限りません。

Windows：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にして「今すぐ同期」をクリックし、同期結果を確認します。
Android：システム設定で「日付と時刻」を検索し、自動設定を有効にします。設定画面の場所は端末のシステムによって異なります。
同期後：テストリクエストをもう一度実行し、同じ時刻のコアログを確認します。証明書エラーが続く場合は、証明書の有効期間とサーバー名を確認してください。

エラー：x509: certificate has expired or is not yet valid

原因：証明書の有効期間と現在のシステム時刻が一致していません。端末の時刻が誤っている場合もあれば、サーバー証明書の更新が必要な場合もあります。

対処法：まず端末の時刻を同期します。時刻が正しいのにエラーが続く場合は、サーバー管理者に証明書とその配置状況を確認してもらってください。

エラー：x509: certificate signed by unknown authority

原因：証明書チェーンを信頼されたルート証明書までたどれません。中間証明書の不足、プライベート証明書、端末の信頼ストアなどが原因として考えられます。

対処法：サーバーの証明書チェーンと想定される認証局を確認します。プライベート証明書を使う場合は、信頼できる経路で信頼設定を行い、検証を無効にして済ませないでください。

SNIの確認：接続先アドレスとTLSのサーバー名が異なる構成はあり得ますが、サーバーの設定と証明書の要件に合っている必要があります。接続できるドメイン名を適当に入力しないでください。allowInsecureをタイムアウト解消の設定として使わないでください。証明書の検証を省略してもTCP接続の問題や誤った通信経路は解決せず、認証の安全性が低下します。

手順5：サーバーへの接続性とリモート側の待ち受けを確認する

リモート側の接続確認：手順1〜4でローカルの入口、通信の取り込み、設定を確認した後、ノードのアドレスと対象ポートをテストします。以下はWindows PowerShell用のコマンドです。実際のノードアドレスとポートを入力してください。サブスクリプションURL全体は入力しないでください。このテストで確認できるのはTCP接続だけで、アカウント、TLS、WebSocketのパス、gRPCのサービス名は検証できません。

$nodeHost = Read-Host "ノードサーバーのアドレスを入力"
$nodePort = [int](Read-Host "ノードサーバーのポートを入力")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailed

TcpTestSucceeded が True：テストで使用したアドレスとポートへのTCP接続が確立できています。次はTLS、認証、通信方式のパラメータ、サーバーログを確認してください。これだけでノード全体が正常だとは判断できません。
TcpTestSucceeded が False：名前解決、サービスの待ち受け、ファイアウォール、セキュリティグループ、経路上のパケットロスなどが考えられます。解決されたリモートアドレスとエラー内容を合わせて判断してください。これだけでサービス停止を証明できるわけではありません。
Pingは失敗するがTCP接続は成功：接続先がICMPに応答しない可能性があります。Pingの失敗をプロキシポートのテストの代わりに使わず、Pingが成功してもプロキシサービスが正常とは判断しないでください。
UDPを使う場合：TCPのテストではUDPの利用可否は確認できません。また、ウェブのリクエストに成功しても、UDPに依存するすべてのアプリが正常に動作するとは限りません。

エラー：i/o timeout

原因：ネットワークの読み書きが制限時間内に完了しませんでした。前後のログと照らし合わせ、ノードへの接続、TLSハンドシェイク、接続先サービスへのアクセスのどの段階で発生したかを確認する必要があります。

対処法：同じリクエストの前後のログを残し、リモートアドレスと発生段階を確認します。そのうえでポート、ハンドシェイク、接続先サービスを個別に調べてください。この1行だけを根拠にDNSを変更しないでください。

ネットワークを比較する：ノード、接続先アドレス、テストコマンドは変えず、端末のネットワークだけをスマートフォンのテザリングに切り替えて再テストします。結果が異なる場合は、元のネットワークの外向き通信制限、DNSの応答、アドレスファミリーの違いを優先して確認してください。ただし、これだけで特定の制限が原因だと断定はできません。ドメインがIPv4とIPv6の両方のアドレスを持つ場合は、実際に使われたアドレスを記録し、ドメイン名の表記だけを比較しないでください。

サーバー側の確認：管理権限がある場合は、プロセスが動作中か、想定したポートで待ち受けているか、ファイアウォールとセキュリティグループで通信が許可されているか、証明書とリバースプロキシの設定が一致しているかを確認します。権限がない場合は、失敗した時刻とタイムゾーン、プロトコルと通信方式、機密情報を隠したログ、ポートのテスト結果を管理者に伝えてください。ユーザー識別子、サブスクリプションURL、その他の認証情報を公開しないでください。

判断の目安：ポートに接続できたら、ハンドシェイクと設定を確認

TCPのテストに成功してもプロキシ経由のリクエストが失敗し続ける場合、次の調査対象はTLS、プロトコル認証、通信方式のパラメータ、実際のアウトバウンドログに絞ります。待ち時間を何度も延ばしても、同じエラーが遅れて発生するだけです。

再テストの仕上げ：同じリクエストで修正範囲を確認

再テストの基準：一つの設定を変更したら、手順2で使ったプロキシを明示するリクエストをもう一度実行し、実際に使うブラウザーやアプリでも確認します。プロキシを明示したテストで確認できるのは、そのリクエストの経路だけです。システムプロキシ、TUN、DNS、ほかのアプリの動作は個別に検証する必要があります。クライアントに表示される遅延テストも、対象や方法が別に定められているため、すべてのアプリが使えることを示すものではありません。

変更を記録：変更した項目、テスト時刻、選択中のノード、対応するログを残し、次回のトラブル対応を最初からやり直さずに済むようにします。
設定を元に戻す：必要に応じてTUNとシステムプロキシを元の状態に戻し、一時的な変更を取り消します。証明書検証を無効にするなどの回避設定は残さないでください。
範囲を絞る：特定のウェブサイトだけ失敗する場合は、その宛先に対するルーティングと応答ステータスを確認します。特定のアプリだけ失敗する場合は、アプリ固有のプロキシ設定と通信の種類を確認してください。
結果を残す：修正前後のテストは、同じ接続先、同じ入口、同じタイムアウト設定で実施します。一度成功しただけで、長期的に安定したと判断しないでください。

設定を続ける：システムプロキシ、TUN、ルーティングルールの関係を確認するには応用設定をご覧ください。初期設定がまだの場合は、まずチュートリアルに沿って、再現可能な接続を一つ確立してから、ルーティングやDNSの設定を追加してください。