複数のノードを管理しているユーザー向けに、ping と Tcping、実接続遅延、ダウンロード速度測定という3種類の数値について、それぞれの測定対象・誤差の要因・桁の違いを整理し、「日常的なノード選び」と「回線のトラブルシューティング」という2つの場面での判断手順を示します。あわせてよくある4つの誤解も挙げます。読み終われば決まった順序でノードを絞り込めるようになり、感覚で切り替える必要はなくなります。
3つの数値はそれぞれ何を測っているのか
ping が測るのは、本機から対象サーバーまでの ICMP の往復時間1回分です。Tcping は同じ経路上の TCP の往復時間1回分を測ります。どちらも「本機からサーバーまで」の区間だけを対象とし、プロキシプロトコルには入らず、サーバー側がトラフィックを正常に転送しているかどうかまでは判定しません。
実接続遅延が測るのは経路全体です。TCP 接続の確立、TLS ハンドシェイクの完了、VMess や VLESS のプロトコルハンドシェイクを経て、最初の有効なレスポンスバイトを受け取るまでを含みます。この数値にはサーバー側の処理時間も含まれるため、ping より大きくなるのは正常なことであり、ノードに問題があるわけではありません。
ダウンロード速度測定が測るのはスループットで、単位は MB/s または Mbps です。単位時間あたりにどれだけのデータを運べるかを示します。これは遅延とは別の次元の指標です。40 ms のノードが 3 MB/s しか出ないことも、180 ms のノードが 20 MB/s 出ることもあり、どちらも珍しくありません。
| 数値 | 測定対象 | 対象範囲 | 一般的な目安 | 主な誤差要因 |
|---|---|---|---|---|
| ping / Tcping | ネットワークの往復1回 | 本機からサーバー IP まで | 10~300 ms | ICMP の帯域制限、ハンドシェイクの待ち行列 |
| 実接続遅延 | ハンドシェイクから初回バイトまで | 本機からアウトバウンド完了まで | ping より 30〜150 ms 高い | サーバー負荷、TLS ネゴシエーション、プロトコルハンドシェイク |
| ダウンロード速度測定 | 単位時間あたりのスループット | 経路全体で使える帯域 | 1~50 MB/s | 測定ファイルの設置場所、シングルスレッドの制限、ローカル回線の上限 |
ping と Tcping の測定範囲
Tcping は ICMP の ping よりも実際の利用場面に近い指標です。プロキシ接続そのものが TCP 上に構築されるためです。ICMP は多くの回線で帯域制限や優先度の引き下げを受け、そのまま破棄されることさえあります。そのため「ping は通らないがノードは使える」という状態は矛盾ではありません。
逆もまた成り立ちます。ping の数値が低くてもノードが使えるとは限りません。サーバーが 443 番ポートだけを開放し、ICMP とその他のポートがすべて無応答という場合、Tcping 443 は結果が返り ping は無応答になりますが、これは故障ではなく正常な設定です。
- 分かること:本機からこのサーバーまでの経路の往復時間、パケットロスの有無、ジッターが続いているかどうか。
- 分かること:サーバーの該当ポートが待ち受けているか、TCP ハンドシェイクが途中で遮断されていないか。
- 分からないこと:サーバー側のプロセスが正常に転送しているか、プロトコルハンドシェイクが成功するか。
- 分からないこと:ノードの実際のスループット、サーバー側で帯域制限されていないか。
実接続遅延
おすすめハンドシェイクから初回バイトまでの流れ全体をカバーし、日常的に Web ページを開いたり API を読み込んだりするときの体感にもっとも近い指標です。
向いている場面:日常的なノード選び、ノードが正常に使えるかの判断
ping / Tcping
回線層の往復だけを見るため数値が素直で測定も速く、回線の問題を切り分けるのに最適です。
向いている場面:ローカルネットワークとサーバー間の回線品質の切り分け
ダウンロード速度測定
単位時間あたりのスループットを測る指標で、応答速度ではなく帯域を反映します。1回の測定で実際の通信量を消費します。
向いている場面:大容量ファイルのダウンロードや動画向けの帯域選別
実接続遅延が ping より高くなる理由
実接続遅延には少なくとも3回の往復が含まれます。TCP の3ウェイハンドシェイクが1回、TLS ハンドシェイクが1〜2回(TLS 1.3 を有効にすると通常1回)、プロトコルハンドシェイクと初回バイトで1回です。往復のたびに経路の RTT が積み重なるため、経路そのものが 100 ms の場合、実接続遅延が 250〜400 ms になるのはよくある範囲です。
判断の基準は絶対値ではなく、同じグループのノード内での相対的な順位と、同じノードを複数回測ったときの変動幅です。地域をまたいだノード同士で絶対値を比べても意味は限定的で、同じ都市にある2台のサーバーなら直接比較に向いています。
おすすめの使い分け:デスクトップ側とモバイル側それぞれの測定入口
デスクトップ(v2rayN)
- ノード一覧を右クリック → 「サーバーの Tcping 遅延をテスト」
- 右クリック → 「サーバーの実接続遅延をテスト」
- 速度テスト項目、またはツールバーの「速度テスト」でダウンロード速度測定を実行
Android 版(v2rayNG)
- ノード右側のメニュー → 「実接続遅延をテスト」
- メニューから全ノードを一括テスト可能
- 帯域の選別はデスクトップ側で行い、通信量を抑える
両端末で測った実接続遅延は近い値になり、10〜30 ms の差は正常な範囲です。両方の数値を完全に一致させる必要はありません。
ダウンロード速度測定の3つの前提
ダウンロード速度測定はもっとも誤差が出やすい項目です。既定の測定ファイルは海外にあることが多く、手元の回線が 100 Mbps しかなければ上限は 12.5 MB/s となり、どれだけ速いノードでもそれを超えられません。測定前にローカル回線で直接ベースラインを1回測っておけば、ボトルネックがノード側かローカル側かを判断できます。
v2rayN の測定ファイルの URL は「設定」→「パラメータ設定」でより近い場所のアドレスに差し替えられ、測定結果が実際に使える帯域に近づきます。測定に使ったノードは実際にデータを転送する点が、遅延テストとはまったく異なります。
注意
ダウンロード速度測定は実行するたびに、測定ファイルのサイズ分の通信を実際に行います。10 MB の測定ファイルをノード数分となると、従量課金のプランでは数分で数百 MB を消費します。ノードの絞り込みは実接続遅延を優先し、最終的に残った2〜3個だけをダウンロード速度測定にかけましょう。
- まずローカル回線で直接ベースラインの帯域を1回測り、比較用の数値として記録します。
- 候補ノードに対して順にダウンロード速度測定を実行し、シングルスレッドで基準に届かなければマルチスレッドも試します。
- 測定ファイルを近場からアクセスできるアドレスに変え、国境をまたぐ経路の影響を減らします。
- 直接接続のベースラインの 70% 以上出ていれば、その回線のスループットは合格と見なせます。
判断の順序:パケットロスから帯域へ
3種類の数値には決まった使用順序があり、順序を入れ替えると正反対の結論になります。たとえば先にダウンロード速度測定を見ると、帯域は大きいが遅延も大きいノードが上位に来てしまい、日常のブラウジングはかえって遅くなり、またノードを切り替える羽目になります。
- まず Tcping のパケットロス率を見ます。5% を超えるノードはその時点で除外し、遅延の数値は参考にしません。
- 次に実接続遅延の変動を見ます。同じノードを3回更新して中央値を取り、変動が 50% を超えるものは候補に降格します。
- 実接続遅延の中央値で並べ、上位3つを次の段階に進めます。
- 上位3つにダウンロード速度測定を行い、用途で取捨選択します。Web ページや API なら遅延の低いもの、大容量ファイルや動画ならスループットの高いものを選びます。
- 接続後も Web ページが遅い場合は、ノードをさらに切り替えるのではなく、まず DNS とルーティングルールを確認します。
結論:まずパケットロス、次に遅延、最後に帯域
パケットロス率が 5% を超えるノードは、遅延の数値がどれだけ低くても使えません。実接続遅延の変動が 20% 未満のノードだけがダウンロード速度測定に進む価値があります。3ステップの順序を入れ替えると、絞り込みの結果はほぼ必ず逆になります。
よくある4つの誤解
| よくある誤解 | 実際のところ |
|---|---|
| ping が低ければ速い | ping は本機からサーバーまでの区間しかカバーせず、プロトコルハンドシェイクや転送の所要時間は含まれません |
| ダウンロード速度測定が速ければ Web 閲覧にも向いている | スループットと遅延は別の次元で、Web ページの読み込みは遅延と DNS 解決により依存します |
| 最小値だけを見て変動を見ない | 最小値は回線が空いている一瞬に出ることが多く、中央値こそが平常時の値を示します |
| システムプロキシを有効にしたまま測るほうが正確 | クライアント内蔵の測定はシステムプロキシを通らず、プロキシの影響を受けるのはブラウザ内で測る場合だけです |
これら4つの誤解に共通するのは、次元の異なる数値を混ぜて並べてしまうことです。「回線・ハンドシェイク・スループット」という3つの層にそれぞれ対応する数値があると覚えておけば、ノード選びで単一の数字に振り回されることはなくなります。
結論:同じノードを3回測り、最小値ではなく中央値を見る
最小値は回線が空いている一瞬に出ることが多く、平常時の値ではありません。3回測って中央値を取り、同じグループのノードと横並びで比較すれば、絞り込みの結果が安定し、次回も同じ結果を再現しやすくなります。
速度測定のよくある質問
実接続遅延が ping より大幅に高くなるのはなぜですか?
実接続遅延には TCP ハンドシェイク、TLS ハンドシェイク、プロトコルハンドシェイクが含まれ、追加の1.5〜3回の往復分だけ経路の RTT が積み重なります。30〜150 ms 高くなるのは正常な範囲です。差が長期的に安定していれば、サーバー側の処理は正常です。
同じノードで更新するたびに遅延が大きく違うのは正常ですか?
±20% 以内の変動なら正常です。50% を超える場合やタイムアウトが頻発する場合は、まずローカルネットワークを確認し、そのうえで回線の輻輳を疑います。このようなノードは候補に降格し、メインで使わないようにしましょう。
ダウンロード速度測定は速いのに Web ページが遅いのはなぜですか?
スループットと遅延は別の次元です。Web ページの表示はハンドシェイク遅延と DNS 解決により依存するため、実接続遅延のより低いノードに切り替え、ドメイン解決が遠回りしていないかも確認しましょう。
測定の前にシステムプロキシを切るべきですか?
必要ありません。v2rayN と v2rayNG 内蔵の測定はクライアント自身が実行するためシステムプロキシを通りません。プロキシの影響を受けるのは、ブラウザで速度測定サイトを開く場合だけです。
速度測定でノードの通信量は消費されますか?
消費されます。Tcping と実接続遅延はハンドシェイクのみなので通信量はごくわずかです。一方、ダウンロード速度測定は測定ファイルを実際に転送するため1回あたり 10 MB 程度になります。従量課金のノードでは最終的に残した2〜3個だけを測ることをおすすめします。