V2Rayの遅延テスト結果の見方：ICMP Ping・実接続遅延・ダウンロード速度の違い

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

ノード一覧に35 ms、126 ms、78 MB/sと表示されても、これらの数値をそのまま比較することはできません。ミリ秒は1回の通信にかかる時間、MB/sやMbpsは単位時間あたりのデータ転送量を示します。同じミリ秒表示でも、ICMP Pingと実接続遅延では通過するプロトコル層が異なります。

ICMP Pingは通常、端末からノードのサーバーアドレスへ直接エコー要求を送り、ネットワーク層の往復時間とパケットロスを確認します。VMess、VLESS、Trojan、Shadowsocksのプロキシハンドシェイクは実行せず、ノード設定のユーザー識別子、ポート、トランスポート層パラメーター、暗号化設定が利用可能かどうかも検証しません。

実接続遅延では、クライアントが現在の設定を起動し、ローカルプロキシの入口からテスト先への実際の接続を確立します。DNS名前解決、サーバーとのTCPなどのトランスポート接続、プロキシプロトコルのハンドシェイク、テスト先からの応答待ちまでが含まれます。ダウンロードテストではさらに大きなデータを転送し、時間とデータ量からスループットを算出します。

ICMP Pingが低いことは、基礎的な経路が短いことを示すだけ

Pingの数値は、端末からサーバーのIPアドレスまでのネットワーク経路で決まります。一般に同じ地域のサーバーは大陸をまたぐサーバーより低くなりますが、通信事業者のルーティング、混雑する時間帯、中継ネットワークの迂回によって結果は変わります。地理的に近いノードでも、経路の迂回によって遅延が高くなることがあります。

たとえば同じPCから20回連続でリクエストを送り、ノードAは平均38 ms・パケットロス0%、ノードBは平均31 ms・パケットロス15%だったとします。平均値だけを見るとBの方が速いように見えますが、15%のパケットロスは再送や待ち時間を発生させ、Webページの読み込みやプロキシのハンドシェイクを不安定にします。この場合は、パケットロスのないAを優先して残すべきです。

サーバーによってはICMPリクエストを制限または無視するため、Pingのタイムアウトはプロキシポートが必ず利用不能であることを意味しません。逆に、サーバーがPingに応答しても、サブスクリプションのポートが待ち受け中とは限らず、UUID、トランスポート経路、TLSドメインなどの設定が一致している証拠にもなりません。Pingがタイムアウトしても実接続遅延が表示されるノードは、実接続の結果を基準にしてください。

• 平均遅延は全体的な往復時間を示しますが、単発のスパイクを隠すことがあります。
• 最小遅延は回線が理想的な状態に近いときの値であり、継続利用時の体感を示すものではありません。
• 最大遅延と変動幅は、ネットワークの揺らぎを判断する手掛かりになります。
• 平均遅延の差が5〜10 ms程度であれば、まずパケットロス率を優先して確認すべきです。
• 企業ネットワークや公衆ネットワークではICMPが直接フィルタリングされても、許可されたTCP接続には影響しない場合があります。

実接続遅延はノードが使えるかを確認するのに最適

実接続遅延では、Pingにはないアプリケーション層の処理全体が加わります。一般的なTCPトランスポートの場合、クライアントはアドレスを解決し、サーバーポートへの接続を確立し、ノード設定に従ってプロキシハンドシェイクを完了してから、プロキシ経由でテスト先へアクセスします。WebSocket、TLS、その他のトランスポート構成を使う場合は、それぞれのハンドシェイクも追加されます。

そのため、実接続遅延がICMP遅延より高くなるのは正常です。Pingが40 msで、完全なテスト結果が105 msだったとしても、それだけでノード異常とは判断できません。追加時間には、TCP接続、TLSネゴシエーション、プロキシプロトコルの処理、テスト先の応答、クライアント側でのテストタスク待ちなどが含まれる可能性があります。

v2rayNでは、まず1つまたは複数のノードを選択し、「サーバー」→「サーバーの実接続遅延をテスト」を実行します。一部のバージョンでは、ノードの右クリックメニューにも同じ項目があります。テストが完了すると、成功した項目にはミリ秒単位の数値が表示されます。タイムアウトや失敗になった項目は、ノードが利用不能なのか、テスト先に到達できないのか、テストの待機時間が足りないのかをログと併せて判断してください。

1. まずサブスクリプションを更新し、サーバー側で削除された古い設定をテストしないようにします。
2. ノード一覧で候補を選択し、「サーバー」→「サーバーの実接続遅延をテスト」を実行します。
3. タイムアウトしたノードはいったん除外し、結果が得られたノードの遅延と安定性を比較します。
4. 候補ノードをアクティブサーバーに設定し、システムプロキシを有効にして複数のページを実際に開きます。
5. 初回の結果が異常な場合は、単発のネットワーク揺らぎによる誤判定を避けるため、30秒空けてさらに2回テストします。

すべてのノードが同時に実接続タイムアウトになる場合は、サブスクリプション全体が無効になったとすぐ判断せず、まずローカル状態を確認してください。「設定」→「パラメーター設定」→「基本設定」を開き、ローカルの待ち受けポートが他のプログラムと競合していないか確認します。一般的な設定ではローカルSOCKS入口に10808、旧式の分離設定ではHTTP入口に10809を使用することがありますが、実際には現在の画面に表示されている値を基準にしてください。

