複数のVMess、VLESSノードがあり、どの測定結果を見ればよいかわからない人向けの記事です。pingは基礎的なネットワーク経路、実接続遅延はプロキシリクエストの応答性、ダウンロード速度は継続的な転送性能を確認します。ノード選びでは、数値が最小の項目だけでなく、用途に応じて3つの結果を組み合わせて判断しましょう。
3種類の測定は同じ経路を測っていない
測定値の見方
ping、実接続遅延、ダウンロード速度はノード一覧に並んで表示されることがありますが、それぞれ測定する階層が異なります。pingは通常、ICMP Echoリクエストを送り、端末からサーバーアドレスまでのネットワーク往復時間だけを確認します。V2RayやXrayのプロキシセッションは開始せず、VMess、VLESSの認証情報、TLSハンドシェイク、転送経路、プロキシ出口も検証しません。
測定値の見方
実接続遅延では、クライアントが指定したノードを通じて実際のプロキシリクエストを1回送信します。v2rayN 7.xの一般的な動作では、コアの起動、ノード設定の読み込み、TCPなどの転送接続の確立、プロトコル認証、テスト先へのアクセスが必要です。成功時に表示されるミリ秒数は、ウェブページを開く際の最初のリクエストが待機する時間に近い値です。
測定値の見方
ダウンロード速度の測定では、接続確立後に一定量のデータを継続して受信します。往復遅延だけでなく、サーバーの出口帯域、回線混雑、TCP輻輳制御、パケットロスによる再送、ローカルネットワーク、テストファイルのサイズにも左右されます。実接続遅延が180 msでも150 Mbps出るノードがある一方、遅延が80 msでも出口速度の制限により12 Mbpsしか出ないノードもあります。
| 測定方法 | 主な測定対象 | プロキシプロトコルを経由するか | 何を判断するための測定か |
|---|---|---|---|
| ICMP ping | 端末からサーバーアドレスまでのネットワーク往復 | いいえ | 基礎経路に到達できるか、揺らぎが目立つか |
| 実接続遅延 | 接続確立、ハンドシェイク、認証、プロキシリクエスト | はい | ウェブページの最初のリクエストにかかる待ち時間 |
| ダウンロード速度 | 接続確立後の継続スループット | はい | 大容量ファイルや動画をどの程度の速度で転送できるか |
pingが低くてもノードが遅いことがある理由
測定値の見方
よくある誤りは、pingの値が小さい順に並べて先頭のノードをそのまま選ぶことです。あるサーバーのICMP往復時間が24 msでも、わかるのはサーバーアドレスが現在のネットワークから近いということだけです。プロキシリクエストはTLS、WebSocket、中継入口、別の出口回線を通る場合があり、実際に目的のサービスへアクセスする経路がICMPと完全に一致するとは限りません。
測定値の見方
ネットワークによってはICMPリクエストが制限されたり、優先度を下げられたりします。サーバーがICMPに応答しない場合もあります。このときpingがタイムアウトしても、VMessやVLESSのポートに接続できないとは限りません。逆に、ICMPが安定して応答しても、購読設定のポート、UUID、転送経路、Server Name、Realityパラメータが正しいとは限りません。これらの設定項目を確認できるのは、実接続テストです。
測定値の見方
低いpingだけでは、パケットロスによる速度低下もわかりません。継続ダウンロードでは大量のパケットが連続して届く必要があり、1～3%のパケットロスでも再送や輻輳ウィンドウの縮小が起こることがあります。短いICMPのサンプルでは30 msに見えても、継続転送では速度が80 Mbpsから周期的に15 Mbpsまで落ちる場合があります。ウェブページでは、ファーストビューは速く表示されるのに画像や動画の読み込みが遅い、という症状になります。
結論：ノードの並べ替えでは実接続結果を優先する
ウェブ閲覧、メッセージング、短い接続の頻繁な確立が目的なら、まず実接続がタイムアウトするノードを除外します。その後、遅延が近いノード同士で揺らぎとダウンロード速度を比較しましょう。ICMPの最小値だけを最終判断の基準にするべきではありません。
実接続遅延に含まれる時間の内訳
測定値の見方
実接続遅延は単純なネットワーク往復時間ではなく、複数の段階にかかった時間の合計です。ドメイン名を使うノードでは、まずDNS名前解決を行います。続いてサーバーのポートへの接続を確立し、TLSやRealityを使う場合は対応するハンドシェイクも実行します。その後、コアがVMessまたはVLESSの認証を行い、プロキシ出口からテストリソースへアクセスします。どこかで再試行が発生すると、最終的な数値は大きく増加します。
測定値の見方
転送方式の組み合わせによって、固定的なオーバーヘッドも異なります。VLESSとVMessはプロキシプロトコル、TCPやWebSocketなどは転送設定、TLSとRealityは対応するハンドシェイクや接続特性を担います。プロトコル名だけで速さを判断することはできず、実際の結果はサーバー負荷、経路品質、設定の一致、測定時間帯に左右されます。
VLESS + TCP + Reality
- 主なオーバーヘッド
- TCPとRealityのハンドシェイク
- 認証段階
- VLESSユーザー識別子の検証
- 確認ポイント
- 実接続結果を3回連続で測定
- 異常のサイン
- タイムアウト、または数値が100 msを超えて急変する
購読設定を取り込んだ後は、サーバー名、ポート、Flow、Server Name、公鍵、短い識別子の対応関係を維持してください。
VMess + WebSocket + TLS
- 主なオーバーヘッド
- TCP、TLS、WebSocketの接続確立
- 認証段階
- VMessユーザー情報の検証
- 確認ポイント
- 初回と後続結果の差
- 異常のサイン
- 経路エラーまたはTLSハンドシェイクの失敗
ドメイン、ポート、Host、パス、TLSパラメータはすべて一致している必要があります。どれか1つでも誤っていると、実接続のタイムアウトとして現れることがあります。
測定値の見方
初回の測定は、後続の測定より遅くなることがあります。初回だけDNS問い合わせ、コアの起動、接続のウォームアップが含まれる場合があるためです。候補ノードは3回連続で測定し、明らかな初回起動分を除外して中央値を比較するのが確実です。たとえば結果が210、126、132 msなら、210 msをそのまま記録するのではなく、約132 msを代表値と考えられます。
v2rayNとAndroidクライアントでの測定方法
測定値の見方
デスクトップ版はノードの一括比較に適しています。購読設定を取り込み、グループを更新したら、まずローカルネットワークが安定していることを確認してから実接続テストを実行します。測定中に大容量ファイルのダウンロードやシステム更新を同時に行うと、ローカル帯域の競合で結果が歪みます。テスト先自体の応答が不安定な場合は、複数回の結果も一緒に変動します。
- v2rayN 7.xのメイン画面で、同じ購読グループ内の候補サーバーを選択します。最初は5～10個のノードに絞り、同時測定による干渉を避けましょう。
- 「サーバー」メニューを開き、「サーバーの実接続遅延をテスト」を選択します。マイナーバージョンによっては、サーバー一覧の右クリックメニューから同名のテスト項目を選べます。
- 遅延列が更新されるまで待ち、タイムアウトや接続失敗と表示されたノードを削除または一時的に無視します。その後、数値の低い3つを選び、さらに2回ずつ再測定します。
- 「設定」→「パラメータ設定」を開き、実接続テストのアドレスとタイムアウト時間を確認します。テスト先は小さなサイズのレスポンスを安定して返すHTTPステータスにし、ファイルのダウンロード時間が遅延に混ざらないようにします。
- 候補ノードを選択してアクティブサーバーに設定し、システムプロキシを有効にします。そのうえで、実際に使うブラウザーやダウンロード作業で最終確認を行います。
測定値の見方
v2rayNでよく使われるローカルSOCKS待受ポートは10808です。一部の設定ではHTTP入口に10809を使用しますが、具体的な値は「設定」→「パラメータ設定」のローカル待受設定を確認してください。ポートは端末上のアプリをプロキシへ接続するためのもので、ノードサーバーのポートではありません。ローカルポートを変更しても、リモートノードの遅延は下がりません。
測定値の見方
Androidでは、v2rayNGがXrayコア、v2flyNGがv2flyコアを使用します。どちらもノード一覧から遅延を測定できますが、メニュー名や測定方法はバージョンによって変わります。Wi-Fiとモバイル回線を切り替えると、以前の接続が無効になることがあります。ネットワークを切り替えた後は現在の設定を再起動して測定し、切り替え前の数値をそのまま使わないでください。
- 測定前に帯域を継続的に使用するタスクを停止し、画面を点灯したままにして、システムがバックグラウンドのネットワーク処理を一時停止しないようにします。
- 同じノードを少なくとも3回測定し、中央値を記録します。20 ms、180 ms、24 msという結果なら、1回だけ大きく揺れていると判断できます。
- クライアントを比較するときは、同じネットワーク、同じノード、同じ時間帯を使います。家庭の固定回線とモバイル回線の結果をそのまま比較してはいけません。
- デスクトップ版では成功するのにAndroid版でタイムアウトする場合は、まず購読設定が同じバージョンに更新されているか確認し、次にコアログのハンドシェイクとDNS情報を確認します。
ダウンロード速度を実際の使用感に換算する方法
測定値の見方
ダウンロード速度は、単位時間に転送できるデータ量を示します。測定ツールでは毎秒メガビットを表すMbps、ブラウザーのダウンロード表示では毎秒メガバイトを表すMB/sがよく使われます。換算時は8で割ります。80 Mbpsは理論上約10 MB/s、100 Mbpsは約12.5 MB/sです。プロトコルのオーバーヘッド、再送、ディスクへの書き込みにより、実際の数値は少し低くなります。
測定値の見方
短時間の測定では、接続のウォームアップや瞬間的なバーストを長期的な性能と取り違えやすくなります。ノードを比較するなら、少なくとも20～30秒測定し、平均速度と最低速度を同時に確認してください。たとえば最初の3秒だけ160 Mbpsで、その後45 Mbpsで安定するノードは、45 Mbps程度のノードと考えるのが適切です。瞬間的なピーク値は長時間のダウンロード性能を表しません。
| 利用シーン | 優先する指標 | 判断の目安 |
|---|---|---|
| ウェブ閲覧と短いリクエスト | 実接続遅延、揺らぎ | 3回連続の中央値が低く、タイムアウトがない |
| 高画質動画 | 継続ダウンロード速度、最低速度 | 30秒間の推移を確認し、ピーク値だけを見ない |
| 大容量ファイルの転送 | 平均スループット、パケットロス、安定性 | 長時間の測定で速度が周期的にゼロにならない |
| リモート操作 | 実接続遅延、揺らぎ、パケットロス | 50～300 msを繰り返す接続より、安定した120 msのほうが通常は快適 |
測定値の見方
ノードの帯域と、ローカル回線の帯域も分けて考える必要があります。ローカル回線の上限が100 Mbpsなら、複数のノードが92～95 Mbpsに集中しても、ボトルネックはローカル回線にある可能性が高く、ノードの出口上限とは判断できません。ローカルネットワークが空いているときの直通測定が500 Mbpsで、プロキシ経由では長時間40 Mbpsしか出ない場合に、サーバーの出口、回線混雑、ノードの速度制限を詳しく調べる価値があります。
結論：スループットは安定区間で判断し、単発のピーク値は見ない
測定時間を30秒まで延ばし、後半20秒の平均値を記録します。平均82 Mbps、最低74 Mbpsのノードは、ピーク180 Mbpsを出しても後半に8 Mbpsまで何度も落ちるノードより、継続ダウンロードや動画再生に適しています。
再現性のあるノード選びの手順
測定値の見方
測定の目的は、1つの数値が最小のノードを探すことではなく、再現性のある選別手順を作ることです。まず設定が使えることを確認し、用途に応じて候補を絞り、最後に実際の作業で再確認します。これにより、サーバーの一時的な負荷、テスト先の変動、ローカルネットワークの帯域占有による誤判定を避けられます。
- 第1段階は到達性：実接続テストを実行し、認証失敗、ハンドシェイク失敗、継続的なタイムアウトが発生するノードを除外します。pingがタイムアウトしても実接続に成功するノードは残して構いません。
- 第2段階は応答性：残ったノードを3回連続で測定し、中央値と最大偏差を比較します。中央値の差が20 ms未満なら、より小さな数値だけを求めて頻繁に切り替える必要はありません。
- 第3段階はスループット：候補上位3ノードで30秒間のダウンロード測定を行い、平均Mbps、最低Mbps、途中で停止するような瞬断がないかを記録します。
- 第4段階は実際の作業：普段使うウェブページを開き、いつも見る画質の動画を再生するか、実際のダウンロードを行い、少なくとも5分間確認します。
- 第5段階は時間帯別の再測定：平日の混雑時間帯と空いている時間帯に1回ずつ測定します。夜間だけ大きく低下するノードは、昼間の結果をそのまま使わず、利用時間帯に合わせて判断します。
測定値の見方
実用的な記録例として、ノードAは実接続中央値96 ms、30秒平均62 Mbps、最低55 Mbps、ノードBは実接続中央値148 ms、平均118 Mbps、最低103 Mbpsとします。ウェブ閲覧ならA、大容量ファイルのダウンロードならBを優先できます。「最速ノード」は用途によって変わり、状況を離れて決められる唯一の答えはありません。
よくある速度測定の疑問と対処法
pingはタイムアウトするのに、ノードには正常に接続できるのはなぜ？
測定値の見方
サーバーや途中のネットワークがICMPに応答していない可能性があります。実接続テストと実際のプロキシリクエストを基準にし、3回の測定が安定しているかも確認してください。pingがタイムアウトしただけでノードを削除しないようにしましょう。
実接続遅延が初回だけ500 msで、後は120 msなのはなぜ？
測定値の見方
初回の結果にはDNS問い合わせ、コアの起動、接続のウォームアップが含まれることがあります。3回連続で測定して中央値を取りましょう。毎回、各測定の初回だけ異常に遅い場合は、DNS設定とコアログを確認します。
遅延は70 msなのに、ダウンロード速度が2 MB/s未満なのはなぜ？
測定値の見方
70 msはリクエストへの応答が速いことを示すだけです。サーバーの出口帯域、ローカル帯域、夜間の混雑、パケットロスを確認し、少なくとも30秒間の継続ダウンロード測定を行ってください。2 MB/sは約16 Mbpsです。
同じノードなのにv2rayNとv2rayNGで結果が違うのはなぜ？
測定値の見方
まず、両方で同じ購読項目、同じネットワーク、同じ測定時間帯を使っているか確認します。次にテスト先、DNS、コアのバージョン、転送パラメータを確認してください。テスト先が異なる数値を直接比較することはできません。
一括測定の後、すべてのノードが同時に遅くなったのはなぜ？
測定値の見方
同時測定によってローカルの接続数を使い切ったり、サーバーに一時的な負荷がかかったりすることがあります。候補を5～10ノードに絞り、他のダウンロードを停止して、30秒間隔を空けて分けて再測定してください。
測定値の見方
最後に、次の原則を覚えておきましょう。pingは基礎経路の確認、実接続遅延はプロキシ経路全体の応答確認、ダウンロード速度は継続的な転送性能の評価に使います。3つの結果は互いに補完し合うもので、どれか1つだけでノードの品質全体を表すことはできません。同じネットワーク、同じテスト先、同じ時間帯、同じ測定時間を使ってこそ、結果を比較できます。