遅延テストの見方：ping・実接続遅延・ダウンロード速度の違いと使い分け

3種類のテストは同じ経路を測っていない

ノード一覧に40 ms、120 ms、80 Mbit/sが同時に表示されても矛盾ではありません。3つの数値は異なる処理を示しているためです。pingは通常、サーバーアドレスへICMPパケットを送り、往復時間を記録します。実接続遅延では、クライアントがVMessやVLESSのノードを通じてプロキシ接続を確立し、テスト対象へアクセスします。ダウンロード速度は一定量のデータを継続的に転送し、利用可能なスループットを確認します。

ICMP pingが確認できる範囲は最も狭いものです。ローカルネットワークから対象アドレスまでの基本的な往復時間やパケットロスは分かりますが、ノードのポートが開いているか、TLS、WebSocket、gRPC、Reality、プロキシプロトコルのハンドシェイクが成功するかは確認できません。アドレスへのpingが38 msでも、TCP 443への接続、TLSネゴシエーション、VLESSチャネルの確立を終えて最初のWebリクエストを送るまでに150 msを超えることがあります。

実接続遅延は、普段Webページを開く際の待ち時間により近い指標です。v2rayNのようなクライアントは通常、ローカルプロキシを起動し、指定したノード経由でテストアドレスへリクエストを送り、接続確立から応答取得までの時間を測定します。ローカルのSOCKSインバウンド、コアの処理、プロキシプロトコルのハンドシェイク、サーバー側のアウトバウンド、対象サイトの応答、一部のDNS解決時間が含まれる場合があるため、pingよりもノードが実際に使えるかを反映しやすい指標です。

pingは低いのにWebページの表示が遅いのはなぜか

最もよくある原因は、pingがプロキシ接続の確立処理を経由しないことです。サーバーアドレスへのICMP往復が45 msだとしても、TCP接続の確立には少なくとももう1往復必要です。TLSを使用する場合はネゴシエーションが加わり、WebSocketではHTTPアップグレードの完了も必要です。その後、プロキシコアが対象サイトへのアウトバウンド接続を確立します。各段階で待ち時間が増える可能性があります。

2つ目の原因は、pingの対象とWebページの対象が異なることです。pingが測るのはクライアントからノード入口までですが、Webページの表示にはノードから対象サイトまでの経路も含まれます。あるノードがローカルから近くても、サーバーから対象サイトまで遠回りすれば、実接続遅延は高くなります。反対に、入口へのpingがやや高いノードでも、サーバー側の出口が安定していれば、Webページの読み込みやダウンロードは快適な場合があります。

3つ目の原因は、ICMPとTCP・UDPで処理ポリシーが異なることです。サーバーがICMP応答の頻度を制限したり、まったく応答しなかったりしても、443などのノードポートは正常に動作する場合があります。したがって、pingのタイムアウトは今回のICMPテストが応答を得られなかったことを示すだけで、VMessやVLESSの設定が無効だと単独で判断することはできません。

• VMessとVLESSのプロトコル名だけで遅延が決まるわけではありません。通常はサーバーの場所、伝送層、混雑状況、出口経路のほうが大きく影響します。
• WebSocket、gRPC、通常のTCPではハンドシェイクの流れが異なるため、1回の測定結果だけで伝送方式の優劣を決めないでください。
• ルーティングを分割している場合は、測定先が本当に現在のノードを経由しているか確認してください。そうしないと、直接接続の結果を測っている可能性があります。

実接続遅延とダウンロード速度をどう組み合わせて見るか

実接続遅延が答えるのは「応答を受け取り始めるまで何秒か」、ダウンロード速度が答えるのは「接続確立後、1秒あたりどれだけデータを転送できるか」です。短いWebページの閲覧、APIリクエスト、リアルタイム操作では前者が重要です。大容量ファイルのダウンロードや高ビットレートコンテンツの再生では、後者がより重要になります。あるノードは110 msでリクエストを完了しても、継続ダウンロードは3 MiB/sしか出ないことがあります。別のノードは最初の応答まで180 msかかっても、12 MiB/sを安定して維持できる場合があります。

以下は、同じPC、同じ有線ネットワーク、同じテストファイルで記録した例です。測定前に他のダウンロードを停止し、v2rayNのローカルSOCKSポートを10808、HTTPポートを10809に設定します。実接続遅延は3回連続で測定して中央値を取り、ダウンロードは接続が安定してから30秒間の平均値を記録します。

