v2rayNの接続テストがタイムアウトする、プロキシを有効にするとWebページが開かない、ノードを変更してもつながらない場合に役立つ手順です。まず通常接続とプロキシを明示したリクエストを別々に試し、PC側とクライアント側を切り分けます。その後、ノード設定、トランスポート設定、サーバーの待ち受けを確認します。一度に変更する項目は1つにし、該当するログを残して、ポート競合、DNS障害、接続先への到達不可を混同しないようにしましょう。
まず確認：接続テストのタイムアウトか、実際のリクエストの失敗か
「ノードがタイムアウトする」だけでは原因を特定できません。TCP接続テストで分かるのは、接続先ポートに接続できるかどうかです。実際のプロキシ経由の遅延テストでは、プロキシプロトコル、テスト先、リクエストのタイムアウト設定も影響します。一覧にタイムアウトと表示されても、すべてのWebサイトにアクセスできないとは限りません。遅延が表示されても、証明書やルーティング、すべてのアプリが正常とは限りません。
まずノードを1つ選んで有効にし、固定のHTTPSアドレスを開いてください。ノード、ルーティングモード、DNSを同時に切り替えるのは避けます。問題が発生した時刻を分単位で記録し、同じ時刻のコアログを確認してください。ノード一覧のスクリーンショットだけでは、接続がどの段階で止まったか分からないことがほとんどです。
- すべてのノードがタイムアウトする：まずPCのネットワーク、コアの起動状態、ローカルポート、共通設定を確認します。同じ提供元のノードは、サーバー側の障害で同時に使えなくなることもあります。
- 特定のノードだけ失敗する：サーバーアドレス、ポート、トランスポート方式、接続先の状態を優先して比較します。クライアント全体のリセットは後回しにしましょう。
- ブラウザーでは失敗するが、プロキシを指定したリクエストは成功する：ノードの認証情報を変更するのではなく、システムプロキシ、ブラウザーのプロキシ拡張機能、ルーティングを確認してください。
- 特定のテスト先だけ失敗する：アクセスできることが分かっている別の接続先で再テストし、テスト先の障害かノードの問題かを切り分けます。
手順1：プロキシを停止し、PCのネットワークとDNSを確認する
v2rayNのトレイメニューで「システムプロキシ」から「システムプロキシを解除」を選び、TUNモードもオフにします。ネットワークを制御するほかのツールも一時的に終了し、通信が仮想アダプターを経由しない状態にしてください。そのうえで、普段から直接接続できるサイトにアクセスします。開けない場合は、まずWi-Fiのログイン、ゲートウェイ、または通信事業者との接続を確認します。
-
通常接続に戻す
システムプロキシを解除してTUNをオフにしたら、ブラウザーを開き直します。ブラウザーに個別のプロキシ設定がある場合は、システム設定を使う状態に戻してください。クライアントのメインウィンドウを閉じるだけでは不十分です。
-
IPアドレスを確認する
Windowsのターミナルで
ipconfigを実行し、現在使っているネットワークアダプターのIPv4アドレスとデフォルトゲートウェイを確認します。利用可能なゲートウェイがなく、169.254.x.xが表示される場合は、ネットワークに再接続するかDHCPを確認してください。 -
名前解決を確認する
次のDNSコマンドを実行します。まず一般的なドメイン名が名前解決できることを確認し、次にノードで実際に使うドメイン名でも同じ確認を行ってください。ノードにIPアドレスを設定している場合、この手順ではノードアドレスの名前解決を確認できません。
-
別のネットワークで試す
スマートフォンのテザリングを使い、同じノードでもう一度テストします。元のネットワークでのみ失敗する場合は、クライアントを再インストールする前に、使用中のネットワークのDNS、外向き通信の制限、ルーティングを確認してください。
ipconfig
nslookup example.comexample.com はコマンドの形式を示すための例であり、ノードのサーバーではありません。名前解決に成功しても、IPアドレスが分かっただけで、そのアドレス上のサービスに接続できるとは限りません。また、ping に応答がないだけでノードがオフラインだと判断しないでください。接続先がICMPを無効にしていても、TCPサービスは正常に動作している場合があります。
手順2：コア、ローカルポート、システムプロキシを確認する
基本的なネットワーク接続が復旧したら、クライアントを起動してノードを選択します。v2rayNの「設定」→「パラメーター設定」を開き、ローカルの待ち受け設定と使用中のコアを確認してください。デスクトップ版によってサブページの名称が異なる場合があるため、実際の項目名を確認します。まずログに設定の読み込みエラーがないことを確かめてから、システムプロキシを確認します。通常のプロキシモードの問題をTUNで覆い隠さないようにしてください。
以下ではローカルのSOCKS入口 127.0.0.1:10808 を例にします。実際のポートは現在の設定で確認してください。混合プロキシ入口を使う設定や、HTTP入口を別に設ける設定もあります。古い設定では 10809 が使われている場合もあります。ポート番号だけでプロトコルを判断したり、SOCKSポートをHTTPプロキシとして誤って設定したりしないでください。
netstat -ano | findstr :10808
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/- まず待ち受けを確認：
netstatの出力にあるLISTENINGは、プロセスがポートを待ち受けていることを示します。最後の列はPIDです。何も表示されない場合は、まずコアが起動しているか、ポート番号が変更されていないかを確認してください。 - 次にプロセスを確認：タスクマネージャーの「詳細」タブでPIDを確認し、どのプロセスか特定します。別のプログラムがポートを使用している場合は、用途を確認してから該当するプログラムを終了するか、ローカルの待ち受けポートを変更してください。システムプロセスをむやみに終了しないでください。
- プロキシを明示して指定：この例の
socks5hは、接続先のドメイン名をSOCKSプロキシ側で名前解決します。ただし、ノードサーバー自体のドメイン名はローカルでの名前解決が必要な場合があります。--noproxy ""は、このリクエストで直接接続の例外を解除する指定です。 - 応答内容を見分ける：HTTPレスポンスを受信できれば、ステータスコードが403や405でも、今回の接続先へのプロキシ経由のリクエストには応答があったことを示します。接続先のサイト側のポリシーも考慮してください。20秒は今回の診断に使う上限であり、ソフトウェアの既定値ではありません。
結論：プロキシを明示したリクエストが成功したら、通信の経路を確認
このコマンドで応答があり、ブラウザーでは失敗する場合は、ノード設定を変更せず、「システムプロキシ」→「システムプロキシを自動設定」を有効にし、ブラウザーの拡張機能とシステムプロキシの例外設定を確認します。プロキシを明示したリクエストも失敗する場合は、ログと接続先を引き続き調べてください。システムプロキシのオン・オフを繰り返す必要はありません。
手順3：ノード設定を確認し、項目を推測で追加しない
問題のあるノードの編集画面を開き、サーバーから提供された元の設定と項目ごとに照合します。VMessとVLESSは異なるプロトコルです。プロトコル名を変更しても相互に変換されません。サブスクリプションは設定を配布する方法にすぎず、更新に成功してもノードの利用可否、アカウントの有効性、接続先のサービス状態は保証されません。
| 確認項目 | 確認内容 | よくある誤り |
|---|---|---|
| サーバーとポート | ドメイン名またはIPアドレスと、接続先の待ち受けポートを正確に照合する | ローカルの10808をサーバーポートと勘違いする、または接続先のポートをすべて443に変更する |
| プロトコルと認証情報 | VMess / VLESS、ユーザーID、サーバーが要求する関連項目を確認する | コピー時に文字が欠ける、または別のノードの認証情報とアドレスを混同する |
| トランスポート方式 | TCP、WebSocket、gRPCなど、実際の設定を確認する | トランスポート方式は表示名にすぎず、自由に切り替えられると思い込む |
| セキュリティ設定 | TLSまたはREALITYと、対応するサーバー名や専用項目を確認する | REALITYを通常のTLSと同じものと考え、ドメイン名だけ入力して保存する |
| ルーティングとアウトバウンド | テスト先への通信が直接接続やブロックルールではなく、想定したアウトバウンドを通ることを確認する | 有効なノードを選べば、すべてのリクエストがそのノードを通ると思い込む |
サブスクリプションを更新したばかりの場合は、更新後の項目が選択されていることを確認してください。同じ名前の項目が複数あると古い設定を選びやすくなります。元の設定は残したまま、テスト用の項目に見分けやすいメモを付けると便利です。共有リンク全体、ユーザーID、サブスクリプションURLを公開の掲示板に投稿しないでください。問い合わせ時は、プロトコル、トランスポート方式、エラーメッセージ、伏せ字にしたアドレスだけを共有します。
手順4：ログからTLSとトランスポート層のエラーを特定する
クライアントのログで今回のリクエスト時刻を確認し、エラーがドメイン名の解決、TCP接続、TLSハンドシェイク、トランスポートの確立のどの段階で発生したかを調べます。以下はよくあるエラーの例です。前後のログはコアによって異なります。context deadline exceeded だけではタイムアウトしたことしか分からないため、その直前にどの処理をしていたかも確認してください。
エラー：dial tcp: lookup
原因：ノードのドメイン名を解決できないときによく発生します。詳細なログには通常、ドメイン名とDNSエラーも含まれます。
対処：まず nslookup で同じドメイン名を確認し、クライアントのDNS設定と現在のネットワークを確認します。修正後に再試行し、新しいログを確認してください。
エラー：connect: connection refused
原因：接続が明示的に拒否されています。接続先ポートで待ち受けていない、ファイアウォールが拒否している、またはローカルのプロキシ入口が起動していない可能性があります。
対処：まずエラーに表示されたアドレスが 127.0.0.1 か、接続先のアドレスかを確認します。ローカルの場合は待ち受けを確認し、接続先の場合は管理者にサービスとファイアウォールを確認してもらってください。
エラー：i/o timeout
原因：ネットワークの読み書き処理のいずれかが期限を超えています。パケットロス、応答のない破棄、接続先から応答がない状態などが考えられます。
対処：ログの前後からタイムアウトした段階を特定し、別のネットワークでも比較します。この1行だけでパスワードの誤りやサーバーの停止と判断しないでください。
エラー：x509: certificate has expired or is not yet valid
原因：PCの時刻がずれているか、サーバー証明書の有効期間が切れている、またはまだ始まっていない可能性があります。
対処：まずWindowsの「設定」→「時刻と言語」→「日付と時刻」で時刻を合わせてから、管理者に証明書の有効期間を確認してもらってください。
エラー：websocket: bad handshake
原因：WebSocketのアップグレード応答が想定と異なります。パス、Host、リバースプロキシの転送先、接続先サービスの設定が一致していない場合によく発生します。
対処：サーバー設定と照合してWebSocketのパスとHostを確認し、リバースプロキシがそのパスを正しいバックエンドに転送しているか調べてください。
TLSのSNIはハンドシェイクで使うサーバー名、WebSocketのHostはHTTPリクエストのフィールドであり、用途が異なります。サーバーアドレス、SNI、Hostは同じ場合もあれば、構成に応じて別々に設定する場合もあります。アドレス欄の値に一律で置き換えないでください。gRPCでは serviceName と中間プロキシのHTTP/2対応も確認します。パスや名前の大文字・小文字も一致させてください。
手順5：サーバーの待ち受けと入口のファイアウォールを確認する
PC側とノード設定の確認が済んでから、権限のある管理者にサーバー側を確認してもらいます。通常のサブスクリプション利用者がサーバーのログイン情報を探す必要はありません。サービス提供元には、障害の発生時刻、利用ネットワーク、ノードのメモ、個人情報を伏せたログを伝えてください。以下のコマンドはLinuxサーバー用です。必要な権限がある環境で実行してください。
sudo ss -lntp
sudo systemctl status xray --no-pager
sudo journalctl -u xray --since "20 minutes ago" --no-pagerここではサービスユニット名を xray と仮定しています。実際の構成でこの名前を使っている場合のみ、そのまま実行してください。V2Rayや独自のサービスユニット名を使っている環境では、実際の名前に置き換えます。サービスが稼働中でも、対象ポートが待ち受けているとは限りません。ss の出力で待ち受けアドレス、ポート、プロセスを確認してください。
- 入口ポートを確認：クライアントがTCP 443を使う場合は、インターネット側の入口でTCP 443を確認します。UDP 443だけを許可しても接続できません。ほかのポートも実際の設定に合わせて確認してください。
- フロントエンドとバックエンドを区別：リバースプロキシを使う構成では、インターネット側の443をリバースプロキシが待ち受け、コアはループバックアドレス上のバックエンドポートだけを待ち受ける場合があります。これは正常な構成です。バックエンドをすべてインターネットに公開しないでください。
- 2段階のファイアウォールを確認：クラウドのセキュリティグループとサーバーのファイアウォールの両方で、実際の入口を許可する必要があります。片方だけ変更してもタイムアウトすることがあります。
- DNSレコードを確認：ドメイン名にAレコードとAAAAレコードがある場合は、IPv4とIPv6それぞれの待ち受けと到達性を確認します。一方のアドレスだけ正常で、もう一方が接続に失敗する状態を見落とさないようにしてください。
- サービスログを確認：ポートのバインド失敗、設定の解析失敗、ユーザー認証失敗、証明書の読み込みエラーを探します。ログにリクエストが記録されていない場合は、リクエストが手前のリバースプロキシで止まっていないかも確認してください。
結論：同じノードを異なるネットワークで比較する
同じノードがテザリングでは使えて元のネットワークでは失敗する場合は、サーバー設定を変えずに元のネットワーク経路を調べます。複数のネットワークで失敗し、サーバーの入口ポートも待ち受けていない場合は、まず接続先サービスを復旧させます。ポートには接続できてもプロキシリクエストが失敗する場合は、プロトコル、認証、トランスポート層のログに戻って確認してください。
ノードのタイムアウトに関するよくある質問と再テストの記録
すべてのノードがタイムアウトします。まずv2rayNを再インストールすべきですか？
まず再インストールする必要はありません。通常接続のネットワーク、コアのログ、ローカルの待ち受け、プロキシを明示したリクエストを順に確認してください。同じ提供元のノードがすべて失敗し、ほかの利用可能な設定では正常な場合は、提供元にサービス状態を確認してもらいましょう。再インストールしても、接続先の停止やサブスクリプション設定の誤りは解決しません。
TCPテストでは遅延が表示されるのに、Webページが開かないのはなぜですか？
TCP接続の成功だけでは、その後の認証、TLS、アプリケーションリクエストの成功は確認できません。前述の curl.exe コマンドでリクエスト全体をテストし、同じ時刻のログを確認してください。リクエスト全体が成功する場合は、リモートポートを変更せず、システムプロキシ、ブラウザーの設定、ルーティングを修正します。
TUNを有効にしたときだけネットワークに接続できなくなります。どうすれば戻せますか？
まずTUNをオフにしてシステムプロキシを解除し、通常接続が復旧するか確認します。次に通常のシステムプロキシでノードをテストします。成功した後でTUNだけを有効にし、権限、仮想ネットワークアダプター、DNS、ルーティングの制御を確認してください。ネットワークを制御するツールを複数同時に使わないでください。
同じノードがAndroidでは使えるのに、デスクトップではタイムアウトするのはなぜですか？
まず両方の端末を同じネットワークに接続し、サーバー、ポート、トランスポートの設定が一致していることを確認してください。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。特定の設定への対応状況はコアによって異なります。デスクトップ側では、実際に選択されているコア、ローカルポート、システム時刻も確認してください。
修正後は同じ接続先へ3回続けてリクエストを送り、応答の有無を毎回記録してから、普段使うルーティングとアプリの設定に戻します。1回成功しただけでは断続的な障害を否定できず、失敗が続いてもタイムアウト時間を延ばすだけでは解決しません。テスト記録にはネットワークの種類、有効なノード、コアの種類、失敗した段階、今回の変更内容を残し、認証情報は記録しないでください。
- 基本ネットワーク：通信制御を解除すると直接接続できるか、ノードのドメイン名を名前解決できるか。
- ローカルの入口：実際の待ち受けアドレス、ポート、プロセスが設定と一致しているか。
- リクエスト全体：プロキシを明示したリクエストに応答があるか、ブラウザーでも同じ結果になるか。
- 接続先の状況：サービスが待ち受けているか、ログにテスト時刻の記録があるか。