VPN の速度実測で大事なのは、スピードテストサイトを開いて一度走らせることではなく、測定条件を固定し、今日の結果と来週の結果を同じ表に並べて比べられるようにすることです。レイテンシ、ジッタ、パケットロス、帯域という 4 項目はそれぞれ別の問いに答えるもので、夜間ピークの挙動は平常時と大きく変わります。以下では、どの指標を測るのか、どの時間帯に測るのか、何回測ってどの値を採るのか、結果をどう読むのか、そして各社の宣伝ページの数字がなぜ互いに比較できないのかを、再現できる手順として順に示します。

速度測定で測るべき指標とは

「速いかどうか」は漠然とした言い方で、分解すると少なくとも 4 つの別々に測れる量になります。レイテンシ、ジッタ、パケットロス、帯域です。これらは互いに換算できる関係ではなく、レイテンシが低い回線でも帯域は小さいことがあり、公称帯域が大きい回線でも夜間ピークには激しく揺れることがあります。4 項目を分けて記録して初めて、問題が物理距離にあるのか、経路の混雑にあるのか、それとも自宅側のネットワークにあるのかを判断できます。

指標単位よく使う測り方読み解くときの注意
レイテンシ(RTT)ミリ秒クライアント内蔵のレイテンシ測定、TCP ハンドシェイクの所要時間物理距離が下限を決める。大陸をまたげば同一都市と同じ値にはならない
ジッタミリ秒連続 10 個以上のサンプル間の差分中央値が良くてもジッタが大きいと通話は途切れる
パケットロスパーセント連続プローブ、または TCP 再送の統計まずロスを見て、次にレイテンシ。順序は逆にしない
下り / 上り帯域Mbpsシングルスレッドとマルチスレッドを各 1 回結果が自宅回線プランの上限を超えることはない
DNS 解決の所要時間ミリ秒新しいドメインへ初回アクセスするときの所要時間解決がローカル経由かトンネル経由かで大きく変わる
最初のバイトまでの時間ミリ秒ブラウザの開発者ツールのネットワークパネル接続先サイト側の影響も受けるので、すべてを回線のせいにはできない

ICMP のプローブは一部のネットワークでレート制限されたり、そのまま破棄されたりします。ping が通らないことは回線が不通であることを意味しません。疎通の判断には TCP ハンドシェイクの所要時間やクライアント内蔵のレイテンシ測定のほうが信頼でき、ブラウザが実際に接続を確立する過程にも近いです。

まず測定条件を固定する

同じノードでも、端末が違えば、無線の周波数帯が違えば、バックグラウンドの負荷が違えば、実測値は倍ほど変わります。速度測定の第一歩は「開始」を押すことではなく、変数を固定することです。そうしなければ、後で出てくるデータは参考にはなっても根拠にはなりません。

プロトコルも固定します。VMess はクライアントとサーバーの時刻が一致していることが前提で、システム時刻がずれると単に遅くなるのではなくハンドシェイクが失敗します。Hysteria2 と TUIC は QUIC ベースで UDP を使うため、パケットロスの多い経路では TCP 系のプロトコルより安定するのが普通ですが、自宅側のネットワークが UDP を制限している場合は逆の結果になります。プロトコルを変えたら必ず別の行に記録し、前のグループと混ぜて平均を取らないでください。

時間帯の割り振り:夜間ピークは別の行に

国際回線の帯域は共有です。20:00 から 23:00 にかけては、地域の通信事業者の出口と国外方向が同時に混み合い、同じ回線でもこの時間帯の実測値は午前の半分ほどになることがあります。空いている時間帯だけで測ると、その日の最も良い数字が得られるだけで、実際に使いたい時間帯の姿とは一致しません。

4 つ 時間帯:午前・午後・夜間ピーク・深夜に各 1 回
3 回 各時間帯で 3 回繰り返し、最良値ではなく中央値を採る
10 個 レイテンシは最低 10 回連続でサンプリングして 1 組とする
1 枚 全時間帯を同じ表にまとめて初めて横比較ができる

