TCPingはサーバーのポート確認、実接続遅延はプロキシ経由でリクエストを完了できるかの確認、ダウンロード速度測定は継続的な転送能力の確認に使います。「遅延は低いのにWebページが開かない」「遅延は高いのにダウンロードは速い」といった状況に悩むv2rayNユーザー向けに、測定条件をそろえたうえで段階的に切り分け、用途に合うノードを選ぶ方法を解説します。
3つの測定方法で確認できる接続区間
Webページへのアクセスは、サーバーへの接続だけではありません。まず端末からノードの入口に接続し、プロキシコアがプロトコル認証と通信のネゴシエーションを行います。その後、ノードが接続先のWebサイトへ接続し、応答データが返ってきます。TCPing、実接続遅延、ダウンロード速度測定では測る区間が異なるため、数値を同列に並べて順位を付けることはできません。
| 測定方法 | 主な測定対象 | 分かること | 直接は分からないこと |
|---|---|---|---|
| TCPing | 端末からノードのアドレス・ポートへのTCP接続 | 入口のポートに到達できるか、接続におよそどれくらいかかるか | UUIDが正しいか、プロキシ経由でWebサイトにアクセスできるか |
| 実接続遅延 | 測定対象のノード経由でテストURLにリクエストを送信 | プロキシ経路とテスト対象が利用可能か | すべてのWebサイトの応答速度、大容量ファイルの転送速度 |
| ダウンロード速度測定 | ノード経由で測定用サーバーからデータを継続的に受信 | その時間帯・測定対象での転送速度 | 長期的な最低帯域、ゲームの遅延、あらゆるアプリの使用感 |
実接続テストでは、HTTP 204を返すURLなど、容量の小さい応答を使うことがよくあります。実際にプロキシ経由でリクエストを行いますが、Webページ全体を読み込むわけではありません。計測の終了条件、接続の再利用、タイムアウトの扱いはクライアントやコアの実装によって異なります。そのため、「ブラウザーでページが完全に表示されるまでの時間」と単純に捉えることはできません。
TCPingが低くてもノードを使えないのはなぜ？
TCPingは通常、ノード設定にあるサーバーアドレスとポートへの接続を試みます。ノードにドメイン名が設定されている場合は、先に名前解決が必要です。DNSの名前解決時間が表示値に含まれるかどうかは実装によって異なります。TCPingはICMP Pingとは異なり、サーバーからのICMP応答も必要ありません。サーバーで通常のPingが無効でも、TCPポートには正常に接続できる場合があります。
たとえば、入口がTCP 443ポートのVLESSノードでTCPingが45 msと表示されても、分かるのは入口へのTCP接続が確立したことだけです。その後のTLSやREALITYのネゴシエーション、VLESS認証、ノードから接続先Webサイトへの通信が成功することまでは、この数値から判断できません。
- 認証エラー：VMessやVLESSのUUIDが一致しなくても、TCP接続は確立することがありますが、プロキシ経由のリクエストは失敗します。
- トランスポート設定の誤り：WebSocketのパスやHost、TLSの
serverNameが一致していない場合、TCP接続後に問題が発覚することがあります。 - セキュリティ層の設定ミス：REALITYの公開鍵、
shortId、関連設定が一致しない場合は、TCPingを繰り返すのではなく、コアのログを確認してください。 - 測定しているのは入口：CDNを使うノードでは、近くのエッジ入口に接続する場合があります。入口の遅延が低くても、オリジンサーバーへの接続やその後の通信が速いとは限りません。
実接続遅延：まずリクエストの成功を確認し、次にミリ秒を比較
実接続テストでは、テスト用リクエストを測定対象のノード経由で送信します。通常、端末からノードへの接続、プロキシプロトコルの処理、ノードからテスト対象への接続、応答の受信が含まれます。HTTPSのテストURLを使う場合は、接続先とのTLSハンドシェイクも発生します。DNSキャッシュ、接続の再利用、テスト方式によって所要時間は変わります。
したがって、TCPingが45 ms、実接続遅延が260 msでも矛盾ではありません。この差を正確に分解して「サーバーの処理遅延」と見なすことはできず、単純に引き算してノードの負荷が原因だと判断するのも誤りです。テスト対象の場所、ノードの出口経路、ハンドシェイクの回数なども影響します。
TCPingで初期チェック
まず入口への接続性を確認し、複数のノードに共通するネットワークやポートの問題をすばやく特定します。最も低いミリ秒のノードを、普段使いのメインに決めるのは避けましょう。
おすすめの用途：ノードが多く、入口の障害をすばやく調べたい場合
実接続遅延で選別
おすすめ同じテストURLで繰り返し測定します。リクエストが安定して成功し、遅延のばらつきが小さいノードを優先し、実際のWebサイトでも確認しましょう。
おすすめの用途：Web閲覧、APIリクエスト、普段使いのノード選び
ダウンロード速度を確認
候補を絞ってから、データを継続して受信できる速度を測定します。通信量と実際の用途を考慮し、サブスクリプション内の全ノードで何度も最大速度を測る必要はありません。
おすすめの用途：大容量ファイルの転送、動画のバッファリング性能の確認
実接続がタイムアウトしても、ノード全体が使えないとは限りません。テストURLにアクセスできない、接続先が特定の出口を制限している、DNSの名前解決に失敗しているなどの原因が考えられます。まず元のURLでの結果を記録し、安定した小容量の応答を返すURLに変更して再測定してください。比較のたびに接続先を変えると、順位をそろった条件で比べられません。
ダウンロード速度の見方：MB/s、Mbps、瞬間的なピーク値
ダウンロード速度測定では、一定時間に受信したデータ量を確認します。ボトルネックは自宅の回線、Wi-Fi、ノードの共有帯域、出口回線、測定用ファイルのサーバーなど、さまざまな場所にあります。測定値は通信経路全体の結果であり、ノードのサーバー単体の性能を示すものではありません。
まず単位を確認しましょう。10進法では1 MB/sは8 Mbpsです。回線プランではMbps、アプリのダウンロード画面ではMB/sやMiB/sが使われることがあります。以下は説明用のサンプルであり、本サイトでの実測値や特定ノードの性能を保証するものではありません。3つの指標が同時に成り立つ例として示しています。
- 低遅延・低スループット：短いリクエストへの応答は速くても、長時間の接続では速度制限や共有帯域の影響を受けることがあります。
- 高遅延・高スループット：遠距離の通信では往復に時間がかかりますが、接続確立後は高い転送速度を維持できる場合があります。
- 最初は速く、その後に低下：バースト帯域、混雑、サーバー側の制御などが考えられます。瞬間的なピークだけでなく、安定している時間帯の速度を確認しましょう。
平均速度が8 MB/sで15秒間測定した場合、受信データ量は約120 MBです（プロトコルのオーバーヘッドを除く）。複数のノードを測定すれば、その分だけ通信量も増えます。特に従量制のサブスクリプションでは、まず実接続で候補を絞り、2～3個のノードだけ速度を測るのがおすすめです。
v2rayNで再現性のある測定手順を作る
ここではノード一覧から操作する流れを説明します。バージョンによって右クリックメニューの名称は「サーバー遅延をテスト Tcping」「サーバーの実接続遅延をテスト」などと異なる場合があり、設定項目の分類も変更されることがあります。実際の画面で確認してください。測定前にクライアントとコアのバージョンを記録し、アップデート前後の結果を同じデータとして扱わないようにしましょう。
- ネットワーク条件をそろえる：ほかのダウンロード、クラウド同期、システム更新を一時停止します。有線か同じWi-Fiのどちらかに決め、測定中はネットワークを切り替えないでください。
- 測定設定を確認する：「設定」→「パラメータ設定」を開き、現在のバージョンにある遅延テスト用URL、速度測定用URL、タイムアウト、同時実行数に関する設定を確認します。実際の設定値を記録してください。速度測定の項目が独立したグループにある場合は、該当するグループも確認します。
- 少数のノードで初期チェック：ノード一覧から測定対象を選び、右クリックしてTCPingを実行します。次に同じノードで実接続テストを実行し、それぞれの結果を別々に記録します。2種類の遅延値を同じものとして扱わないでください。
- 3回測定する：同じテスト対象で、成功回数と遅延を記録します。たとえば3回の結果が180、185、620 msの場合、中央値は185 msですが、620 msという大きなばらつきも記録に残してください。
- スループットは個別に測定：候補ノードだけを1つずつ選んでダウンロード速度を測ります。測定した時間帯、継続時間、平均速度を記録し、複数のダウンロードで端末の帯域を奪い合わないようにします。
- 実際の用途で確認：候補を使用中のノードに設定し、普段使うWebサイトやアプリを開きます。内蔵テストが成功しても、システムプロキシ、アプリのプロキシ、ルーティング設定が正しいとは限りません。
2段階で確認：ノードの品質と利用環境を切り分ける
条件をそろえた測定環境
- テストURL、ネットワーク、測定時間を固定します。
- 少数のノードで遅延を測り、その後1つずつダウンロード速度を測定します。
- 3回分の結果を記録し、最小値だけを切り取らないようにします。
普段使いの環境
- 普段使っているシステムプロキシとルーティング設定に戻します。
- 対象アプリの通信が、選択したノードを実際に経由しているか確認します。
- よく使う時間帯に、Web閲覧、動画視聴、ダウンロードを再度試します。
条件をそろえた測定はノードの比較に、普段使いの環境での確認は設定と実際の使用感の確認に役立ちます。互いに代用はできません。
内蔵テストは成功するのにブラウザーが遅い：プロキシ経路を確認
v2rayNのノードテストとブラウザーでのアクセスは、必ずしも同じ設定経路を通るわけではありません。ノードテストでは通常、測定対象のノードを経由する接続が使われます。一方、普段のアプリ通信はシステムプロキシ、アプリ独自のプロキシ設定、routingルール、DNSの動作にも左右されます。Webサイトへの通信がルールによって直結に振り分けられている場合、ノードを切り替えてもアクセス速度が変わらないことがあります。
個別に確認する場合は、ローカルのSOCKS入口を明示して指定できます。以下のコマンドは、127.0.0.1:10808が現在利用できるSOCKSまたは互換性のある混合インバウンドであり、画面上で対象ノードを選択済みであることを前提としています。10808はこの例で使うポート番号で、すべての環境で使えるとは限りません。ローカルの待受ポートが異なる場合は、コマンド内のアドレスを変更してください。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://www.example.com/- このコマンドは、
curlが利用できるLinuxやmacOSのターミナル向けです。Windows PowerShellではcurl.exeを使い、出力先の/dev/nullをNULに置き換えてください。 socks5hは、接続先のドメイン名をSOCKSプロキシ側に渡す指定です。端末側の名前解決による差を抑えられますが、実際にどこで名前解決するかはコアやルーティング設定によって異なります。time_totalは、このコマンドの開始から転送終了までにかかった合計時間です。v2rayNの実接続遅延とは異なり、サーバーの処理時間だけを示すものでもありません。- 例の接続先は、リクエストの確認用です。結果を比較するには、同じ安定した接続先を使い続けてください。小さなページの応答から大容量ファイルのダウンロード速度を推定することはできません。
プロキシ入口を明示すると、システムプロキシが適用されているかという疑問は切り分けられますが、コアのroutingを自動的に回避するわけではありません。通信経路に疑問がある場合は、アクセス時のログで接続先、適用されたルール、アウトバウンドのタグを確認してください。ログを共有する前に、サブスクリプションURL、認証情報などの機密情報を隠してください。
速度測定でよくある質問：症状から原因を絞り込む
TCPingは数十ミリ秒なのに実接続がタイムアウトします。ノードを変更すべきですか？
まずノード一覧から実接続テストをもう一度行い、その時刻のコアのログを確認してください。認証やハンドシェイクのエラーがある場合は、UUID、TLS、REALITY、トランスポート設定を確認します。テストURLだけが失敗する場合は、安定した別の接続先で再測定してから判断してください。
すべてのノードが同じ時間帯に測定できません。サブスクリプションが無効になったのでしょうか？
まず、利用できることが分かっているノード1つだけに絞り、同時実行数を減らします。端末のネットワーク、テストURL、コアが正常に起動しているか確認してください。原因が分かるまでは、サブスクリプション全体を何度も削除して再インポートしないようにしましょう。
ダウンロード速度は速いのに、Webページの表示が遅いのはなぜですか？
大容量ファイルの転送と、短い接続を何度も行う通信では負荷のかかり方が異なります。まず実接続遅延を複数回測ってばらつきを確認し、ブラウザーのDNS、ルーティング、Webサイトのサードパーティーリソースも調べてください。同じページで再測定し、異なるサイトの読み込み時間を比べないようにしましょう。
「-1」やタイムアウトと表示されるのは、遅延が非常に大きいという意味ですか？
通常は、遅延がマイナスなのではなく、測定に失敗したと考えてください。タイムアウト設定とログを確認してから、個別に再測定します。失敗時の表示はバージョンによって異なるため、ステータスの文言も確認し、正常なミリ秒値と一緒に平均しないでください。
常に最も遅延が低いノードを選ぶべきですか？
まず成功率とばらつきを比較し、次に用途に合うかを確認してください。Web閲覧では実接続が安定したノードを優先し、大容量ファイルの転送では継続的なスループットを比較します。普段使う時間帯にも少なくとも1回は測り、動作確認済みの予備ノードを残しておきましょう。
ノードを選ぶときは、リクエストが成功すること、結果が安定していること、実際の用途で使えることを先に確認し、単独の数値が低いか高いかは最後に見ましょう。テスト対象、ネットワーク、時間帯、単位を記録しておけば、速度低下がノード、接続先サーバー、端末環境のどこに起因するか判断しやすくなります。