Ping・実接続遅延・ダウンロード速度の違い：v2rayN遅延テストを理解する

ノード一覧に35 ms、128 ms、18 MB/sが同時に表示されても、3つのツールのうち2つが間違っているわけではありません。それぞれ異なるプロトコルで別の対象へアクセスし、異なる問いに答えています。ホストの応答速度、プロキシ経由の実リクエストの完了可否、そして通信を継続したときのスループットです。何を測っているかを整理して初めて、数値をノード選びに活用できます。

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

一般的なPingはICMP Echoリクエストを指します。システムからノードサーバーのアドレスへ小さなパケットを送り、Echo Replyを待って往復時間をミリ秒で記録します。主に端末からサーバーIPまでのネットワーク往復経路を測るもので、VMessやVLESSのハンドシェイク、プロキシの出口から対象サイトへアクセスできるかどうかまでは検証しません。

注意したいのは、クライアント画面に「Ping」と表示される機能が、必ずしもICMPを使うとは限らない点です。環境によってはTCPingに切り替え、サーバーの実ポートへTCP接続を試みてICMPの制限を回避します。TCPingでポートが接続を受け付けることは確認できますが、プロキシプロトコルの完全なハンドシェイク、暗号化通信、ルーティング、出口アクセスまでは確認できません。

• 入口経路：端末のネットワークが通信事業者の回線を経由してノードサーバーに到達します。
• プロキシ経路：入口への接続後、VMessやVLESSなどのプロトコルに必要なハンドシェイクと通信を実行します。
• 出口経路：ノードサーバーがテスト対象へアクセスし、対象からの応答がプロキシ経路を通って端末へ戻ります。
• 継続通信：ダウンロード速度テストでは、サーバー側の速度制限、同時接続数、輻輳制御、テストファイルのサイズも結果に影響します。

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

最も多いのは、ノードの入口は近くても出口までの経路が長いケースです。たとえばサーバーの入口が近隣地域にあり、ICMPの往復は32 msでも、ノードからテスト対象へは混雑した上位回線を通り、実際のリクエスト全体では180 msになることがあります。この場合、Pingは入口までの距離を、実接続遅延はプロキシ経由のリクエストコストを正しく示しています。

プロトコルのハンドシェイクも差を広げます。TCP接続ではセッションを確立し、TLS通信では証明書と鍵のネゴシエーションが行われます。WebSocketやgRPCにも固有のカプセル化処理があります。テストツールが既存接続を再利用するか、名前解決を行うか、完全なレスポンスヘッダーを待つかによっても、最終的なミリ秒値は変わります。そのため、異なるバージョンやテストアドレスで得た結果を単純に比較して順位付けすることはできません。

上記の数値は、同じLAN・同じノードを連続してテストした説明用サンプルであり、ノード品質の基準ではありません。34 msから126 msまでの差は、プロキシのハンドシェイク、名前解決、出口までの距離、テスト対象の応答などが合わさったものです。11.8 MB/sは、最初の応答は遅くても接続確立後の継続スループットは高いことを示します。

1. 3回のテストが同じノードを対象にしていることを確認し、ノードの自動切り替え後に古い結果と比較しないでください。
2. 実行中のシステム更新、クラウドストレージの同期、大容量ファイルの転送を停止し、ローカル回線の競合を減らします。
3. 3回連続でテストして中央値を記録し、1回だけの最低値を結論にしないでください。
4. 実接続遅延が時々1000 msを超える場合は、コアのログにハンドシェイクのタイムアウト、DNSタイムアウト、接続リセットが出ていないか確認します。

実接続遅延がWebリクエストに近い理由

v2rayNの実接続遅延は、サーバーのポートを単純に探るものではありません。クライアントはまず選択したコアにノード設定を読み込ませ、その後ローカルのプロキシポートからテストアドレスへリクエストを送ります。通常はローカルリスナー、ルーティング判定、プロトコルのカプセル化、リモートノードでの受信、出口からのアクセス、応答の返送を経るため、「ポートは開いているがプロキシ設定が使えない」といった問題も見つけられます。

v2rayN 7.12.xの一般的な画面を例にすると、まずノード一覧で項目を選択し、右クリックメニューから「サーバー実接続遅延をテスト」を実行します。一括確認では複数のノードを選択して同じ操作を行えます。マイナーバージョンによってメニューの配置は変わる場合がありますが、テスト名とノード一覧の遅延結果列は通常対応しています。

ローカルのリスニングポートも切り分けに影響します。v2rayNでよく使われるローカルポートは10808で、古い設定ではHTTPプロキシが10809になっている場合もあります。一般的な値だけを根拠にブラウザやシステムプロキシを変更せず、「設定」→「パラメータ設定」で現在のポートを確認し、別のプログラムが同じポートを使用していないことも確かめてください。ローカルのプロキシ入口が起動していなければ、すべてのノードが同時に失敗と表示される可能性があります。

テスト記録の例
クライアントバージョン：v2rayN 7.12.x
ローカルプロキシポート：10808
ノードA：92 ms / 98 ms / 95 ms
ノードB：61 ms / 420 ms / 73 ms
判定：Aのほうが安定。Bは最低値が低いが、変動が大きすぎる

ダウンロード速度テストで遅延テストを代用できない理由

ダウンロード速度テストは、単位時間あたりに受信できるデータ量を確認します。プロキシ接続を確立して通信を継続するため、ローカル回線の帯域、ノードサーバーの出口、テスト元の速度制限、単一接続の性能、プロトコルのオーバーヘッド、輻輳制御の影響を同時に受けます。遅延180 msのノードでも、接続確立後に大量のデータを経路上で流し続けられるため、20 MB/sに達することがあります。

