遅延テストの数値の見方：ICMP ping・実接続遅延・ダウンロード速度の違い

3つの数値は同じ経路を測っていない

ノード一覧に35 ms、118 ms、76 Mbpsが同時に表示されても矛盾ではありません。ミリ秒は往復や1回のリクエストにかかる時間、Mbpsは単位時間あたりの転送量を表します。前者は待ち時間、後者は継続的な転送速度に着目した指標で、単位も用途も異なります。

ICMP pingは通常、システムからサーバーアドレスへ直接エコー要求を送信します。パケットがサーバーのネットワークインターフェースに到達し、応答を受け取ると測定は完了します。自宅ネットワークからサーバーアドレスまでの基本的な往復時間やパケットロスは確認できますが、通常はVMess、VLESS、トランスポート層のカプセル化、TLSハンドシェイク、プロキシ出口からのアクセスは経由しません。

実接続遅延では、pingより長い経路を測定します。v2rayNとXrayコアを組み合わせる場合、リクエストはローカルプロキシの入口、ノードプロトコルのハンドシェイク、TCPなどのトランスポート接続、必要に応じたTLSネゴシエーションを経て、サーバーの出口から測定先へアクセスします。測定先の応答速度、DNS名前解決、出口回線も結果に影響します。

ダウンロード速度測定は、さらにその先の継続的な転送能力を測ります。往復時間だけでなく、サーバー側の速度制限、出口帯域、ローカル回線、ネットワーク間の混雑、TCP輻輳制御、テストファイルの配信元にも左右されます。遅延が160 msでも100 Mbpsを維持できるノードがある一方、45 msでも継続ダウンロードでは8 Mbpsしか出ないノードもあります。

pingは低いのに実接続遅延が高いのはなぜか

最も多い原因は、2つの測定で終点が異なることです。pingはサーバーアドレスがICMPに応答した時点で終了しますが、実接続テストではサーバーから外部の測定先へアクセスします。サーバーへの入口回線が良好でも、サーバーの出口から測定先までの経路が同じように快適とは限りません。

プロトコルのハンドシェイクも固定的なオーバーヘッドを増やします。TCP接続の確立には通常1往復が必要で、TLSの初回ネゴシエーションではさらにデータ交換が発生します。ノードがWebSocketとTLSを使用している場合、実接続テストで完了すべき手順は単純なICMPエコーより多くなります。VLESSやVMess自体の処理時間は通常、主要なボトルネックではなく、地域間の往復、TLS、出口側の混雑によって差が開きやすくなります。

上記は同じネットワーク環境で取得した説明用の記録です。Windows 11 24H2、v2rayN 7.12.5、Xray-core 25.6.8を使用し、ローカルの混合プロキシポートは10808です。78 Mbpsは約9.75 MB/sに相当しますが、ブラウザーやダウンロードツールの実測値にはサンプリング時間やプロトコルのオーバーヘッドによる差も含まれます。これらの数値は単位の関係を示すもので、ノード性能の基準ではありません。

比較可能なノードテストを行う手順

単発の数値より、比較条件をそろえることが重要です。あるノードを早朝に測定し、別のノードを夜間の混雑時間帯に測って比較してはいけません。端末、接続回線、クライアントのバージョン、コア、測定先、時間帯を固定し、帯域を消費する同期やダウンロードは停止してください。

v2rayN 7.xでは、比較するノードを選択してから、「サーバー」→「サーバーの実接続遅延をテスト」を実行できます。基本的なネットワーク状態を確認する場合は、「サーバー」→「サーバーの遅延をテスト」を使用します。マイナーバージョンによってメニュー表記は多少異なる場合がありますが、「遅延」と「実接続遅延」は区別し、2列の結果を同じ指標として扱わないでください。

1. まず「設定」→「パラメーター設定」で、ローカルの待受ポートが競合していないことを確認し、現在使用しているコアの種類を記録します。
2. 候補ノードを3～5個選び、実接続遅延テストを3回連続で実行します。各回の間隔は約10秒にします。
3. DNSキャッシュが温まっていないことや、TLSの初回ネゴシエーションの影響を受けた最初の異常なスパイクは除外し、後半2回の中央値を記録します。
4. 接続遅延の中央値が低い2つのノードに接続し、同じテストファイルをそれぞれ30～60秒間継続ダウンロードします。
5. 夜間の混雑時間帯にも再測定します。遅延と速度がともに大きく悪化する場合は、時間帯による混雑を判断材料に加えてください。

テスト中はルーティングモードも固定してください。ブラウザーのダウンロード先がルールによって直接接続と判定されると、測定されるのはノードのスループットではなくローカル回線の速度です。v2rayNのコアログでリクエストがプロキシの出力へ送られているか確認するか、一時的にグローバルプロキシモードで比較し、完了後に元の分流設定へ戻してください。

