V2Rayの接続がタイムアウトしてつながらない？ローカルからサーバーまでの切り分け手順

1. タイムアウトが発生している箇所を確認する

「ノードのタイムアウト」は、テストが制限時間内に完了しなかったことを示すだけで、サーバーが停止したとは限りません。ローカルの待ち受けポート、ノードアドレスの名前解決、通信のハンドシェイク、プロキシ経由でテスト先にアクセスする段階など、さまざまな箇所で止まる可能性があります。v2rayNはデスクトップ向けの設定管理クライアントで、実際の接続は選択したコアが確立します。画面が開いていても、コアが正常に起動したとは限りません。

発生時刻、クライアントのバージョン、コアの名称とバージョン、使用中のノード名、プロキシモード、テスト先URLを記録します。バージョンは「ヘルプ」のバージョン情報、またはメイン画面の表示を確認してください。コアのバージョンは起動ログで確認し、クライアントのバージョンと混同しないようにします。次の3つのケースは分けて対処しましょう。

• すべてのノードで失敗する：まず端末のネットワーク、待ち受けポート、システムプロキシ、TUN、セキュリティソフトによるブロックを確認します。同じサブスクリプションで共通のサービス障害が起きている可能性もあります。
• 特定のノードだけ失敗する：ノードのアドレス、ポート、通信設定を比較し、サーバー側で該当する接続口が停止されていないか確認します。
• テストは失敗するがWebサイトは表示できる：テスト先URLとテスト通信の経路を確認します。遅延の数値ひとつだけを理由にノードを削除しないでください。

2. ローカルの直接接続を確認し、テスト条件をひとつに絞る

Windowsでは、まずv2rayNのメイン画面で「TUNを有効にする」をオフにし、「システムプロキシ」から「システムプロキシを解除」を選びます。設定項目の場所はバージョンによって異なる場合がありますが、ウィンドウを閉じるだけでなく、通信の経路を引き継ぐ機能が停止していることを確認してください。その後、普段プロキシなしで開けるサイトにアクセスし、Wi-Fiでログイン認証が必要かどうかも確認します。

1. ローカルネットワークを確認する

   Windowsの「設定」→「ネットワークとインターネット」でネットワークに接続されていることを確認します。プロキシなしでもサイトを開けない場合は、ゲートウェイ、認証ページ、ネットワーク障害を先に解決し、ノード設定は変更しないでください。

2. システム時刻を確認する

   「設定」→「時刻と言語」→「日付と時刻」を開き、自動時刻設定を有効にして「今すぐ同期」をクリックします。時刻のずれは証明書の検証や、時刻チェックを行うプロトコルに影響することがあります。

3. 待ち受けポートを確認する

   v2rayNの「設定」→「パラメータ設定」でローカルの待ち受け設定を確認し、コアの起動ログと照らし合わせて実際のポート番号とプロトコルを特定します。ノードの接続先ポートをブラウザーのプロキシ設定に入力しないでください。

4. テスト条件を固定する

   ノードをひとつ選んで使用し、TUNはオフのまま、システムプロキシだけを有効にするか、コマンドでローカルプロキシを明示します。URLをひとつに固定してリクエストを実行し、その時刻のログを確認してください。

以下の数値は切り分け用の例であり、すべてのバージョンの初期値を示すものではありません。ローカルのHTTPまたは混合接続口が127.0.0.1:10808で待ち受けており、接続先URLがHTTPSだと確認できている場合を想定しています。実際に実行する際は、現在の設定とポート番号を一致させてください。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 --head https://example.com/

これはWindowsのコマンド例です。macOSとLinuxでは通常curlを使います。接続口がSOCKSのみをサポートする場合は、プロキシアドレスをsocks5h://127.0.0.1:10808に変更してください。ポート番号も必ず確認します。HTTPレスポンスを受信できれば、リクエストが何らかのHTTPサービスに到達したことは分かりますが、ステータスコードとログも確認する必要があります。タイムアウトする場合は、接続経路に沿って調査を続けてください。

3. システムプロキシとTUNを個別に検証する

システムプロキシの影響を受けるのは、システムのプロキシ設定に従うアプリが中心で、すべてのプロセスが自動的に経由するわけではありません。TUNは仮想ネットワークインターフェースを使い、設定条件に該当する通信を引き継ぎます。そのため、ルーティングテーブル、権限、DNSの引き継ぎも関係します。切り分け中に両方を同時に有効にすると、ループや二重の通信引き継ぎが起こりやすくなり、どの層で問題が発生しているか判断しにくくなります。

v2rayNGはAndroid VpnServiceとXrayコアを使用し、v2flyNGはv2flyコアを使用します。どちらも設定が実際に使用するコアに対応しているか確認してください。AndroidのVPN接続は、別のVPNサービスによって置き換えられることがあります。通知欄にアプリが表示されているかだけでは判断できません。バックグラウンドの問題は、画面をロックする前と後でそれぞれテストし、すぐにノードのプロトコルを変更しないでください。

4. リクエストが想定した経路に送られているか確認する