ダウンロード速度はスループットを示すが、Webページの表示速度とは別

ダウンロード速度テストでは、継続的なデータ転送能力を確認します。通常は現在のプロキシ接続を通じて一定量のデータをダウンロードし、転送バイト数を所要時間で割って速度を算出します。ローカル回線の帯域、無線ネットワークの品質、ノードの出口容量、回線の混雑、テスト先の速度制限、クライアントの並列処理方針が同時に影響します。

MbpsとMB/sは同じ数値として直接比較できません。ネットワーク帯域にはMbps、ファイルのダウンロード画面にはMB/sがよく使われます。理論上は8 Mbpsが約1 MB/sです。テスト結果が80 Mbpsなら理論上限は約10 MB/sですが、プロトコルのオーバーヘッド、再送、ディスクへの書き込みによって、実際のファイル速度はやや低くなります。

帯域が広いノードでも、インタラクティブな通信の遅延が最小とは限りません。たとえばノードAは実接続遅延85 ms・ダウンロード42 Mbps、ノードBは実接続遅延145 ms・ダウンロード160 Mbpsだったとします。普段のWeb閲覧ではAの方が軽快に感じられる一方、高ビットレートの動画や大容量ファイルの転送にはBが適しています。選択基準は用途で決め、3つの数値を単純に合算して順位付けしないでください。

v2rayNで候補ノードを選択したら、「サーバー」→「サーバーのダウンロード速度をテスト」を使用できます。ダウンロード速度テストは実際のサブスクリプション通信量を消費するため、ノード一覧全体に頻繁に実行するのは適していません。まず実接続遅延で候補を2〜3個に絞り、それぞれ1回ずつ測定すれば、通常は十分に判断できます。

速度テストは順序を固定してこそ比較できる

速度テストで最も多い問題は、ツールの誤動作ではなく、条件が変化し続けることです。午前にノードA、夜にノードBを測ったり、一方を有線、もう一方を無線で測ったりすると、差をノードだけに帰属できません。端末、接続ネットワーク、テスト先、時間帯をできるだけ揃えてください。

候補ノードごとに実接続テストを10〜30秒間隔で3回行い、最小値だけでなく中央値を記録することをおすすめします。たとえば92 ms、108 ms、246 msなら中央値は108 msです。246 msは明らかな揺らぎを示すため、削除して見栄えのよい数値だけを残すのではなく、引き続き観察してください。

1. 進行中の大容量ファイルのダウンロード、クラウド同期、システム更新を停止します。
2. 同じネットワーク上でサブスクリプションを更新し、地域と倍率が要件に合うノードを選びます。
3. まず実接続遅延を実行し、継続的なタイムアウトやプロトコルハンドシェイク失敗の設定を除外します。
4. 残ったノードを3回ずつ再テストし、中央値と最大値の差を比較します。
5. 最終候補の2〜3ノードだけにダウンロード速度テストを実行します。
6. アクティブサーバーに設定した後、実際に利用するWebサイトを開き、システムプロキシが有効になっていることを確認します。

ノードA：実接続 92 / 108 / 246 ms、ダウンロード 68 Mbps
ノードB：実接続 124 / 128 / 131 ms、ダウンロード 82 Mbps
ノードC：実接続タイムアウト / タイムアウト / 310 ms、今回は選択しない

閲覧を優先：ノードB、遅延はやや高いが変動が小さい
ダウンロードを優先：ノードB、継続帯域も高い
継続観察：ノードA、246 msが混雑時間帯にも繰り返し発生するか確認が必要

ブラウザーの通信が確実にプロキシを経由しているか確認するには、まずv2rayNでアクティブサーバーを設定し、システムプロキシを有効にします。そのうえで信頼できるIP情報ページにアクセスし、有効化前後の出口アドレスを比較してください。アドレスが変わらない場合は、速度テストを繰り返すのではなく、まずシステムプロキシの状態とブラウザー独自のプロキシ設定を確認します。

速度テストでよくある異常値への対処

同じノードで短時間に大きく異なる結果が出る場合は、通常、ローカルネットワーク、ノード負荷、テスト先の3方向から切り分けます。1回のタイムアウトだけでノードを削除したり、1回だけ極端に低い遅延が出たからと長期固定したりしないでください。単発のピーク値より、連続した結果の方が判断材料になります。

ルーティングの振り分けも、テスト結果と実際のアクセスの対応関係に影響します。テスト先は現在のルールによりプロキシを経由していても、実際にアクセスする特定のドメインはルールで直接接続に設定されていることがあります。逆の場合もあります。速度テストは正常なのに特定サイトの挙動が異なるなら、速度テストを繰り返すのではなく、ルーティングルールの適用状況とコアのログを確認してください。

最終判断は3段階にまとめられます。Pingは基礎ネットワークとパケットロスの確認、実接続遅延は設定の利用可能性と通信応答の比較、ダウンロード速度テストは継続帯域の確認に使います。3つは互いに代替できず、ノードの品質を1つの数値だけで完全に表すこともできません。