平均値、ジッター、パケットロスをどう組み合わせて見るか

最低値だけを見ると、たまたま速かったノードを選びやすくなります。1回48 msだったからといって、その後のリクエストも48 msを維持できるとは限りません。結果が48、51、236、55、420 msと続く場合、平均値はスパイクによって押し上げられますが、中央値はなお55 ms付近です。このとき中央値は平常時の状態を示し、最大値とばらつきは引っかかりやすさを示します。

インタラクティブなアプリケーションはジッターの影響を受けやすい傾向があります。ウェブページの読み込みは複数の接続とリクエストで構成されるため、遅延が時折数百ミリ秒まで跳ね上がると、一部のリソースの表示が遅れます。動画のバッファーはジッターをある程度吸収できるため継続速度の影響が大きく、リアルタイム音声やリモート操作では安定した遅延とパケットロスがより重要です。

• 中央値：複数の結果を並べたときの中央の値で、その時間帯におけるノードの典型的な遅延を表すのに適しています。
• ジッター：連続する結果の変化を確認します。大半の結果の差が15 ms以内に収まる状態は、40～300 msの間を繰り返し変動する状態より、通常は安定しています。
• パケットロス：10回のpingで1回失われれば、パケットロス率は10%です。平均遅延が低くても、明らかなパケットロスがあると再送が発生し、実効速度が低下します。
• タイムアウト率：実接続テストでタイムアウトが連続する場合、プロキシ経路全体に失敗が発生しています。1回だけ成功した最低値よりも、判断材料として重視すべきです。

ICMPのパケットロスを、そのままプロキシ通信のパケットロスと見なすことはできません。一部のネットワークではICMP応答の優先度が制限されても、TCP通信は正常に転送される場合があります。pingでロスがあっても実接続が安定しているなら、ダウンロードや実際のアクセスを引き続き確認し、ICMPだけで結論を出さないでください。

利用シーンごとに、どの数値を重視すべきか

ウェブ閲覧、検索、APIリクエストは、多数の短い接続や短時間の処理で構成されるため、待ち時間の割合が大きくなります。実接続遅延が300 msから100 msに下がるほうが、ダウンロード速度が80 Mbpsから100 Mbpsに上がるより体感しやすいことが一般的です。この用途では、まずタイムアウトするノードを除外し、その後に実接続遅延の中央値を比較します。

高画質動画や大容量ファイルの転送では、安定したスループットがより重要です。遅延が頻繁なタイムアウトを起こすほど高くなければ、180 ms・80 Mbpsのノードのほうが、60 ms・12 Mbpsのノードより継続ダウンロードに適する場合があります。換算時は、8 Mbpsが理論上約1 MB/s、80 Mbpsが理論上約10 MB/sである点に注意してください。実速度はプロトコルのオーバーヘッドによりやや低くなります。

• 一般的なウェブ閲覧：実接続遅延を優先し、次に変動とタイムアウト率を確認します。
• リモートターミナル：安定した遅延を優先します。継続的な帯域幅の要求は通常それほど高くありません。
• 動画再生：継続ダウンロード速度を優先し、夜間の混雑時間帯における最低速度も確認します。
• 大容量ファイル転送：平均スループットを優先し、測定時間は60秒以上に延ばします。
• サブスクリプションの一括一次選別：まずpingで素早く確認し、候補ノードに実接続テストを実行します。

ノードのプロトコルも比較条件をそろえる必要があります。VLESSノードとVMessノードでは、地域、トランスポート、出口が異なる可能性があり、数値の差をプロトコル名だけに帰すことはできません。プロトコルは接続形式と機能を担いますが、実際の遅延は主に物理的な距離、通信事業者の経路、混雑、サーバー負荷に左右されます。

v2rayNGの測定結果も、Android端末の現在のネットワーク環境に左右されます。無線LANの電波状況、モバイル回線の切り替え、バックグラウンドのダウンロードはいずれも結果を変化させます。デスクトップ版v2rayNとAndroid版v2rayNGは同じサブスクリプションを使っていても別々に測定し、一方の端末のミリ秒値をそのまま別の端末に当てはめないでください。

遅延テストに関するよくある質問

最終的な判断は、実際に利用する経路へ戻して考える必要があります。pingは迅速な診断ツール、実接続遅延はプロキシリクエスト全体の待ち時間、ダウンロード速度は継続的な転送能力を測る指標です。3つはそれぞれ「基本ネットワーク上でどれだけ遠いか」「プロキシリクエストをどれだけ待つか」「長時間にどれだけデータを転送できるか」に答えるもので、どれか1つで他の2つを代用することはできません。