v2rayNは起動し、ノードも登録済みなのに、遅延テストがタイムアウトしたりブラウザーでアクセスできなかったりする場合に向けた内容です。ローカルプロキシの未起動、接続先ポートへの到達不可、プロトコルのハンドシェイク失敗を切り分け、システム時刻、ローカルの待ち受け、ファイアウォール、トランスポート設定、ルーティングとDNSの順に確認します。複数の設定を同時に変更せず、各手順で再現可能なテスト結果を記録してください。
1. タイムアウトが発生している段階を確認する
「ノードのタイムアウト」は、ひとつの原因で起きるとは限りません。TCP遅延テストで分かるのは、通常、接続先ポートへの接続が確立できるかどうかです。実際の接続テストや可用性テストでは、プロキシプロトコルや接続先サイトも経由します。テスト対象によって結果が異なる場合があります。TCPテストに成功しても、VMessやVLESSの認証に成功したとは限りません。また、特定のテストサイトに接続できなくても、すべての通信が失敗しているとは限りません。
まずノードをひとつ選び、テスト時刻、サーバーアドレス、ポート、プロトコル、トランスポート方式、使用中のコアを記録します。v2rayNのメイン画面でログを開き、リクエストを再実行して、同じ時刻に記録された最初のエラーを探してください。その後に続く接続終了のメッセージは、直前のエラーが原因で表示されていることがよくあります。
- すべてのノードで失敗する：まずシステム時刻、ローカルのコア、ネットワークの出口、サブスクリプション全体の障害を確認します。
- 特定のノードだけ失敗する：そのノードの設定、サーバーの稼働状況、アカウントの有効性を優先して確認します。
- プロキシテストは成功するがブラウザーでは失敗する：アプリがシステムプロキシを参照しているか、ブラウザーの拡張機能がプロキシ設定を上書きしていないかを確認します。
- 一部のサイトだけ失敗する：クライアントをすぐに再インストールするのではなく、ルーティングルール、DNS、接続先サイトへの到達性を確認します。
2. システム時刻を合わせてから接続を再テストする
VMessの認証には時刻が関係するため、クライアントとサーバーの時刻に大きなずれがあると認証に失敗することがあります。TLS証明書の検証も現在時刻に依存しており、年や日付が正しくないと、有効な証明書が未発効または期限切れと判断される場合があります。VLESSにVMessの時間幅の判定をそのまま当てはめることはできませんが、TLSなどのセキュリティレイヤーを使う場合は、システム時刻を正確に保つ必要があります。
-
システム時刻を同期する
Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にして、「今すぐ同期」をクリックします。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を有効にします。
-
実際の日時を確認する
年月日と現在時刻が正しいことを確認してください。タイムゾーンは表示に影響しますが、認証で主に使われるのは実際のタイムスタンプです。表示上のタイムゾーンだけをサーバー所在地に変更しないでください。スリープから復帰した後に時刻が繰り返しずれる場合は、システム時刻サービスとハードウェアクロックを確認します。
-
ノードを再読み込みする
v2rayNで現在のノードを選び直し、設定を読み込ませてから、同じ種類の接続テストを実行します。自分でサーバーを管理している場合は、サーバー側の時刻も確認してください。クライアント側だけを修正しても、サーバー側の大きな時刻ずれは解消できません。
3. ローカルポートを確認する：10808と10809は実際の設定に従う
v2rayNはクライアントの画面であり、実際にポートを待ち受けて接続を転送するのは起動中のコアです。コアの起動に失敗しても、画面にノード一覧が残る場合がありますが、アプリからローカルプロキシポートにアクセスすると失敗します。ポートの用途はバージョンや設定によって異なります。一般的な設定では10808を使用し、古い設定ではSOCKSポートに10808、HTTPポートに10809をそれぞれ使用する場合があります。混合インバウンドに対応した設定では、同じポートで両方のリクエストを受け付けられます。
「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートとアドレスを確認します。項目名は使用中のバージョンによって異なります。次に、ログに待ち受け成功の記録があるか確認してください。ネット上の手順だけを根拠にブラウザーへ10809を設定したり、ローカルプロキシのポートを接続先サーバーのポート欄に入力したりしないでください。
| OS | 確認コマンド | 確認するポイント |
|---|---|---|
| Windows PowerShell | Get-NetTCPConnection -State Listen -LocalPort 10808 | 待ち受けの記録があるか、OwningProcessが想定したコアのプロセスか |
| Windowsのプロセスを確認 | Get-Process -Id 1234 | 1234を直前の結果に表示されたプロセスIDに置き換えます |
| macOSのターミナル | lsof -nP -iTCP:10808 -sTCP:LISTEN | 待ち受け中のプロセスとポートを確認します。何も表示されない場合はコアのログを確認してください |
ポートが別のプログラムに使用されている場合は、まずプロセスを特定し、正体の分からないシステムサービスを終了しないでください。重複して起動したクライアントを終了するか、ローカルポートを未使用のポートに変更し、アプリのプロキシ設定も合わせて更新します。このPCだけで使う場合は、通常127.0.0.1での待ち受けで十分です。トラブルシューティングのためにLANからのアクセスを有効にする必要はありません。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/Windowsでは、コマンドのエイリアスによる違いを避けるためcurl.exeを使用できます。上記のコマンドは、そのポートがSOCKSに対応している場合に限り使用できます。socks5hは、接続先のドメイン名をプロキシ側で処理する指定です。HTTPインバウンドしかない場合は、プロキシアドレスをhttp://127.0.0.1:10809に変更し、実際のポートを指定してください。HTTPレスポンスが返れば、そのリクエストのプロキシ経由の通信は完了しています。403が返った場合も、接続タイムアウトとは分けて対処してください。
4. 接続先ポートとファイアウォールを確認する：Pingを接続テストの代わりにしない
サーバーでICMPが禁止されている場合、Pingが通らなくてもプロキシサービスに到達できないとは限りません。反対に、Pingに成功してもプロキシポートが待ち受け中とは限りません。TCP接続の場合は、ノードで実際に使っているサーバーアドレスとポートをテストします。以下のドメイン名はコマンド形式の例です。実行時にはノード設定の実際のアドレスに置き換え、ポートも実際の値に変更してください。
# Windows PowerShell: TCPポートをテスト
Test-NetConnection -ComputerName example.com -Port 443
# macOS: TCPポートをテスト
nc -vz -G 10 example.com 443- ポートテストに成功：今回のTCP接続が確立できたことを示します。続けてTLS、トランスポート方式、プロトコル認証を確認してください。ノードが完全に利用可能であることを示すものではありません。
- すぐに接続が拒否される：サービスが待ち受けていない、ポートの指定が誤っている、またはファイアウォールが明示的に拒否している可能性があります。サーバー管理者にプロセス、待ち受けポート、受信ルールを確認してもらってください。
- 待ってもタイムアウトする：パケットロス、ネットワーク出口の制限、サーバーのファイアウォール、セキュリティグループによる破棄などが考えられます。別のネットワークでもテストしてください。
- UDPを使用する：TCPテストでUDPの疎通は確認できません。該当するコアのログとサーバー側の記録を合わせて判断してください。
PC側のファイアウォールでは、コアプログラムの送信許可を確認します。他のデバイスにプロキシを共有する場合に限り、ローカルプロキシの受信ルールも確認してください。トラブルシューティングのためにファイアウォール全体を無効にしたままにしないでください。企業ネットワークの制限は、ネットワーク管理者がルールに沿って対応する必要があります。サーバー側では、クラウドプラットフォームのセキュリティグループとOSのファイアウォールの両方を確認します。どちらか一方で許可されていないだけでもタイムアウトの原因になります。
結論：まず別のネットワークで比較する
同じノードと設定を使い、PCのネットワークだけをAndroidスマートフォンのテザリングに切り替えて再テストします。元のネットワークではタイムアウトし、テザリングでは接続できる場合は、元のネットワークの出口、DNS、ポート制限を優先して調べてください。ノード、コア、ルーティングを同時に変更するより、原因を絞り込みやすくなります。
5. トランスポート設定を照合する：ポートに接続できてもハンドシェイクに失敗する
VMessとVLESSはプロキシプロトコル、WebSocketやgRPCなどはトランスポート方式、TLSはセキュリティレイヤーです。それぞれ設定の階層が異なり、互いに置き換えることはできません。リンクをインポートした後も、重要な項目を確認してください。特にリバースプロキシや中継を経由するノードでは、接続アドレス、TLSの検証用ドメイン名、HTTP Hostが異なる場合があります。
| 確認項目 | 一致させる設定 | よくある間違い |
|---|---|---|
| プロトコルと認証情報 | VMessまたはVLESSの種類、UUID、サーバーが要求する関連パラメーター | プロトコル名だけを変更し、別の種類のノードの設定をそのまま使う |
| TLSとSNI | TLSの有効・無効、検証用ドメイン名、証明書の対象範囲 | 接続先をIPアドレスに変更した際に、必要なSNIまで削除してしまう |
| WebSocket | トランスポート方式、パス、Host、リバースプロキシのルール | /rayと/ray/を混在させる、またはパスの大文字・小文字が異なる |
| gRPC | サービス名、およびサーバーが要求するHTTP/2とTLSの設定 | WebSocketのパスをそのままサービス名に入力する |
| VLESSのセキュリティ設定 | サーバー指定のflow、REALITY使用時の公開鍵、shortId、serverNameなど | 別のノードからセキュリティ設定をコピーする、またはセキュリティレイヤーを任意に切り替える |
サブスクリプションが更新されている場合は、「サブスクリプショングループ」メニューから該当グループを更新してから、ノードを選び直してください。手動編集した古いノードには、期限切れのポート、パス、認証情報が残っている場合があります。「特定のコアを使う」ことは、すべてのノードに互換性があるという意味ではありません。現在使っているXray-coreなどの実際のコアがノードの機能に対応しているか確認し、まずはクライアントに付属するコアを使用してください。
エラー：bind: address already in use
原因：ローカルの待ち受けアドレスまたはポートが使用中のため、現在のコアがバインドできません。
対処：使用中のプロセスを特定し、重複したインスタンスを終了するかローカルポートを変更してから、アプリのプロキシポートも合わせて変更します。
エラー：x509: certificate has expired or is not yet valid
原因：PCの時刻が正しくないか、サーバー証明書の有効期間が実際に切れている、または開始前です。
対処：まず時刻を同期します。時刻が正しいのに再発する場合は、管理者に証明書の更新状況と実際に配信される証明書チェーンを確認してもらってください。
エラー：websocket: bad handshake
原因：WebSocketのアップグレードリクエストに期待した応答がありません。パス、Host、リバースプロキシの転送設定が一致していない場合によく発生します。
対処：パスとHostを一字ずつ照合し、サーバー管理者に入口の応答ステータスとアップグレードリクエストの転送設定を確認してもらってください。
エラー：context deadline exceeded
原因：処理のいずれかが制限時間内に完了しませんでした。このエラーだけでは、認証、DNS、ネットワークのどこで問題が起きたか特定できません。
対処：前後の接続先とエラー記録を確認し、ローカルの待ち受け状況と接続先ポートのテストを組み合わせて、タイムアウトが発生した段階を特定してください。
6. プロキシ接続が正常なら、システムプロキシ、DNS、ルーティングを確認する
プロキシを明示的に指定したcurlリクエストが成功するのにブラウザーで開けない場合は、まずv2rayNのトレイメニューにある「システムプロキシ」で「システムプロキシを自動設定する」を選び、ブラウザーに個別のプロキシ設定がないか確認してください。システムプロキシの設定を使うアプリにのみ影響し、すべてのネットワーク通信を引き受けるわけではありません。トラブルシューティングの初期段階では、仮想ネットワークアダプター、ルーティング、権限という新たな要因を増やさないよう、TUNを同時に有効化したり切り替えたりしないでください。
- ルールの適用先を確認：ログで、失敗したリクエストがどのアウトバウンドを使用したか確認します。ルールによって宛先が直接接続に振り分けられていると、ノードが正常でもアクセスに失敗することがあります。
- 名前解決の場所を切り分ける：接続先ノードのアドレス自体も、最初に名前解決が必要です。SOCKS経由で接続先サイトの名前解決に成功しても、PC上でノードのドメイン名を正常に解決できるとは限りません。
- アドレスファミリーを比較：ドメイン名からIPv4とIPv6の両方が返される場合は、どちらか一方だけで失敗していないか確認します。システム全体のIPv6を無効にするのは、最初の対処にしないでください。
- テスト対象を確認：可用性テストの接続先自体が一時的に停止していたり、リクエストを制限していたりする場合があります。明確にアクセスできるHTTPS接続先を2つ使って確認し、ひとつの速度テストの数値だけに頼らないでください。
7. 再現時の情報を整理してから、ノードの変更を判断する
トラブルシューティングは、「再起動したら直った気がする」で終わらせず、再現可能な結果で締めくくりましょう。復旧後も同じリクエストを使って2回テストし、ハンドシェイクや待ち受けのエラーが続いていないことをログで確認します。特定のノードだけが失敗し、ローカルポート、システム時刻、ネットワークを切り替えたテストに問題がなければ、ノードのサービス提供元に問い合わせてください。
- OSのバージョン、v2rayNのバージョン、実際に動作しているコアの名前とバージョンを記録します。バージョン番号は現在のプログラム情報で確認し、インストーラーのファイル名から推測しないでください。
- 障害が発生した時刻、元のネットワークとテザリングでの比較結果、TCPテストとプロキシを明示したリクエストそれぞれの成否を記録します。
- 同じリクエストの前後に記録された必要なログを共有します。サブスクリプションのリンク、UUID、アクセストークン、個人のネットワーク情報を隠し、設定全体を公開しないでください。
- 各手順で変更する前と後の結果を記録します。一度に変更するパラメーターはひとつにし、効果のなかった変更を元に戻してから次のテストに進んでください。
確認する順序は、時刻の調整、コアの待ち受け確認、接続先ポートのテスト、トランスポートと認証の照合、最後にアプリのプロキシ設定、DNS、ルーティングです。この順に調べることで「すべてタイムアウトする」という問題を段階ごとに切り分けられ、クライアントを何度も入れ替えて原因の手がかりを失うことも防げます。