同じノードでも、pingは38 ms、実接続遅延は112 msなのに、ダウンロード速度は92 Mbpsに達することがあります。別のノードではpingが80 msでも、Webページの表示は速い場合があります。これはテストの失敗ではなく、3つの指標が異なる経路を見ているためです。テストでどの通信が発生し、どのプロトコル段階を通過したのかを確認して初めて、数値を比較する意味が生まれます。
この記事は、v2rayN、v2rayNG、v2flyNGでノードを選びたい方に適しています。要点は、pingは基礎的なネットワーク確認、実接続遅延は操作時の応答性の判断、ダウンロード速度は継続的なスループットの評価に使うことです。普段使いのノードは実接続遅延と安定性を優先し、ダウンロード速度で帯域幅を確認しましょう。
3種類のテストで実際に測っているもの
ICMP pingは対象アドレスにエコー要求を送り、応答が戻るまでの往復時間を記録します。通常は端末のネットワーク、通信事業者の回線、対象ホストを通過するだけで、VMessやVLESSの認証を実行したり、WebSocket、gRPC、TLS、REALITYのセッションを確立したりはしません。サーバー側でICMP応答が制限されている場合もあるため、pingのタイムアウトだけでプロキシポートが使えないとは判断できません。
実接続遅延は、クライアントの現在の出力設定を使って実際のリクエストを1回送信します。テストには少なくともサーバーポートへのTCP接続が含まれ、TLSを使う場合はセキュアハンドシェイク、VMessやVLESSなどを使う場合はプロキシセッションの確立も行われます。クライアントによっては指定したHTTPテスト先にも接続し、レスポンスヘッダーまたは最初のデータを正常に受信するまでの時間を結果とします。
ダウンロード速度テストは接続を維持し、十分なサイズのデータを転送します。単位時間あたりに何バイトを届けられるかを測るもので、主に回線帯域、サーバーの出口、輻輳制御、同時接続数、テストファイルのサイズに左右されます。接続確立までの応答が遅くても、接続後は高いスループットを維持できるノードもあります。
ICMP ping
ネットワーク層の往復時間を測定しますが、プロキシポート、プロトコル認証、転送設定は確認しません。
適しています：基礎的な到達性の確認、パケットロスや回線の揺らぎの観察
実接続遅延
おすすめプロキシのハンドシェイクと実際のリクエストを経由するため、Webページの表示やAPI呼び出し時の待ち時間に近い結果が得られます。
適しています：普段使いの主力ノードの選定、操作時の応答性の比較
ダウンロード速度テスト
データを継続的に転送してスループットを算出します。主に帯域幅を示すもので、応答速度とは異なります。
適しています：大容量ファイルの転送、動画のバッファリング、継続的なダウンロード
- 回線が通っているか確認：pingを使い、平均値、最大値、パケットロス率も記録します。
- Webページの応答性を確認：実接続遅延を使い、少なくとも3回連続でテストします。
- 継続的な転送能力を確認：ダウンロード速度を測定し、テスト時間は10秒未満にしないでください。
3つの結果が食い違うことが多い理由
1つ目の理由は、測定対象が異なることです。pingの対象はサーバーのIPアドレスでも、実接続テストは外部のHTTPサイト、ダウンロード速度テストは別の測定サーバーに接続することがあります。後者2つではプロキシサーバーからテスト先までの出口経路も含まれます。対象が揃っていない場合、数値を同じ表に並べて単純に順位付けすることはできません。
2つ目の理由は、プロトコルのオーバーヘッドが異なることです。ICMPパケットは小さく、アプリケーション層のハンドシェイクを含みません。VLESSとTCP・REALITYの組み合わせや、VMessとWebSocket・TLSの組み合わせでは、往復回数が異なります。物理回線の往復時間が60 msの場合、直列のハンドシェイクが1回増えるだけで、ほぼ1往復分の時間が加わることがあります。DNSクエリがキャッシュにない場合は、名前解決の待ち時間も増えます。
3つ目の理由は、ネットワークが通信の種類ごとに異なる扱いをすることです。ホストによっては通常の業務接続を優先する一方、ICMPを制限します。逆に、ICMPは速くてもプロキシポートへの経路が混雑している場合もあります。無線ネットワークの一時的な干渉で再送が発生し、実接続テストが90 msから300 msに跳ね上がった後、次のテストでは正常に戻ることもあります。
| 現象 | 考えられる主な原因 | 次に確認すること |
|---|---|---|
| pingは低いが、実接続遅延が高い | TLSまたはプロキシのハンドシェイク、サーバー負荷、出口経路の迂回に時間がかかっている | 5回連続でテストし、カーネルログの接続エラーを確認する |
| pingはタイムアウトするが、プロキシは正常に使える | サーバーがICMPエコーを制限している | TCPポートテストと実接続テストに切り替える |
| 実接続は速いが、ダウンロード速度が遅い | 出口帯域の不足、ピーク時間帯の混雑、単一接続の制限 | 時間帯を変えて15秒以上のダウンロードテストを実行する |
| ダウンロードは速いが、Webページの初回表示が遅い | DNS、ハンドシェイク、または最初の1バイトを待つ時間が長い | DNSの経路と実接続遅延を確認する |
結論：食い違う数値は、まずテスト経路ごとに分けて考える
38 msのICMP結果で112 msの実接続結果を上書きしないでください。前者は基礎回線が短いことを示すだけで、後者には実際のプロキシハンドシェイクが含まれます。Webページの応答性を改善したい場合は、プロトコル、DNS、サーバー負荷、出口経路を確認しましょう。
再現性のある遅延テスト方法を作る
ノードを比較するときは、条件を揃える必要があります。サブスクリプション更新後、同じ地域に異なるサーバー、転送プロトコル、入口ポートが混在することがあります。一方でVLESS over TCP、もう一方でVMess over WebSocketをテストすると、結果に回線差とプロトコル差の両方が含まれ、本当のボトルネックを判断できません。
- ローカル環境を固定する。帯域を消費するダウンロードを停止し、できるだけ有線ネットワークを使います。無線しか使えない場合は、端末の位置と周波数帯を変えないでください。
- テスト対象を固定する。同じ実接続テストでは同じHTTP対象を使い、ダウンロード速度テストでは同じファイルと同じ継続時間にします。
- 複数回サンプリングする。各ノードを少なくとも5回テストし、DNSや接続のウォームアップの影響を受ける可能性がある1回目を除外してから、中央値を確認します。
- 揺らぎと失敗を記録する。最低値だけを記録しないでください。112、118、109、460、115 msという結果は明らかなスパイクが1回あることを示し、常に130～145 msに収まるノードより安定性が低いと判断できます。
- 時間帯を分けて再測定する。昼と夜にそれぞれ1回ずつ測定します。地域をまたぐ回線は夜間のピーク時間帯に帯域が低下することがあり、午前中の1回の結果だけでは1日全体を代表できません。
Windowsではping -n 20 服务器地址を使ってICMPの結果を20回収集できます。macOSとLinuxではping -c 20 服务器地址を使います。平均往復時間とパケットロス率を記録すれば十分で、コマンドラインのpingをプロキシプロトコルのテストと混同しないでください。
ノードA
ICMP：38 / 40 / 39 / 41 / 38 ms
実接続：112 / 118 / 109 / 121 / 115 ms
15秒ダウンロード：89 / 92 / 90 Mbps
ノードB
ICMP：61 / 63 / 60 / 62 / 61 ms
実接続：84 / 87 / 86 / 85 / 89 ms
15秒ダウンロード：54 / 57 / 55 Mbpsこの条件を揃えた記録では、ノードAは継続的なダウンロードに適し、ノードBはWeb閲覧、ターミナル接続、短いリクエストの繰り返しに適しています。pingだけで順位を付けても、ダウンロード速度だけで順位を付けてもAが選ばれます。しかし操作時の応答性で見ると、Bの実接続遅延は約27 ms低く、結論はまったく異なります。
v2rayN、v2rayNG、v2flyNGでの測定方法
クライアントのメニュー名はバージョンによって変わりますが、テスト入口は通信の種類で見分けられます。v2rayN 7.xでは、まずサーバー一覧から設定を選択し、「サーバー」→「サーバーの実接続遅延をテスト」を実行します。この操作は現在の設定で実際の接続を確立するもので、一覧に表示される基礎pingやTCP探測とは異なります。
Android版のv2rayNGはXrayカーネル、v2flyNGはv2flyカーネルを使用します。サブスクリプションを更新してノードを選択したら、右上のメニューから遅延テストを開けます。一括テストでは、サーバーポートの確認だけでなく「実接続」タイプのテストが実行されていることを確認してください。テスト前に一度接続し、ローカルVPNの通信制御、DNS、ルーティングルールを普段と同じ状態にしておきます。
ローカルプロキシを使って手動テストする場合は、まずv2rayNの「設定」→「パラメータ設定」でローカル待受ポートを確認します。一般的な混合プロキシポートは10808ですが、変更している場合は現在の設定を優先してください。テストツールでこのプロキシポートを明示的に指定しないと、リクエストが対象へ直接接続され、ノードの実接続結果にならない可能性があります。
- サブスクリプション更新後は、ノードのアドレス、ポート、プロトコル、転送方式に変更がないか確認します。
- 一括テスト中は、システムプロキシ、TUNモード、無線ネットワークを切り替えないでください。
- 結果がすべて負の値、タイムアウト、または同じ値になる場合は、まずテスト先にアクセスできるか確認します。
- ログに接続拒否が出ている場合は、まずサーバーポートを確認し、ダウンロード速度で判断し続けないでください。
指標を使ってノードとプロトコルを選ぶ方法
普段のWeb閲覧や即時リクエストでは、実接続遅延が低く、連続テストでの揺らぎが小さいノードを優先します。2つの回線が95 msと110 msの場合、15 msの差より安定性のほうが重要なことが多いです。前者が5回に1回500 msのスパイクを出し、後者が常に105～120 msなら、後者のほうが主力に適しています。
ダウンロード、動画のバッファリング、大容量ファイルの同期では、継続的なスループットがより重要です。10～30秒間の平均速度を比較し、途中で速度が低下しないかも確認します。開始直後は150 Mbpsでも、その後35 Mbpsで安定するノードの実効性能はピーク値ではなく、35 Mbpsに近いものです。
- VMess
- 認証と暗号化処理を含み、TCP、WebSocket、TLSなどの転送方式と組み合わせて使われます。遅延は組み合わせ全体で決まるため、プロトコル名だけに原因を求めるべきではありません。
- VLESS
- 軽量な認証プロトコルで、TLS、REALITY、TCP、gRPCなどと組み合わせて使われます。ハンドシェイク回数、サーバーとの距離、出口回線の品質が実接続遅延に影響します。
- TUN
- 仮想ネットワークアダプターで通信を引き受けます。有効にすると、テストリクエストもシステムのルーティングとDNS設定を経由するため、普段の全体通信環境に近い結果になります。
- ルーティング分岐
- ドメイン、IP、プロセスに応じて、直接接続とプロキシの出口を決めます。速度テストの対象が直接接続されている場合、クライアントに表示されるデータはプロキシノードを表しません。
VMessとVLESSを比較する場合は、できるだけ同じサーバー、同じ入口ネットワーク、近い転送条件を選びます。VLESSノードが近隣地域にあり、VMessノードがより遠い経路を通る場合、遅延差の主因は物理的な距離です。プロトコルは、サーバーの対応状況、転送時のセキュリティ方式、クライアントとの互換性を踏まえて選び、1回だけの最低遅延を基準にしないでください。
結論：主力ノードは中央値、予備ノードは経路の違いで選ぶ
主力ノードは5回の実接続テストの中央値で選び、頻繁にタイムアウトするものは除外します。予備ノードは別のサーバーまたは別の出口経路を優先し、2つの設定が同じ混雑箇所で同時に使えなくなる事態を避けます。
遅延テストでよくある疑問
テスト結果がおかしいときは、まず「テストがプロキシを経由していない」のか「プロキシが別の経路を通っている」のかを分けて考えます。前者は通常、ローカルポート、システムプロキシ、分岐ルールに関係します。後者はDNS、サーバーの出口、テスト対象を合わせて判断する必要があります。以下では、よくある操作上の誤りを取り上げます。
pingがすべてタイムアウトするのに、なぜノードへ接続できるのですか？
対象サーバーがICMPに応答していない可能性があります。クライアントの実接続テストに切り替え、プロキシポートへのTCP接続を確立できるか確認してください。pingのタイムアウトだけでサブスクリプションのノードを削除しないでください。
実接続遅延は、なぜ1回目だけいつも特に高いのですか？
初回テストには、DNSクエリ、TLSセッションの確立、接続のウォームアップが含まれることがあります。5回連続で実行し、2～5回目の中央値を記録すると同時に、コールドスタート時の体感を判断するため1回目の結果も残します。
遅延がわずか1 msですが、信頼できますか？
インターネット上の遠隔ノードが長時間1 msを示すことは通常ありません。ルーティングルールでテストリクエストが直接接続になっていないか、テスト対象がローカル端末を指していないかを確認してください。接続ログを見て、リクエストが選択したプロキシの出力先に入っていることを確認します。
ダウンロード速度が速いのに、なぜWebページの表示が遅いのですか？
高いスループットだけでは、DNS、プロトコルハンドシェイク、最初の1バイトを待つ時間を短縮できません。まず実接続遅延を測定し、次にDNS設定とルーティング分岐を確認します。短いリクエストが多い環境では、揺らぎの少ないノードを優先してください。
一括遅延テストで最も低かったノードが最適ですか？
いいえ。少なくとも5回再測定し、タイムアウト率、夜間ピーク時の性能、ダウンロードスループットも確認してください。最低値は1回のサンプルにすぎず、長期的な選択には中央値と揺らぎの範囲が適しています。
最後に、3つの指標をそれぞれの用途に戻して考えましょう。ICMP pingは基礎回線の確認、実接続遅延は完全なプロキシ経路の応答性の判断、ダウンロード速度は継続的な転送能力の評価に使います。テスト対象、ルーティングモード、ローカルネットワークの条件を揃えれば、3つの数値は互いを否定するものではなく、ノードの通信経路を一緒に説明する指標になります。