このデータでは、プロキシ経由のダウンロード速度が直接接続の基準値の約9割に達しており、帯域幅を比較的有効に利用できています。実接続遅延はpingより67 ms高く、この差はプロキシのハンドシェイクとノードから測定対象までの経路によって生じたものです。67 msをすべて特定のプロトコルの影響とみなすことはできません。対象サイトの応答、DNSキャッシュ、接続再利用の状態も結果に影響するためです。

単位を換算する場合も、表記をそろえましょう。クライアントやブラウザではダウンロード速度をMiB/sで表示することが多く、ネットワーク帯域幅はMbit/sで表すのが一般的です。概算では8を掛けますが、MiBとMBの定義には違いがあります。11.5 MiB/sは約96.5 Mbit/sであり、11.5をそのまま「100 Mbit/s」と比較することはできません。

おすすめの測定順：まず環境を確認し、その後ノードを絞り込む

何度も速度測定をクリックするより、正しい順序で進めることが重要です。測定中にサブスクリプションの更新、ブラウザのダウンロード、システムプロキシモードの切り替えが行われていると、数値を比較できません。デスクトップではまずv2rayNを開き、「設定」→「パラメータ設定」でローカルの待受ポートを確認し、現在のシステムプロキシモードとルーティングモードも確認します。

1. 直接接続の基準値を作る。いったんプロキシを使うタスクを停止し、同じネットワークで対象ファイルの直接接続速度と通常のWebページの応答を記録します。直接接続自体が継続的に変動する場合は、まずローカルネットワークを確認してください。
2. サブスクリプション設定を確認する。サブスクリプションの更新後、ノードアドレス、ポート、VMessまたはVLESSプロトコル、伝送方式、TLSパラメータが完全に読み込まれていることを確認します。
3. pingで一次選別する。明らかな高遅延や連続したパケットロスがないか確認します。単一ノードがICMPに応答しなくても、いったん残して実接続テストを続けてください。
4. 実接続テストを行う。v2rayNで候補サーバーを選択し、右クリックメニューから「サーバーの実接続遅延をテスト」を実行します。各ノードを3回測定し、初回だけキャッシュ状態が異なる場合はその結果を除外して、後の2回を比較するか、3回の中央値を取ります。
5. 対象のWebページを手動で開く。候補ノードへ切り替えて接続を再確立し、実際に利用するWebサイトへアクセスします。ルーティング規則によって測定トラフィックが直接接続になっていないことを確認してください。
6. 最後にダウンロードを測定する。同じHTTPSファイル、同じ測定時間、単一接続の条件で、2～3個の候補ノードのスループットを比較します。
7. 時間帯を変えて再測定する。日中と夜間にそれぞれ1回ずつ記録します。夜間に速度が10 MiB/sから2 MiB/sへ低下し、ローカルの直接接続が安定しているなら、ノード負荷や異なるネットワーク間の経路を重点的に確認します。

ルーティングを分割して測定する場合は、古い接続にも注意してください。ルールを変更しても、ブラウザが確立済みの接続を再利用していると、新しいルールがすぐ結果に反映されないことがあります。該当ページを閉じ、接続が解放されるまで待ってから再測定します。必要に応じてクライアントのコアを再起動し、ログで対象ドメインがプロキシのアウトバウンドと直接接続のどちらに振り分けられたかを確認してください。

よくある誤判定とトラブル対応

遅延一覧は候補を絞るのに役立ちますが、実際の使用環境をそのまま代替するものではありません。1回の測定では、DNSキャッシュ、サーバーの一時的な混雑、測定対象の速度制限などの影響を受けることがあります。信頼できる判断には、少なくとも同じ環境、繰り返し測定、実際の対象での確認という3つの条件が必要です。

最終的な選択は用途ごとに分けられます。Web閲覧やリモート操作では、実接続遅延が安定し、連続測定時のばらつきが小さいノードを優先します。大容量ファイルの転送では、継続速度が直接接続の基準値に近いノードを選びます。両方が不安定な場合は、まずローカルネットワークとルーティング規則を確認し、その後でサブスクリプションのノード自体を判断してください。