推奨は、午前 10:00 をベースライン、午後 15:00 を第 2 のベースライン、21:00 を夜間ピークのサンプル、深夜 00:30 を対照とすることです。各時間帯で 3 回測り、回と回の間は 2〜3 分あけて中央値を採ります。平均値は 1 回の異常なサンプルに引っ張られやすく、最良値はページを開くときの日常的な状態を表しません。中央値は個々の外れ値に鈍く、日々の体感に近い値になります。

レイテンシ・ジッタ・パケットロスの読み方

光ファイバー中の光の速度は秒速約 20 万 km で、往復距離がそのままレイテンシの下限を決めます。アジア近隣国のノードなら往復 1〜2 千 km なので、理論上の下限は数十ミリ秒です。太平洋をまたぐと往復 2 万 km 以上になり、下限だけで 100 ミリ秒を超えます。同じスクリーンショットに「東京 30 ミリ秒」と「ロサンゼルス 30 ミリ秒」が並んでいたら、後者はほぼ間違いなく最寄りの入口を測った値で、実際の出口ノードではありません。

ここに挙げたのは経験的な参考レンジで、保証値ではありません。実際の結果は地域の通信事業者、回線種別、接続先サイトの位置にも左右されます。ジッタは隣り合うサンプルの差を見るもので、連続 10 サンプルの最大と最小が 50 ミリ秒離れていれば、中央値が 60 ミリ秒でも音声通話は途切れます。リアルタイムの音声・映像では、ジッタはレイテンシ以上に致命的です。パケットロス率は 1% 未満ならほぼ気にならず、3% を超えると動画にブロックノイズが出はじめ、Web ページもたまに読み込みに失敗します。10% を超えると実用になりません。ロスが出たら、まず回線種別を変え、そのうえでプロトコルの変更を検討してください。

読み解き 1:レイテンシが高く、ジッタが小さく、ロスが 0 なら、原因は物理距離にあります。プロトコルを変えても改善せず、より近いノードに変えるか、経路の短い回線種別に変えるしかありません。

1 回測っただけで結論を出すのが最もよくある誤りです。1 回の結果には回線の状態、瞬間的な混雑、自宅ネットワークの揺らぎという 3 つの要素が混ざっています。最低 3 回、各回 10 サンプルを取って初めて、数字は比較に耐えるものになります。

帯域:シングルスレッド・マルチスレッドと単位換算

シングルスレッドの帯域は 1 本の接続のスループットを決め、高ビットレートの動画視聴や大きなファイル 1 本のダウンロードはこれに依存します。マルチスレッドの帯域は総量を決め、複数タスクを同時に走らせるときに効いてきます。ブラウザのスピードテストサイトは通常いくつもの接続を同時に張るので数字が良く出ます。クライアント内蔵の測定はシングルスレッドか接続数を指定する形式が多く、数字は 1 つのアプリの体感に近くなります。どちらも測る必要がありますが、混ぜて比べてはいけません。

まず単位をそろえます。Mbps は 1 秒あたりのメガビット、MB/s は 1 秒あたりのメガバイトで、両者は 8 倍違います。100 Mbps はおよそ 12.5 MB/s です。ダウンローダーに表示された 12 MB/s を 12 Mbps と取り違えると、回線が公称値の一割しか出ていないと誤解してしまいます。

帯域の上限は 3 つの制約を受けます。自宅回線のプラン、ノード側の帯域配分、プロトコルのカプセル化オーバーヘッドです。実測の下りが自宅プランを超えることはなく、たいていはそれより一段低くなります。上りは一般に下りよりはるかに小さく、ビデオ会議が固まるときは下りを測り続けるのではなく、まず上りを見てください。

宣伝の数字が比較できない理由

