ノードの速度テストがタイムアウトする、起動後に接続できない、ネットワークを切り替えたら急に使えなくなった、といった場合に役立つ手順です。まずローカルの待ち受け、サーバーのポート、プロトコルのハンドシェイクを切り分け、時刻・通信方式・TLS設定を確認します。最後に同じリクエストのログを見て原因を絞り込みます。macOSではv2rayN、Androidではv2rayNGを例に説明します。ポート番号は例なので、実際に使っている値に置き換えてください。
1. まずタイムアウトが起きている段階を確認
「ノードのタイムアウト」は、原因が一つとは限りません。TCPポートに接続できない、TLSのハンドシェイクに失敗する、プロキシ認証が通らない、テスト先から応答がないなど、さまざまな状況が画面上でタイムアウトと表示されます。何をしたときに起きたのかを記録しましょう。サブスクリプションの更新、サーバーへの実接続を伴う遅延テスト、ブラウザーでのWebサイト表示のどれでしょうか。サブスクリプションを取得できないからといって、登録されたノードがすべて使えないとは限りません。
切り分けでは、ノード・テスト先URL・接続方式を一つずつ固定します。デスクトップではTUNを無効にし、明示的なプロキシ設定でローカルの接続口をテストします。Androidではv2rayNGだけを起動し、ほかのVPNサービスが接続を引き継がないようにしてください。DNS、ルーティング、ノード、コアを同時に変更すると、復旧しても原因を特定できません。
| 症状 | まず確認する項目 | この症状だけでは判断できないこと |
|---|---|---|
| ローカルのプロキシポートへの接続が拒否される | コアが起動しているか、待ち受けアドレスとポートが正しいか | リモートノードが停止しているかどうか |
| サーバーのTCPポートがタイムアウトする | 名前解決、ポート、ネットワーク経路、ファイアウォール | UUIDまたはパスワードが間違っているかどうか |
| ポートには接続できるが、実際のリクエストは失敗する | TLS、通信方式、認証、サーバー側の出力先 | 通信経路に問題がないかどうか |
| 特定のテスト先URLだけ失敗する | テスト先のURL、接続先サイト、ルーティングルール | すべてのプロキシリクエストが失敗する |
2. 端末の時刻と基本ネットワークを確認
証明書を調べる前に、まず時刻を合わせます。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、自動設定を有効にして日付・年・タイムゾーンが正しいことを確認してください。Androidでは通常「設定」→「システム」→「日付と時刻」にあります。機種によっては「その他の設定」内にあります。日付と時刻、自動タイムゾーンの設定を有効にしましょう。時刻を合わせたらクライアントを再起動し、もう一度接続します。
システム時刻がずれていると、証明書の有効期間を正しく判定できず、VMessの認証にも影響する場合があります。タイムゾーンだけを変えて実際の時刻がずれたままでは解決しません。自動設定を有効にしても時刻が大きくずれる場合は、システムの時刻同期がネットワークに接続できているか先に確認してください。時刻の問題を隠すために証明書検証を無効にするのは避けましょう。
-
テスト条件を固定する
ノードを一つ選び、現在のネットワーク、テスト先URL、エラーが起きた時刻を記録します。ほかのプロキシやVPNサービスは停止し、別の経路に通信を引き継がれないようにしてください。
-
システム時刻を合わせる
システムの「日付と時刻」で自動設定を有効にします。日付と時刻が正しいことを確認したら、v2rayNまたはv2rayNGを終了して再起動してください。
-
通常のネット接続を確認する
プロキシを一時停止し、現在のネットワークから直接アクセスできるWebサイトを開きます。公衆Wi-Fiで認証ページが表示される場合は、先に認証を完了してください。基本のネット接続が使えない状態では、ノードの設定を変更しても解決しません。
-
別のネットワークで再テストする
ノードと設定はそのままにして、スマートフォンのテザリングに切り替えます。ネットワークを変えて復旧した場合は、元のネットワークにおけるポート制限、DNS、出口ポリシーを優先して確認します。
3. ローカルの待ち受けポートとサーバーのポートを分けて確認
ローカルの待ち受けポートとノードサーバーのポートは別のものです。前者はブラウザーやコマンドからクライアントに接続するためのポート、後者はクライアントからサーバーへ接続するためのポートです。以下ではローカルのSOCKSポート10808、リモートのTLSポート443を例にします。すべての環境で同じ値が初期設定とは限りません。
v2rayNの「設定」→「パラメータ設定」でローカルの待ち受けに関する項目を確認します。項目の分類名はバージョンによって異なるため、画面の表示に従ってください。コアを起動した状態で、macOSの「ターミナル」から以下のコマンドを実行します。2つ目のコマンドは、実際にそのポートでSOCKSサービスを提供している場合にのみ使用してください。HTTP専用ポートをSOCKSの指定に使わないでください。
# ローカルポートの待ち受けプロセスを確認
lsof -nP -iTCP:10808 -sTCP:LISTEN
# ローカルのSOCKS経由でHTTPSリクエストを送信
curl --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 5 --max-time 10 \
--output /dev/null --show-error --verbose https://example.com/socks5hでは、アクセス先のドメイン名の処理をSOCKSプロキシに任せます。アプリ側での名前解決の違いを切り分けるのに便利です。ただし、すべてのDNSリクエストが必ずリモート側で処理されるわけではありません。ノードサーバーのアドレスをどこで名前解決するかは、コアとシステムの設定によって決まります。テスト先URLは、確認したいHTTPSサイトに置き換えてください。
- 待ち受けが確認できない：まずコアの起動ログを確認します。設定の読み込み失敗やポートの競合が原因で、ローカルの接続口が作られていない可能性があります。
- ローカルには接続できるが、プロキシのリクエストがタイムアウトする：次にリモートのアドレスとポートを確認し、ハンドシェイクの設定を調べます。
- 明示的なプロキシ経由では成功するが、ブラウザーでは失敗する：システムプロキシ、ブラウザーのプロキシ拡張機能、ルーティングを確認します。すぐにノードを作り直す必要はありません。
- リモートポートを確認：macOSでは
nc -vz -G 5の後に、実際のサーバードメインとポートを指定します。TCP接続の成功で確認できるのはポートに到達できることだけです。プロトコルやアカウントが有効とは限りません。
要点：明示的なプロキシで問題の範囲を絞る
同じノードで上記のcurlリクエストが成功する場合は、まずノードの設定を変更せずに残してください。サーバー設定を同時に変更するより、アプリの通信がクライアントに届くまでの経路だけを修正するほうが、結果を確認しやすくなります。
4. 通信方式・TLS・SNIの設定を一つずつ照合
ポートに接続できてもリクエストが失敗する場合は、ノードの編集画面を開き、サービス提供元から受け取った元の設定と項目ごとに照合します。v2rayNでは通常、ノードをダブルクリックすると編集画面が開きます。v2rayNGでは、設定一覧のノード横にある編集ボタンを使います。サブスクリプションのノードは、先に更新してから設定を確認しましょう。手動で修正する前に元の設定を保存しておけば、次回の更新で変更が上書きされたときに戻せます。
| 確認項目 | 照合する内容 | よくある間違い |
|---|---|---|
| プロトコルと認証情報 | VMess、VLESS、Trojan、Shadowsocksの種類と、対応するUUID・パスワード・暗号化方式 | アドレスとポートが同じなら、同じ種類のノードだと思い込む |
| 通信方式 | TCP、WebSocket、gRPCなど。サーバー側の設定と一致させる | 速度を上げる設定だと思い、通信方式を適当に切り替える |
| WebSocket | パス、Host、TLSの有効・無効 | パスの先頭のスラッシュを付け忘れる、またはパスのパラメータを独断で削除する |
| gRPC | サービス名、TLS、サーバー側で指定されたALPN | WebSocketのパスをそのままサービス名に入力する |
| TLS | サーバー名（SNI）、証明書チェーン、有効期間 | 接続先をIPアドレスに変更した際、SNIまでIPアドレスに変更する |
| REALITY | 公開鍵、shortId、serverName、フィンガープリント、使用するflow | UUIDだけをコピーし、セキュリティ層の設定を見落とす |
SNIはTLSハンドシェイクで使われるサーバー名で、接続先のアドレスと同じとは限りません。接続先がIPアドレスでも、SNIにはサーバー側で指定されたドメイン名が必要な場合があります。WebSocketのHostはHTTP層の設定です。SNIと同じ値を使うことが多くても、別々の項目として扱ってください。
5. 同じリクエストのログから原因を絞り込む
v2rayNのメイン画面にあるログ欄、またはv2rayNGのメニューにある「ログ」を開きます。古い記録を消すか現在時刻を控えたうえで、テストを一度だけ実行してください。通常のログレベルで原因が分からない場合は、短時間だけデバッグレベルに切り替えます。再現後は元のレベルに戻してください。メニュー名はバージョンによって異なるため、他のバージョンの画面をそのまま当てはめず、ログレベルの項目を探してください。
エラー：connection refused
原因：接続先のポートで待ち受けていないか、経路上の機器が接続を拒否しています。エラーに表示されたアドレスがローカルかリモートかを確認してください。
対処：ローカルアドレスのエラーならコアと待ち受けポートを確認します。リモートアドレスのエラーならサーバーのポートを確認し、サービス提供元に待ち受けサービスとファイアウォールの確認を依頼してください。
エラー：i/o timeout
原因：処理のどこかで、読み書きが制限時間内に完了しませんでした。この表示だけでは、パケットロス、ポートに到達できないこと、ハンドシェイクが応答しないことを区別できません。
対処：直前のログにある接続先アドレスと処理段階を確認します。まずポートをテストし、同じ設定のままネットワークを切り替えて再現するか調べてください。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と現在のシステム時刻が一致していません。端末の時刻が誤っている場合も、リモート側の証明書が期限切れの場合もあります。
対処：まずシステム時刻を合わせます。時刻が正しいのにエラーが続く場合は、エラーが発生した時刻をサービス提供元に伝え、証明書の設定を確認してもらってください。
エラー：tls: handshake failure
原因：接続先がTLSのネゴシエーションを拒否しています。SNI、プロトコルのネゴシエーション、誤ったサービスへの接続などが考えられます。
対処：元の設定と照らし合わせ、ポート、TLSの有効・無効、SNI、ALPNを確認します。タイムアウト時間を延ばすだけでは解決しません。
エラー：no such host
原因：ログに表示されたドメイン名を名前解決できません。ノードサーバーのアドレスの場合も、接続先サイトのアドレスの場合もあります。
対処：まずどのドメイン名でエラーが出ているか確認し、入力ミス、DNSリゾルバーへの接続、DNSの振り分けを調べます。すべての名前解決を同じ経路に変更するのは避けてください。
ログのEOFは接続が閉じられたことを示すだけで、アカウントが無効になった証拠にはなりません。直前のハンドシェイク情報や、特定のノードだけで失敗するかどうかも確認しましょう。ログを共有するときは、サブスクリプションURL、UUID、パスワード、トークン、個人のネットワーク情報を隠してください。必要なエラー発生段階、時刻、設定項目の種類だけを残します。
6. コアの互換性とAndroidのバックグラウンド制限を確認
v2rayNとv2rayNGはクライアントで、実際のプロトコル処理はコアが行います。設定画面で項目を読み込めても、現在のコアがその項目に対応しているとは限りません。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用するため、拡張設定への対応が同じとは限りません。特にREALITYや新しい通信方式の項目を使う場合は、クライアントとコアの両方のバージョンを確認してください。
- 両方のバージョンを記録：「バージョン情報」でクライアントのバージョンを、起動ログでコアのバージョンを確認します。端末ごとにインストール元や更新時期が異なるため、「最新版」とだけ記録しないでください。
- 起動時のエラーを確認：未知の項目、通信方式を構成できないエラー、設定の解析エラーが出る場合は、速度テストを繰り返す前に互換性と設定の問題を解決してください。
- 対応する方法で更新：設定を保存してから、クライアントと対応するコアを更新します。互換性のないコアファイルを古いフォルダーに直接上書きしないでください。
- Androidのバッテリー設定を確認：v2rayNGのアイコンを長押しして「アプリ情報」→「バッテリー」を開き、端末に表示される選択肢に従って必要なバックグラウンド動作を許可します。画面ロック中やアプリをバックグラウンドにしたときだけ切断される場合は、まずここを確認してください。
- バックグラウンドでの終了とハンドシェイク失敗を区別：VPNのアイコンが消える、サービスが停止するといった場合は、プロセスまたはシステムによる管理の問題です。サービスが動作中なのにログでハンドシェイクエラーが続く場合は、ノード設定を確認してください。
要点：根拠のある互換性問題に対処する
ポートに到達できない場合は、まずネットワーク経路を修正します。ログにはっきり設定非対応と表示された場合に、クライアントと対応するコアを更新してください。証拠に基づいて更新すれば、新たな要因を持ち込まずに済みます。
7. 一度に一つだけ変更し、再現できる結果を記録
一度に変更するのは一項目だけにし、コアを再起動して同じテスト先URLを使います。3回連続で成功すれば、今回の修正が機能したかを確認する目安にはなりますが、長期的な安定性を保証するものではありません。元のネットワークとアプリを使い、普段利用する時間帯にも様子を見てください。タイムアウト時間を延ばしても、応答の遅さに耐えられるだけで、誤ったSNI、無効な認証情報、閉じたポートは直りません。
| 確認結果 | 次の対応 |
|---|---|
| 同じノードがテザリングでは使えるが、元のネットワークでは失敗する | ノード設定は変更せず、元のネットワークの出口、名前解決、ポート制限を確認する |
| 同じネットワークのほかのノードは使えるが、一つだけ失敗する | サブスクリプションを更新し、サービス提供元に対象ノードの状態と設定を確認する |
| 明示的なプロキシでは使えるが、システムプロキシ経由では失敗する | システムプロキシのポート、アプリのプロキシ設定、ブラウザーの拡張機能を確認する |
| 複数のネットワークで失敗し、設定も確認済み | 個人情報を隠したログとバージョン情報を添えて、サービス提供元にサーバーログの確認を依頼する |
問い合わせの際は、発生日時とタイムゾーン、OSのバージョン、クライアントとコアのバージョン、プロトコルと通信方式に加え、「元のネットワークでは失敗し、テザリングでは成功」のような比較結果を伝えてください。サブスクリプションURL全体を送ったり、ノードのパスワードを公開の掲示板に貼ったりしないでください。「タイムアウト」とだけ表示されたスクリーンショットより、再現可能な一度のリクエストと対応するログのほうが原因の特定に役立ちます。