サブスクリプションをインポート済みなのに、v2rayNの実接続遅延テストがタイムアウトする、ブラウザーでページを開けない、またはコアの起動に失敗する場合に役立つ内容です。まずローカルのリスニングを確認し、次にサブスクリプションとノード、最後にシステムプロキシとネットワーク制限を調べます。一度に変更する項目は一つに絞り、コマンドの出力と同時刻のログから原因の層を特定しましょう。最初からクライアントを再インストールする必要はありません。
まず切り分ける：ポートに接続できない、ノードがタイムアウトする、ブラウザーがプロキシを使っていない
現在の設定はそのまま残し、選択中のノード、テスト時刻、エラー内容を記録します。一括速度テストは止め、ノードを一つ選んで一度だけ再現したら、メイン画面のログ欄で該当する記録を確認してください。一括テストでは多数の接続が同時に発生するため、別のノードのエラーを今回の問題と取り違えやすくなります。
v2rayNはGUIクライアントで、実際の接続は選択中のコアが処理します。画面が開きサブスクリプションが表示されても、コアが起動しているとは限りません。リストの遅延値も、テスト方式を区別して確認しましょう。TCP接続テストで分かるのは、対象ポートに接続できる可能性までです。実接続テストでは、プロキシプロトコルやハンドシェイク、テスト先URLも関係します。
| 症状 | 優先して確認する項目 | この症状だけでは判断できないこと |
|---|---|---|
| すべてのノードがすぐに失敗し、ログにリスニング失敗と表示される | ローカルポート、コアプロセス、設定の読み込み | サブスクリプション全体が無効とは限らない |
| TCPテストでは数値が表示されるが、実接続テストはタイムアウトする | プロトコル設定、TLS、テスト先URL、サーバー側の外向き接続 | TCPで接続できても、プロキシが使えるとは限らない |
| 実接続テストは成功するのに、ブラウザーでは失敗する | システムプロキシ、ブラウザー独自のプロキシ、ルーティングルール | ブラウザーで失敗しただけでは、ノードがオフラインとは判断できない |
| 特定のノードだけが継続してタイムアウトする | そのノードのアドレス、ポート、アカウント、サービスの稼働状況 | 通常はシステム全体の設定変更から始める必要はない |
第1段階：システム時刻、ローカルポート、コアの起動を確認する
以下では、Windows版v2rayNを例に説明します。画面の表記はバージョンによって異なる場合があります。ポートは実際の設定値を使ってください。まず「設定」→「パラメーター設定」でローカルのリスニング設定を開き、SOCKSまたは混合リスニングのポートを確認します。リモートノードのサーバーポートをシステムプロキシに入力しないでください。
-
システム時刻を同期する
Windowsの「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にして「今すぐ同期」をクリックします。日付とタイムゾーンも確認してください。時刻が大きくずれていると、証明書の有効期間判定や一部のプロトコル認証に影響することがあります。タイムゾーンが異なる表示だけで、システム時刻が誤っているとは限りません。
-
リスニングポートを確認する
v2rayNの「設定」→「パラメーター設定」で、リスニングアドレスとポートを確認します。この記事では、SOCKSまたは混合接続の入口が
127.0.0.1:10808で待ち受けているものとします。画面に別のポートが表示されている場合は、後述のコマンドも合わせて変更してください。 -
ポートを使用しているプロセスを特定する
PowerShellで次のクエリを実行します。リスニング状態とPIDを確認したら、タスクリストでプロセスを照合してください。現在使っているコアのリスニングであれば通常は問題ありません。古いクライアントのインスタンスや別のプログラムが使っている場合は、競合するプログラムを正常終了するか、現在のリスニングポートを未使用の番号に変更します。
-
コアを再読み込みする
設定を保存し、ノードを選び直してログを確認します。必要に応じてクライアントを終了して再起動してください。ポートを変更した場合は、ブラウザー独自のプロキシ設定やコマンドラインで使うポートも更新が必要です。リスニングしていない場合は、リモートノードのテストを続けず、まずコアの起動エラーを解決してください。
Get-NetTCPConnection -State Listen -LocalPort 10808
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 1234"最後の行にある1234はPIDの例です。最初の2つのコマンドで調べたプロセス番号に置き換えてください。netstatの出力ではローカルアドレスとリモートアドレスを区別し、状態がLISTENINGであることを確認します。10808という数字が見えただけで、ポートが競合していると判断しないでください。見覚えのないシステムプロセスを強制終了するのも避けましょう。
第2段階：リストにノードが残っているかではなく、サブスクリプションの更新成功を確認する
サブスクリプション一覧には、前回保存した内容が表示されている場合があります。更新に失敗しても古いノードは残るため、「ノードが何十件もある」ことはサブスクリプションが現在有効である証拠にはなりません。まず「サブスクリプショングループ」→「サブスクリプショングループの設定」でグループのURLを確認し、「サブスクリプショングループ」から更新を実行して、結果と更新時刻を確認してください。
- 401または403が返る場合：サブスクリプショントークン、アクセス権限、サービス提供側の制限を優先して確認します。このステータスコードは、リクエストが何らかのHTTPサービスに到達したことを示します。ローカルポートが起動していないだけの問題ではありません。
- Webページやログイン画面が返る場合：アカウント管理ページではなく、サブスクリプションURLをコピーしたか確認します。ページが「正常に開けた」ことは、クライアントが解析できるノード設定を取得できたことを意味しません。
- リクエストがタイムアウトする場合：サブスクリプションのドメインへのアクセスにプロキシが必要かを確認します。利用できるノードがある場合は、メニューからプロキシ経由での更新を試せます。すべてのノードが使えない状態で何度もプロキシ経由の更新を選ぶと、依存関係が循環します。
- 更新に成功してもノードが使えない場合：サービス提供元のアカウント期限や通信量、ノードの移転状況を確認します。サブスクリプションをダウンロードできることと、ノードで認証できることは別の段階です。
更新前に既存の設定をバックアップし、テストのためにすべてのグループを削除しないでください。更新後にリストが空になった場合は、まず応答内容と形式の互換性を確認します。システムプロキシを調整しても、誤ったサブスクリプションの内容が有効なノード設定に変わることはありません。
第3段階：ノード設定を確認し、ログから接続とハンドシェイクの失敗を見分ける
現在のノードをダブルクリックして編集画面を開き、サービス提供元の案内にあるパラメーターと一つずつ照合します。まずアドレスとポート、次にプロトコルとトランスポート層を確認してください。ノード名からプロトコルを推測したり、利用できるノードのTLSやトランスポート設定をほかのノードに一括適用したりしないでください。
- VMess：UUID、暗号化方式、サーバーが求めるその他の項目を確認します。古い設定を移行する場合は、サーバーの最新の案内に従って再インポートしてください。認証パラメーターをむやみに変更して試さないでください。
- VLESS：UUID、フロー制御の設定、必要なTLSまたはREALITYのパラメーターを確認します。REALITYを使うノードでは、サービス提供元が指定する公開鍵、Short ID、サーバー名などの項目も一致させる必要があります。
- TLS：サーバー名がサービス提供元の指定と一致しているか確認します。ノードの接続先アドレスと証明書に対応するドメイン名は異なる場合があるため、機械的に同じ値へ変更しないでください。
- WebSocket：トランスポートの種類、パス、Hostを確認します。パスは大文字と小文字を区別することが多く、先頭のスラッシュが抜けていたりHostが誤っていたりすると、ハンドシェイクに失敗することがあります。
- コアの対応状況：現在のコアが、ノードで必要なプロトコルとトランスポートの組み合わせに対応しているか確認します。v2rayNはクライアント名、V2RayとXrayはコアのプロジェクト名です。これらを同じ種類のバージョンとして扱わないでください。
エラー：bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因：現在のリスニングアドレスとポートがすでに使用されている可能性があります。対処法：リスニング中のプロセスを調べ、重複したインスタンスを終了するかローカルポートを変更してから、コアを再読み込みします。
エラー：dial tcp: lookup
原因：アドレス解決エラーでよく見られるログの一部です。ログの完全な行には、通常ドメイン名と具体的なエラーも記録されています。対処法：サーバーアドレスを確認し、システムの名前解決コマンドでドメインをテストします。そのうえでコアのDNS設定を確認し、実際にどの経路で名前解決されているかを調べてください。
エラー：i/o timeout
原因：ネットワークの読み込みまたは書き込み処理のいずれかがタイムアウトした状態です。このエラーだけでサーバーが停止しているとは判断できません。対処法：同じ行または前後のログから接続先アドレスと処理段階を確認し、サーバーポートとプロキシ経由の接続先URLをそれぞれテストします。
エラー：x509: certificate has expired or is not yet valid
原因：システム時刻が異常か、サーバー証明書が有効期間外です。対処法：まず時刻を同期してください。時刻が正しいのに再発する場合は、サービス提供元に証明書の更新を依頼します。証明書検証の無効化を通常の解決策にしないでください。
サーバーのドメイン確認にはPowerShellのResolve-DnsName、ポート確認にはTest-NetConnectionを使えます。引数にはノード編集画面に表示される実際のサーバーアドレスとリモートポートを指定し、ローカルの10808は指定しないでください。システムの名前解決に成功しても、確認できるのはシステム側の経路だけです。コアが独自のDNSを使う場合は、コアのログも確認してください。
判断の目安：TCPで接続できたら、次はハンドシェイクの設定を確認する
サーバーポートのテストには成功するのに、プロキシリクエストが安定して失敗する場合は、認証、TLS、トランスポート層の設定を優先して確認します。ローカルポートの設定を何度も変える必要はありません。TCP接続が成功しても、サーバー側の帯域制限やネットワーク途中の干渉は否定できませんが、調査範囲を絞ることはできます。
第4段階：システムプロキシ設定を介さず、プロキシの入口を個別に検証する
コアのリスニングが正常であることを確認したら、PowerShellで次のコマンドを実行します。ローカルのSOCKS入口に明示的に接続するため、ブラウザーがシステムプロキシを参照しているかどうかに左右されません。ここで使う10808は、SOCKSに対応すると確認済みのポートである必要があります。HTTP専用の入口を使う場合は、後述のHTTP形式を使い、実際のポートを指定してください。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 --head https://example.com/socks5hは接続先ドメインの名前解決をプロキシ側に任せる指定で、接続先サイトを本機で名前解決する影響を減らせます。HTTPのステータス行が返れば、通常はこの入口経由でHTTP応答を受け取れたことを示します。ただし、リクエストがどのルールに振り分けられたかはログで確認してください。クライアントに明示的に接続しても、最終的にリモートプロキシ経由で通信するとは限りません。
curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 5 --max-time 15 --head https://example.com/2つ目のコマンドはHTTP入口の例にすぎません。10809はすべてのバージョンにある固定ポートではありません。その入口を有効にしていない場合は、例をそのまま使わないでください。テスト先には、現在のネットワークやサービスの利用条件でアクセスできるサイトを選びます。1つのURLで失敗したら、別の独立したサイトでも確認し、接続先サービス側の障害をノードの問題と取り違えないようにしましょう。
- コマンドは成功するがブラウザーでは失敗する場合：v2rayNのメイン画面下部にある「システムプロキシ」で「システムプロキシを自動設定」を選びます。次にWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、現在のローカル入口が指定されているか確認してください。ブラウザー独自のプロキシを設定している場合は、そちらも確認します。
- ルーティングモードでのみ失敗する場合：テスト先を確実にプロキシ経由で送るルールを一時的に使って比較し、確認後に元のルールへ戻します。ルールの優先順位、ドメインのマッチ条件、最終的な出力先をログで確認してください。モード名だけでは判断できません。
- ローカルへのリクエストがすべて拒否される場合：第1段階に戻り、コアが引き続きリスニングしているか確認します。ブラウザーにプロキシ接続エラーが表示されていても、リモートノードまで接続が進んでいるとは限りません。
- システムプロキシは正常なのに一部のアプリで失敗する場合：そのアプリがシステムプロキシを参照していない可能性があります。まずアプリ独自のネットワーク設定を確認してください。TUNは別の通信取り込み方式です。基本の接続を確認できていない段階で、追加で有効にするのは避けましょう。
それでもタイムアウトする場合：ネットワークを比較し、必要な情報を記録して調査を終える
4段階の確認後、同じPCと同じノードを使い、現在のネットワークとスマートフォンのテザリングでそれぞれテストします。ネットワークだけを切り替え、DNS、ノード設定、ルーティングモードを同時に変更しないでください。特定のネットワークでだけ失敗する場合は、そのネットワークのDNS、外向き接続の制限、認証ページ、回線品質を優先して確認します。どのネットワークでも同じノードだけ失敗する場合は、サービス提供元に問い合わせてください。
| 記録項目 | 記録する内容 |
|---|---|
| クライアントとコア | クライアントの実際のバージョン、コアの種類とバージョンを記録する。「最新版」だけでは不十分 |
| 発生時刻 | タイムゾーンを添えて分単位まで記録し、サーバーログとの照合に役立てる |
| ローカルでの確認結果 | リスニングポート、プロセス名、プロキシを明示したコマンドの実行結果 |
| ネットワークの比較 | 現在のネットワークとテザリングで再現するか、特定のノードだけ失敗するか |
| エラーの前後関係 | 同じリクエストの前後数行のログを残し、認証情報とサブスクリプショントークンは隠す |
まとめ：各手順で再現可能な結果を記録する
ローカルでリスニングしていること、サブスクリプションの更新が有効なこと、ノード設定が一致していること、プロキシを明示したリクエストが成功すること。この4点は、単独の遅延値よりも原因の判断に役立ちます。接続が復旧したら、一時的に変更したテストルールやネットワーク設定を元に戻し、動作する設定を保存してください。テスト値をさらに下げるために、安定した経路を変更し続ける必要はありません。