2 つの速度の数字を並べて比べてよいかは、まず 4 つの条件がそろっているかで決まります。測定対象の位置、接続スレッド数、測定した時間帯、プローブ方式(ICMP か TCP かアプリケーション層か)です。この 4 つのうち 1 つでも違えば、結論は逆になり得ます。

よくある表記実際の意味再現に必要な条件
公称最大帯域最良の時間帯・最良ノードでのマルチスレッドピーク値同じ時間帯、同じノード、同じスレッド数
公称最小レイテンシ最寄りの入口、または最寄りノードへのプローブ値入口か出口か、どのプローブ方式かを明記
速度制限なし人為的な速度上限がないそれでも自宅回線と回線容量の制約は受ける
夜間ピークでも安定その時間帯の日中に対する落ち込みが小さい比較する時間帯とサンプル数を提示

あるサービスが宣伝ページで高いピーク値を掲げ、自宅でシングルスレッドで測るとそのごく一部しか出ないとしても、条件が違うので矛盾ではありません。判断するには条件をそろえて比べるしかありません。同じ時間帯、同じノード、同じプロトコル、同じスレッド数で測り、そのうえで夜間ピークの落ち込みがどちらが小さいかを見ます。

そのまま使える記録表

以下が記録表の見出しです。1 行が、ある時間帯の 1 回の測定に対応します。表計算ソフトでもプレーンテキストでもかまいませんが、大事なのは列を固定し、途中で列を増やさないことです。

date,slot,node,protocol,rtt_med_ms,jitter_ms,loss_pct,down_mbps,up_mbps,note

記入の順序は次の 6 ステップに固定するとよい:

  1. 未接続の状態で 1 回測り、自宅回線のベースラインとする。
  2. 目標ノードに接続し、10 秒待って接続が安定してから開始する。
  3. レイテンシ測定を 3 回連続、各回 10 サンプル。中央値とジッタを記録する。
  4. 帯域はシングルスレッドとマルチスレッドを各 1 回、下りと上りを別々に記録する。
  5. 時間帯を変えて手順 1〜4 を繰り返し、結果は同じ表に追記する。
  6. 1 週間後に「夜間ピークの下り ÷ 午前の下り」で低下率を算出する。

低下率が 20% 以内なら通常の変動で、対応は不要です。20% から 50% は体感できる速度低下で、他の回線を比べ始める目安になります。50% を超えるなら、その回線はその時間帯にかなり混雑しているということなので、プロトコルをあれこれ変えて運に頼るのではなく、回線種別を変えるべきです。

結果の読み解きとよくある誤解

読み解き 2:夜間ピークの下りが午前の三割まで落ち、レイテンシが倍でもパケットロスがほぼ 0 なら、典型的な共有帯域の混雑です。同じ種別の回線でノードを変えるより、直結から中継や専用線へ回線種別を変えるほうが効きます。
読み解き 3:レイテンシは正常、ロスは 0 なのに、シングルスレッドがマルチスレッドの十分の一しか出ない場合、ボトルネックは単一接続の速度制限かプロトコルのカプセル化オーバーヘッドにあり、ノードの遠近とは関係ありません。

回線は直結・中継・専用線の 3 種類に分かれます。直結は地域の通信事業者からそのまま国外へ出るため経路が最短ですが、ピーク時間帯は変動が大きくなります。中継はまず中国国内の入口を経てから国外へ出るので経路は 1 ホップ増えますが、安定性はたいてい良くなります。専用線はポイントツーポイントのリンクを使うため、レイテンシも帯域も安定し、その分コストは高くなります。測定するときは都市別ではなく回線種別ごとに集計すると、傾向が見えやすくなります。回線一覧では各回線に種別が付いているので、そのまま照らし合わせて記録表を埋められます。

速度測定の目的は、見栄えのよい数字を 1 つ見つけることではなく、「実際に使いたい時間帯にいちばん安定している回線」を見つけることです。同じ時間帯、同じノード、同じプロトコルで 3 回続けて測った中央値だけが、判断の根拠になります。