ノードに接続できないタイムアウトの切り分け手順：サブスクリプション、時刻、ポート、プロトコル設定を順に確認

ノードにタイムアウトが表示されても、プロトコル自体が無効とは限りません。同じ赤い遅延表示でも、サブスクリプションに古いアドレスが残っている、システム時刻がずれている、ドメイン名の解決に失敗している、ローカルの待受ポートが競合している、通信層の設定がサーバーと一致していないなど、さまざまな原因が考えられます。ノードを何度も切り替えるだけでは原因が混在し、ログも大量の再試行で上書きされます。

より安定した方法は、切り分けの順序を固定し、各回で変更する変数を1つだけにして、クライアントのバージョン、テスト時刻、ネットワーク種別、コアのログを記録することです。この記事はデスクトップ版の v2rayN と、Android で Xray コアを使用する v2rayNG、v2fly コアを使用する v2flyNG に対応しています。メニュー名はマイナーバージョンによって変わる場合がありますが、サブスクリプション、時刻、ポート、ネットワーク、プロトコルの5層で判断する点は変わりません。

まずタイムアウトが発生した区間を特定する

プロキシ接続は少なくとも、アプリケーション、ローカルプロキシの待受、ルーティングルール、リモートへのネットワーク接続、プロトコルハンドシェイクを経由します。ブラウザーに「接続がタイムアウトしました」と表示されるだけでは、どの区間で失敗したか分かりません。まずクライアントのログを開き、再現可能なリクエストを1回実行します。たとえば他のダウンロードを停止して固定したウェブページだけを開き、リクエスト前後30秒のログを保存します。

遅延テストも種類を区別する必要があります。TCP プローブで分かるのは、リモートのアドレスとポートに接続できるかどうかだけで、VLESS や VMess のハンドシェイク成功を意味しません。実測遅延は完全なプロキシ経路を通るため、実際のアクセスに近い結果になります。TCP 遅延が86msなのに実測遅延が継続してタイムアウトする場合は、まずプロトコル、セキュリティ層、通信パラメータを確認し、いきなりローカル DNS を変更しないでください。

ステップ1：サブスクリプションを更新し、ノードが有効か確認する

サブスクリプションはノードパラメータの情報源です。サーバー側でドメイン、入口ポート、UUID、通信パス、セキュリティ層が変更されると、ローカルには古いノードが残ったまま接続だけが継続的にタイムアウトすることがあります。切り分けではノード名が同じかどうかだけでなく、サブスクリプションの最終更新時刻、更新後のノード数、アドレス、ポートの変化を確認してください。

v2rayN ではまず「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、サブスクリプションURLが完全で、グループが有効になっていることを確認します。メイン画面に戻り、「サブスクリプショングループ」→「すべてのサブスクリプションを更新（プロキシを使用しない）」を選択します。現在のネットワークからサブスクリプションを直接取得できない場合は、利用可能と確認済みのノードに接続し、「すべてのサブスクリプションを更新（プロキシ経由）」を使います。2つの方法はどちらか一方だけでテストし、連続操作でエラー発生時の状況を上書きしないでください。

1. 更新前の状態を記録する

   ノード数、サブスクリプションの更新時刻、現在選択中のノードを記録します。例として「24ノード、最終更新 2026-05-27 21:10」のように残すと、更新が実際に行われたか判断しやすくなります。

2. サブスクリプションを更新する

   「サブスクリプショングループ」→「すべてのサブスクリプションを更新（プロキシを使用しない）」を開きます。完了通知が表示されるまで待ち、更新中にクライアントを終了したりネットワークを切り替えたりしないでください。

3. 変化を確認する

   更新前後のアドレス、ポート、ノード総数を比較します。ノード数が24から21に変わった場合は、まず新しいリストを使い、削除されたノードを古いバックアップから復元しないでください。

4. 単一ノードで再テストする

   新しいノードを1つ選び、コアを再起動して3回テストします。各回の間隔は5秒にします。3回ともタイムアウトする場合は、続けて時刻とネットワークを確認し、プロトコルを一括変更しないでください。

