v2rayNGにノードを追加済みなのに、接続がタイムアウトする、実接続テストに失敗する、ブラウザーでサイトを開けない場合に役立ちます。まず設定を変更せず、同じノードでネットワークを切り替えて比較します。続いて時刻、サブスクリプション、通信方式、証明書を確認し、最後にサーバーの待ち受け状態とログを調べます。原因を混同しないよう、一度に変更する項目は一つに絞りましょう。
1. まずタイムアウトが発生する段階を確認
v2rayNGはAndroid向けクライアントです。この記事ではXrayコアを使う設定を前提に説明します。画面上の接続アイコンはローカルサービスの起動を示すもので、リモートノードとのハンドシェイク完了を意味しません。ノード一覧のTCPテスト、実接続テスト、ブラウザーでのアクセスは、それぞれ確認する段階が異なるため、互いに代用できません。
メイン画面で対象ノードを選択してサービスを起動し、メニューから「ログ」を開きます。失敗を一度再現し、発生時刻を記録してください。メニュー名はバージョンによって異なる場合があります。テストの項目は通常、メイン画面のメニューにあります。エラーを保存する際は前後数行も残し、サブスクリプションURL、ユーザーID、パスワードは隠してください。
| 結果 | わかること | 次に確認すること |
|---|---|---|
| TCPテストに失敗 | 接続先アドレスとTCPポートに一時的に到達できない状態です。UDPのみの通信方式の判定には使えません。 | ネットワーク、ドメイン名の解決、ポートを確認 |
| TCPテストは成功、実接続テストは失敗 | ポートから応答はありますが、プロキシのハンドシェイクまたはテストリクエストが完了していません。 | プロトコル、TLS、通信設定を確認 |
| 実接続テストは成功、一部のアプリで失敗 | テスト先に接続できても、すべてのアプリの通信がプロキシ経由とは限りません。 | アプリごとのプロキシ設定、ルーティング、アプリ側の設定を確認 |
| サブスクリプションの更新に失敗 | サブスクリプション内容の取得リクエストに失敗しています。 | サブスクリプションURLを個別に確認し、ノードが無効だと決めつけない |
2. ローカルネットワーク：同じノードでWi-Fiとモバイルデータを比較
まずv2rayNGを停止し、ブラウザーから普段直接アクセスできるサイトを開けるか確認します。公衆Wi-Fiでは、端末に表示される認証ページでログインが必要な場合があります。認証が済んでいないと、プロキシ接続も確立できません。次にノードと設定は変えず、Wi-Fiとモバイルデータでそれぞれサービスを起動してみてください。
- Wi-Fiだけ失敗する場合：ルーターのインターネット接続状態、認証ページ、Wi-Fi側のDNSを確認します。モバイルデータで正常なら、ノードのUUID、パスワード、通信パスは変更しないでください。
- どちらのネットワークでも失敗する場合：正常に使えると確認済みの別ノードと比較します。すべてのノードが同時に失敗するなら、端末のVPN状態、時刻、DNSを優先して確認します。一つのノードだけ失敗する場合は、そのノードの設定を確認してください。
- 起動直後に停止する場合：AndroidのVPN接続許可を確認し、システムのVPN枠を使用している他のサービスを停止します。サービスの起動失敗と、リモート接続のタイムアウトは別の問題です。
- 画面ロック後だけ切断される場合：システムの「設定」→「アプリ」→「v2rayNG」からバッテリー関連の項目を開き、バックグラウンド動作を許可します。設定画面の場所はメーカーによって異なるため、実際の画面で確認してください。
システムの「設定」→「ネットワークとインターネット」→「VPN」で、常時接続やVPN未接続時の通信をブロックする設定も確認します。以前のVPN設定が残っていると、比較用の直接接続まで遮断されることがあります。確認後は元のセキュリティ設定に戻し、必要な保護機能を長時間無効にしないでください。
3. 端末の時刻とサブスクリプション：期限切れの設定を確認
Androidの「設定」→「システム」→「日付と時刻」で、日時とタイムゾーンの自動設定を有効にします。一部の端末では「その他の設定」にあります。表示される日時が正しいことを確認したら、v2rayNGを停止して再起動してください。時刻のずれは証明書の有効期限判定やVMess認証に影響する場合があります。
サブスクリプションのリンクを開けても、ノードが有効とは限りません。サブスクリプション提供元の管理ページにログインし、有効期限、通信量の上限、ノード変更のお知らせを確認します。v2rayNGの「サブスクリプショングループ設定」で配信元URLを確認した後、メイン画面に戻って更新してください。バージョンによって更新項目は「サブスクリプションを更新」や「現在のグループを更新」などと表示されます。
- 更新前に現在の設定を控えておき、更新後は対象ノードを選び直してください。置き換えられた古い項目をテストし続けるのを防げます。
- サブスクリプションの取得にプロキシが必要な場合は、実際に使える別のノードで更新してください。接続できないノードで同じ配信元を更新しようとすると、処理がループするおそれがあります。
- インポート結果にサーバーアドレス、ポート、プロトコル、認証情報が含まれているか確認します。ログイン画面やエラーページに戻るリンクは、有効なサブスクリプションではありません。
- サブスクリプションURL全体を、見知らぬオンライン変換サイトに入力しないでください。URLにはアクセス認証情報が含まれていることが多く、取り扱いには注意が必要です。
4. 通信設定：アドレス、ポート、Host、パスを個別に確認
ノード一覧で対象の編集アイコンをタップし、サーバーまたは提供元から提示された元の設定と一つずつ照合します。ノード名に通信方式が記載されていても、編集画面の設定と一致するとは限りません。サーバーアドレスは接続先を、ポートは接続する入口を指定します。通信方式は、その後のトンネル確立方法を決めます。
ここで示すのはプロトコルのポートに関する知識であり、推奨設定ではありません。ノードが別のポートを使っている場合、クライアントだけを443に変更しても接続できません。サーバーの待ち受け、ファイアウォール、転送先の入口をすべて合わせる必要があります。DNSでアドレスを取得できても、ノードのポートに到達できる証明にはなりません。
- WebSocket：通信方式、Host、パスを確認します。パスの大文字・小文字、先頭のスラッシュ、クエリパラメーターは、サーバー側の指定と一致させてください。リバースプロキシの転送設定が誤っていても、ハンドシェイクに失敗します。
- gRPC：サービス名と、提供元から指定された関連オプションを確認します。WebSocketのパスをサービス名の欄に入力しないでください。
- プロトコル認証：VMessとVLESSのユーザーID、TrojanとShadowsocksのパスワードが、サーバー側の設定と一致しているか確認します。通信方式を変更しても、認証情報の誤りは解決しません。
- ドメイン名の解決：ログにノードのドメイン名を解決できないと表示されたら、まず端末側の名前解決経路を確認します。比較のためにサーバーで確認済みのIPアドレスを一時的に使う場合も、TLSサーバー名は正しく設定してください。
ポイント：TCP接続を確認してからハンドシェイク設定を調べる
同じアドレスとポートに、どちらのネットワークからもTCP接続できない場合は、サーバーの待ち受け状態とネットワーク経路を先に確認します。TCP接続は成功するのにプロキシリクエストが失敗する場合は、認証、通信方式、TLSを順に確認してください。DNS、ポート、パスを一度に変更しないでください。
5. TLSとログ：エラーから接続段階を特定
TLSのサーバー名は通常、SNIと証明書名の検証に使われます。WebSocketのHostとは別の設定で、実際に接続するIPアドレスとも一致するとは限りません。3つの値が同じ場合もありますが、名前が似ているからといって相互に置き換えないでください。REALITYを使うノードでは、サーバーから指定された公開鍵、short ID、サーバー名も確認します。通常のTLSノードと同じ感覚で変更してはいけません。
エラー：i/o timeout
原因と対処：ネットワークの読み書きが、ある段階でタイムアウトしています。この行だけでは故障箇所を特定できません。ログの前後にある接続先アドレスと処理段階を確認し、ネットワーク側の状態と同時刻のサーバーログを比較してください。
エラー：connection refused
原因と対処：接続先ホストまたは中継機器が接続を明示的に拒否しています。ポートを確認し、サーバーのプロセスが待ち受け中か、接続を拒否するルールがないか調べてください。
エラー：no such host
原因と対処：ドメイン名を解決できていません。エラーの対象がノードのドメイン名かアクセス先かを確認し、スペル、DNS設定、該当ドメインのレコードを調べてください。
エラー：x509: certificate has expired or is not yet valid
原因と対処：証明書の有効期間と現在時刻が一致していません。まずスマートフォンの時刻を合わせます。それでも解決しない場合は、サーバー管理者に証明書の更新状況と実際に読み込まれている証明書を確認してもらってください。
エラー：websocket: bad handshake
原因と対処：サーバーが想定したWebSocketへのアップグレード応答を返していません。パス、Host、リバースプロキシの転送ルールを確認し、応答ステータスコードも手がかりに調べてください。
6. サーバー側：待ち受け、許可ルール、転送経路を確認
他者から提供されたノードを使っている場合は、失敗時刻、ネットワークの種類、クライアントのバージョン、個人情報を隠したエラー内容を管理者に伝えてください。自分でサーバーを管理している場合は、まず稼働状態を確認し、次にOSのファイアウォール、クラウドのセキュリティグループ、コンテナのポートマッピング、リバースプロキシを調べます。クライアントがタイムアウトしても、サーバーアプリケーションのログに記録が残るとは限りません。通信がプロセスに届いていなければ、アプリ側に記録されないのが自然です。
以下はLinuxサーバーで状態を確認するための読み取り専用コマンドです。まず実際のサービスユニットを一覧表示してください。後の2つのコマンドは、systemdサービス名がxrayであることを確認できた場合に限り実行します。コンテナや別のサービス名で運用している場合は、該当するプロセスとコンテナのログを確認してください。
ss -lntp
ss -lnup
systemctl list-units --type=service --all
systemctl status xray --no-pager
journalctl -u xray --since "10 minutes ago" --no-pager- 実際に待ち受けているポートとアドレスを確認します。バックエンドが
127.0.0.1だけで待ち受け、同じホスト上のリバースプロキシから接続する構成は正常な場合があります。クライアントがバックエンドへ直接接続するなら、対応する外部向けの入口が必要です。 - クラウドのセキュリティグループとホストのファイアウォールを順に確認します。許可ルールは実際のプロトコルと接続先ポートに合わせてください。ルール名だけでは判断できません。
- ドメインのAレコードとAAAAレコードを確認します。古いアドレスや未設定のIPv6接続先に解決される場合は、該当レコードまたはネットワークを修正してください。クライアントを何度も再インストールしても解決しません。
- スマートフォンからテストを実行しながら、入口側とバックエンド側のログを確認します。入口にリクエストがあり、バックエンドに記録がない場合は、リバースプロキシを重点的に調べてください。バックエンドがリクエストを受信して認証に失敗する場合は、ユーザーの認証情報を確認します。
7. よくある質問と確認のまとめ
遅延の数値は正常なのに、Webページを開けないのはなぜ？
まず、その数値がTCPテストと実接続テストのどちらの結果か確認してください。TCPテストでわかるのはポートから応答があることだけです。実接続テストでも、指定されたテスト先への接続しか確認できません。サービスを起動した状態でブラウザーのリクエストログを確認し、アプリごとのプロキシ設定でブラウザーが除外されていないか、ルーティングで接続先が想定したアウトバウンドに送られているかを調べます。
サブスクリプションの更新がずっとタイムアウトします。ノードをすべて削除する必要がありますか？
既存の設定は残したまま、サブスクリプションURLと有効期限を確認してください。直接接続で取得できない場合は、別の利用可能なノード経由で更新を試します。提供元がURLを変更した場合は、該当するグループの設定を修正してください。ノードをすべて削除しても、サブスクリプションサーバーに接続できない問題は解決しません。
同じノードがパソコンでは使えるのに、スマートフォンでは使えないのはなぜ？
まず2台の端末を同じネットワークに接続し、v2rayNとv2rayNGのサーバーアドレス、ポート、通信方式、SNI、認証情報を比較します。同じ名前の古いノードではなく、両方で同じ設定をテストしていることを確認し、それぞれのコアのバージョンも記録してください。設定項目の互換性に問題がある場合は、具体的なエラーに応じて対処します。
接続タイムアウトまでの時間を延ばせば、復旧しますか？
通信経路でハンドシェイクが完了するものの、時間がかかっている場合に限り、待ち時間を延ばすことで改善する可能性があります。接続先が待ち受けていない、証明書に誤りがある、認証情報が一致しないといった問題は解決しません。まずログで失敗した段階を確認し、待ち時間を延ばすだけで直ったと判断しないでください。
最後に、クライアントとコアのバージョン、テスト時刻、ネットワークの種類、ノード更新の有無、最初に表示されたエラー、変更内容を記録しておきましょう。効果のなかった変更は元に戻してから再テストします。この情報があれば、管理者が原因を特定しやすくなり、次回も最初から推測し直す必要がありません。接続とルーティングの基本はトラブルシューティングと高度な設定もご覧ください。