ルーティングでは通常、ルールの順番に沿って条件が判定されますが、条件やデフォルトの出口はコアの設定によって異なります。ノードを選択しても、すべてのリクエストがそのノードを使うとは限りません。ドメイン、IP、プロセスに関するルールや、直接接続・ブロックの出口によって、実際の経路が変わることがあります。実際の接続時間を測るテストリクエストの経路も、バージョンとログを照らし合わせて確認してください。

• 一時的にシンプルなルーティングを使う：v2rayNの「ルーティング」から、グローバルプロキシ用のプリセットを選択します。プリセット名は設定によって異なることがあります。テスト先URLが直接接続やブロックのルールに先に一致していないか確認してください。
• 実際のルーティング結果を確認する：ログから接続先ドメイン、ポート、アウトバウンドのタグを探します。想定したプロキシ経由のアウトバウンドが確認できてから、ノードの接続経路を判断してください。
• 2種類の名前解決を区別する：まずノードのサーバードメインを名前解決する必要があります。プロキシ経由の接続先サイトでも名前解決が発生することがあります。この2か所では対処方法が異なります。
• ルール用リソースを確認する：参照先のルール用リソースが見つからないというログがある場合は、まずリソースの読み込みを修正します。リソースの読み込み失敗を、リモートポートに接続できない問題と混同しないでください。

DNSの問題を切り分けるために、ノードのドメインを古いIPアドレスへ安易に置き換えないでください。ドメインを入口に使うサービスでは、接続先のIPアドレスが切り替わることがあります。また、IPアドレスに変更しても、TLSのサーバー名は元の値を維持する必要がある場合があります。まず名前解決の結果を調べ、サービス提供元の案内する接続先を確認したうえで、元に戻せる方法で比較してください。

5. コアのログから接続失敗の段階を特定する

クライアントのログ画面から、リクエスト失敗の前後を保存します。現在のログレベルで接続の過程が分からない場合は、「設定」→「パラメータ設定」でログレベルを探し、一時的に詳細度を上げてからコアを再起動し、1回だけ再現させてください。確認後は通常のログレベルに戻し、大量のログが出続けないようにします。以下のエラーは前後に長いログが付くことがあります。判断する際は、接続先のアドレスと操作内容も残してください。

6. 最後にノード設定とサーバーの待ち受けを確認する

ローカルの接続口、ルーティング、ネットワークに問題がないことを確認してから、ノード設定を調べます。VMessとVLESSは異なるプロトコルです。プロトコル名だけを置き換えて、元の設定をそのまま使うことはできません。通信方式、TLS、セキュリティ設定はサーバー側と一致している必要があります。クライアントに設定をインポートできても、選択したコアがすべての機能に対応しているとは限りません。

Windows PowerShellではTest-NetConnectionを使って、ノードのTCPポートを確認できます。-ComputerNameにはノードの実際のアドレスを、-Portには実際のポート番号を指定します。このコマンドで分かるのはTCP接続を確立できるかどうかだけです。VMess、VLESS、TLSや、その後の接続先へのアクセスは検証できません。UDPベースの通信についても、この結果だけで判断しないでください。

• サブスクリプションを利用している場合：信頼できる既存の配布元からサブスクリプショングループを更新し、アドレス、ポート、通信設定に変更がないか比較します。重複してインポートした結果、古いノードを選択したままにならないよう注意してください。
• サーバー管理者の場合：サービスの稼働状態、設定の読み込み、対象ポートの待ち受けを確認します。ホスト側のファイアウォールとクラウド側のインバウンドルールで通信が許可されているかも確認してください。
• リバースプロキシを使用している場合：証明書、ドメインの名前解決、転送先をそれぞれ確認してください。公開ポートが開いていても、バックエンドのサービスが使えるとは限りません。
• リクエストがサーバーに到達している場合：サーバー側の送信DNS、ルーティング、接続先サイトへの接続を確認します。サーバーとのハンドシェイクが完了していても、指定したサイトにアクセスできないことがあります。

7. 複数の条件でテストし、再現できる記録を残す

最後に小規模な比較テストを行います。同じ端末でネットワークを変える、同じネットワークで端末を変える、同じクライアントでノードを変える、といった方法で確認してください。毎回、ほかの条件は変えないようにします。別のネットワークで使える場合は元の通信経路を調べる価値がありますが、通信事業者の制限とは限りません。端末の違い、DNS、通信の引き継ぎ設定も、ネットワークを変えると影響を受ける可能性があります。

1. 同じノードが2つのネットワークで失敗し、ほかのノードは使える：発生時刻、ノード名、エラー部分をまとめ、サービス提供元に接続先とサーバーの状態を確認してもらいます。
2. 同じネットワークで1台の端末だけ失敗する：その端末の待ち受けポート、ルーティング、システムプロキシ、TUNの権限、セキュリティソフトの記録を確認します。
3. 特定のサイトだけ開けない：サイト自体の稼働状況、ルーティング結果、接続先の名前解決、サーバーからのアクセス結果を確認します。クライアント設定全体をすぐに作り直さないでください。
4. 復旧した後：一時的に変更したログレベルを戻し、テスト用ルールを削除してから、普段のルーティングと通信の引き継ぎ設定をひとつずつ戻します。問題が再発しないことを確認してください。