ステップ2：システム時刻を同期し、ドメイン解決を確認する

VMess の認証は時間枠に依存し、TLS 証明書の検証もシステムの日付に依存します。端末の時刻が数分ずれていても通常のウェブページは開ける場合がありますが、プロキシのハンドシェイクは失敗します。まずシステムの日時とタイムゾーンの自動設定を有効にし、直ちに同期を実行します。ずれは30秒以内に抑えることを推奨します。90秒を超える場合は、ノードパラメータを調整する前に時刻を合わせてください。

時刻が正確になってから DNS を確認します。ノードアドレスがドメイン名の場合、ローカルで接続可能な IP に解決できなければなりません。ターミナルで OS 標準の名前解決コマンドを実行し、アドレスが返るか、応答にかかる時間を確認します。3回連続で2000msを超える、または解決失敗が断続的に発生する場合、問題はプロトコルハンドシェイクより前にあります。

• システムの日付、タイムゾーン、夏時間のルールが所在地と一致していることを確認します。タスクバーの時と分だけを見て判断しないでください。
• スリープから復帰したパソコンは、時刻を再同期してください。長時間のスリープ後は、時刻サービスの調整が完了していない場合があります。
• ネットワークを変更したらノードのドメイン名を再解決し、無効になったローカルキャッシュの結果を使い続けないでください。
• サブスクリプションURLは開けるのにノードのドメイン名を解決できない場合は、2つのドメインの検索結果を別々に記録し、同じ障害として扱わないでください。

nslookup node.example.net

確認したい状態：
Address: 203.0.113.20
最初の応答：42 ms
連続検索：毎回同じ有効なアドレスが返る

ステップ3：ローカルポート、コアの状態、ファイアウォールを確認する

ノードパラメータが正しくても、まずローカルのコアがプロキシポートの待受に成功している必要があります。v2rayN の一般的な設定では SOCKS ポートに10808を使用し、そこから HTTP ポート10809を割り当てます。実際の値は「設定」→「パラメータ設定」のローカル待受設定を確認してください。ブラウザーが10809を指定していても、クライアントが20809に変更されていれば、リクエストは現在のコアに届きません。

ポートの競合は、古いコアが終了していない、別のクライアントが動作している、システムのスリープ復帰後にプロセスが残っている場合によく発生します。v2rayN のウィンドウを閉じただけではバックグラウンドプロセスが終了したとは限りません。トレイから終了を実行してから再起動してください。切り分け中はクライアントとコアをそれぞれ1つだけにし、複数のプログラムが同時にシステムプロキシを変更しないようにします。

1. コアの動作を確認する

   メイン画面下部の状態表示とログを確認します。起動後に待受成功のメッセージが表示されるはずです。ログが1秒以内に終了する場合は、まずコアの起動エラーを解決します。

2. 待受ポートを照合する

   「設定」→「パラメータ設定」を開き、SOCKS ポート10808と HTTP ポート10809を記録します。ブラウザーや他のアプリケーションには、種類に合ったポートを指定する必要があります。

3. 競合しているポートを解放する

   他のプロキシクライアントと残っているコアを完全に終了してから、v2rayN を再起動します。10808が使用中の場合は20808に変更し、HTTP ポートとアプリケーション側の設定も合わせて変更してください。

4. ファイアウォールを確認する

   現在のコアが、使用中のネットワーク種別で通信を許可されていることを確認します。テスト後は決められたセキュリティポリシーに戻し、関係のないプログラムの受信許可を長期間緩和しないでください。

正常な待受の例：
SOCKS listening on 127.0.0.1:10808
HTTP listening on 127.0.0.1:10809

競合時の例：
failed to listen TCP on 127.0.0.1:10808
bind: address already in use

ステップ4：別のネットワークで回線とノードの障害を切り分ける