反対に、遅延55 msのノードが2 MB/sしか出ないこともあります。ノードがユーザーごとの速度を制限している、夜間の混雑がある、テスト対象が単一接続を制限している、といった原因が考えられます。低遅延はリクエストの往復が速いことを示すだけで、回線容量の大きさを保証しません。Webページや小規模なAPIリクエストでは最初の応答時間が、大容量ファイルのダウンロードや高ビットレート動画では継続スループットがより重要です。

速度テストではMB/sとMbpsも区別してください。1 Byteは8 bitなので、クライアントに12 MB/sと表示された場合は、およそ96 Mbpsに相当します。プロトコルや回線のオーバーヘッドは含まれていません。回線の上限が100 Mbpsなら、10〜11.5 MB/s程度で実用上の上限に近い状態です。12 MB/sを12 Mbpsと読み違えないようにしましょう。

• まず他の機器がローカル回線を使い切っていないことを確認してから、ノードの速度を評価します。
• 同じノードを少なくとも2回測定し、テスト元の短時間の変動を避けます。
• 数十個のノードでダウンロード速度テストを同時に実行しないでください。帯域を奪い合い、結果が不正確になります。
• サブスクリプションに記載された通信量倍率は実際の消費量に影響します。速度が高いからといって、長期的なデフォルト利用に適しているとは限りません。

プロトコル、ルーティング、DNSが結果を変える仕組み

VMessとVLESSはプロキシプロトコルであり、遅延の等級ではありません。プロトコルの種類だけで、どのノードが速いかを判断することはできません。通常はサーバーの場所、回線品質、トランスポート設定、負荷のほうが重要です。同じ物理サーバー上の2つの設定なら、プロトコルが異なっても差は小さい場合があります。一方、異なる回線上にある同じプロトコルのノードでは、遅延や速度が数倍違うこともあります。

ルーティングによって、テストリクエストの最終的な経路が決まります。テストドメインがルールで直通と判定されると、選択したノードのプロキシ性能ではなく、ローカルネットワークからテスト元へアクセスした結果になる可能性があります。テスト前にv2rayNのルーティングモードとルールセットを確認し、コアのログでリクエストがプロキシ出站を使ったのか、直通出站になったのかを確認してください。

• 名前解決の場所：ローカルDNSとリモートDNSでは異なるアドレスが返ることがあり、それに伴ってテスト対象までの物理的な距離も変わります。
• ルーティングルール：ドメイン、IP、ポート、プロセスのルールによって、速度テストのリクエストが異なる出站へ送られる場合があります。
• トランスポート設定：TCP、WebSocket、gRPCなど、トランスポート方式によって接続確立のコストが異なります。
• 接続の再利用状態：既存の接続を再利用すると後続リクエストの時間は短くなりますが、初回のWebページ表示にかかるコストを示すものではありません。
• コアの実装：クライアントのバージョン、Xrayコアのバージョン、設定パラメータの違いがテスト結果に影響することがあります。

v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。同じサブスクリプションを読み込んでも、Android端末とデスクトップ版v2rayNでは、ローカルネットワーク、DNSポリシー、コアのバージョン、テスト方式が異なる場合があります。そのため端末間の数値は傾向を見るためのもので、ミリ秒値が完全に一致するとは限りません。実際の使用感を判断するときは、それぞれの端末で個別にノードを選別してください。

再現性のあるノード選別手順

信頼できる選別の要点は、最低値を追い求めることではなく、条件を固定して段階的に測定することです。まずサブスクリプションを更新し、ノード設定が有効であることを確認してから、帯域を使うタスクを停止します。テスト中は同じネットワーク入口を使い、有線、無線、モバイルホットスポットを切り替えないでください。速度を測りながらルーティングモードを変更するのも避けます。

1. 設定を更新：サブスクリプショングループで更新を実行し、ノードアドレス、ポート、プロトコルの項目が読み込まれていることを確認します。
2. ローカル入口を確認：「設定」→「パラメータ設定」を開き、10808などのローカルリスニングポートを確認し、コアが正常に起動していることを確かめます。
3. 実接続を一括測定：ノードの実接続遅延を測定し、タイムアウト、ハンドシェイク失敗、1000 msを継続的に超える項目を先に除外します。
4. 候補を繰り返し測定：各候補ノードを3回テストし、中央値と最大値を記録します。最低値だけを残さないでください。
5. 用途別に速度を測定：Web用途では遅延の安定性を優先し、動画やダウンロード用途では継続ダウンロード速度も測定します。
6. 実際のルーティングを確認：コアのログを開き、リクエストが想定したプロキシ出站を通り、分流ルールによって直通に変更されていないことを確認します。
7. 予備ノードを残す：主力ノード以外にも、異なる入口または回線の設定を2つ残しておくと、混雑時に切り替えられます。

日常的な目安として、実接続遅延が200 ms未満で、3回の最大差が80 ms以内ならWeb閲覧用の候補にできます。継続ダウンロードがローカル回線の実用上限の60%以上に達するなら、大容量通信の候補と考えられます。しきい値は地域や接続回線に合わせて調整し、すべての回線に機械的に当てはめないでください。

最終的には、3つの指標を役割分担として理解しましょう。Pingは入口経路をすばやく確認するため、実接続遅延はプロキシ経由のリクエストと操作感を検証するため、ダウンロード速度は継続通信の能力を確認するために使います。3つの数値が同じ方向に揃う必要はなく、すべての用途を1つの指標で表すこともできません。テスト条件を固定し、複数回の結果の安定性を確認したうえで用途に合わせて選ぶほうが、一覧の最低ミリ秒値を追うより信頼できます。