サブスクリプション、時刻、ローカルポートに問題がなければ、ノードパラメータを変更せずにネットワークを切り替えます。家庭の固定回線とモバイルホットスポットを比較対象にし、同じノード、同じクライアント、同じテスト先で実測遅延をそれぞれ3回測定します。ネットワークの入口だけを変えることで、問題が現在の回線に集中しているか判断できます。

たとえば家庭のネットワークでは3回ともタイムアウトし、モバイルホットスポットでは118ms、126ms、121msだった場合、ノード設定は少なくともハンドシェイクまで完了できています。家庭ネットワークの DNS、ルーティング、ファイアウォールを重点的に確認してください。両方のネットワークで約10秒後にタイムアウトする場合は、リモートポートに到達できないか、プロトコルパラメータが一致していない可能性が高くなります。

ステップ5：プロトコルと通信パラメータを1項目ずつ照合する

前の4層を確認してから、初めてノード編集画面を開きます。まずプロトコルの種類が VLESS か VMess かを確認し、サーバーから提示されたパラメータと1項目ずつ比較します。UUID は認証識別子なので、経験だけで書き換えないでください。ポートは入口の待受と一致させ、通信方式の TCP、WebSocket、gRPC は相互に置き換えられません。TLS、REALITY などのセキュリティ層もサーバー設定と対応している必要があります。

WebSocket では Host とパスを確認します。パス内のスラッシュや大文字・小文字もルーティングに影響する場合があります。gRPC ではサービス名を照合します。TLS では通常、サーバー名、つまり SNI も確認します。接続先を IP にしても、証明書検証に使う名前はサーバーの要求と一致させる必要があります。REALITY ではサーバー名、公鍵、短い ID を照合し、通常の TLS フィールドをそのまま流用しないでください。

異なるクライアントで再テストする際のポイント

デスクトップ版 v2rayN は、コアの起動、待受、アウトバウンドのログを直接確認するのに適しています。切り分け前に「ヘルプ」→「バージョン情報」でクライアントのバージョンを記録し、ログの冒頭にコアのバージョンも記録します。例：クライアント 7.x、Xray-core 25.x。バージョン番号だけで障害を判断することはできませんが、同じ設定が異なるコア環境で再現するか確認するのに役立ちます。

Android の v2rayNG は Xray コア、v2flyNG は v2fly コアを使用します。同じサブスクリプションを異なるコアのクライアントへそれぞれインポートする方法は、設定の互換性確認に限って利用してください。同じテスト中に通信パラメータまで変更しないでください。モバイルネットワークと Wi-Fi を切り替えた後は、システムが割り当てる DNS や出口経路が変わっている可能性があるため、接続テストを再実行します。

修正後に行う検証の順序

原因を特定した後も、1回だけで検証を終えないでください。まずコアを再起動してローカルポートの待受成功を確認し、次に実測遅延を3回測定します。その後、通常のウェブページとプロキシが必要な対象アドレスを開き、最後に10分待ってもう一度テストします。短時間だけ偶然成功した場合、DNS キャッシュや回線の切り替えがまだ安定していない可能性があります。

最終結果は「クライアントとコアのバージョン、ネットワーク種別、ノードのプロトコル、修正項目、3回の遅延」として記録することを推奨します。例：v2rayN 7.x、Xray-core 25.x、家庭用固定回線、VLESS over WebSocket with TLS、SNI を修正、結果は92ms、95ms、91ms。このような記録は「再インストールしたら直った」より、次回の再現と活用に適しています。

1. コアを再起動する

   ログで10808と10809の両方が正常に待受しており、起動後にポート競合や設定解析エラーがないことを確認します。

2. 3回テストを実行する

   各回の間隔は5秒にします。3回の実測遅延の差が50ms未満なら、現在の接続状態は比較的安定しています。

3. アプリケーションの通信を検証する

   ブラウザー、システムプロキシ、個別設定したアプリケーションを確認し、プロキシの種類とポートがクライアント側と一致していることを確認します。

4. 有効な記録を残す

   エラーが発生した時刻、重要なログ、修正項目を保存し、無効になったサブスクリプションパラメータを長期設定として保存しないでください。