VPN の速度実測で大事なのは、スピードテストサイトを開いて一度走らせることではなく、測定条件を固定し、今日の結果と来週の結果を同じ表に並べて比べられるようにすることです。レイテンシ、ジッタ、パケットロス、帯域という 4 項目はそれぞれ別の問いに答えるもので、夜間ピークの挙動は平常時と大きく変わります。以下では、どの指標を測るのか、どの時間帯に測るのか、何回測ってどの値を採るのか、結果をどう読むのか、そして各社の宣伝ページの数字がなぜ互いに比較できないのかを、再現できる手順として順に示します。
速度測定で測るべき指標とは
「速いかどうか」は漠然とした言い方で、分解すると少なくとも 4 つの別々に測れる量になります。レイテンシ、ジッタ、パケットロス、帯域です。これらは互いに換算できる関係ではなく、レイテンシが低い回線でも帯域は小さいことがあり、公称帯域が大きい回線でも夜間ピークには激しく揺れることがあります。4 項目を分けて記録して初めて、問題が物理距離にあるのか、経路の混雑にあるのか、それとも自宅側のネットワークにあるのかを判断できます。
| 指標 | 単位 | よく使う測り方 | 読み解くときの注意 |
|---|---|---|---|
| レイテンシ(RTT) | ミリ秒 | クライアント内蔵のレイテンシ測定、TCP ハンドシェイクの所要時間 | 物理距離が下限を決める。大陸をまたげば同一都市と同じ値にはならない |
| ジッタ | ミリ秒 | 連続 10 個以上のサンプル間の差分 | 中央値が良くてもジッタが大きいと通話は途切れる |
| パケットロス | パーセント | 連続プローブ、または TCP 再送の統計 | まずロスを見て、次にレイテンシ。順序は逆にしない |
| 下り / 上り帯域 | Mbps | シングルスレッドとマルチスレッドを各 1 回 | 結果が自宅回線プランの上限を超えることはない |
| DNS 解決の所要時間 | ミリ秒 | 新しいドメインへ初回アクセスするときの所要時間 | 解決がローカル経由かトンネル経由かで大きく変わる |
| 最初のバイトまでの時間 | ミリ秒 | ブラウザの開発者ツールのネットワークパネル | 接続先サイト側の影響も受けるので、すべてを回線のせいにはできない |
ICMP のプローブは一部のネットワークでレート制限されたり、そのまま破棄されたりします。ping が通らないことは回線が不通であることを意味しません。疎通の判断には TCP ハンドシェイクの所要時間やクライアント内蔵のレイテンシ測定のほうが信頼でき、ブラウザが実際に接続を確立する過程にも近いです。
まず測定条件を固定する
同じノードでも、端末が違えば、無線の周波数帯が違えば、バックグラウンドの負荷が違えば、実測値は倍ほど変わります。速度測定の第一歩は「開始」を押すことではなく、変数を固定することです。そうしなければ、後で出てくるデータは参考にはなっても根拠にはなりません。
- ✅ 最初から最後まで同じ端末・同じネットワークを使い、途中で Wi-Fi を切り替えず、モバイルデータにも切り替えない。
- ✅ 有線 LAN を優先する。無線しか使えない場合は 5GHz 帯に固定し、同じ場所から動かない。
- ✅ OS のアップデート、クラウドストレージの同期、オンライン動画など、バックグラウンドの通信を止める。
- ✅ 同じ比較グループの中では、クライアント、プロトコル、接続先ノードをそろえる。
- ✅ 測定のたびにタイムスタンプを記録し、夜間ピークと平常時は別々に集計する。
- ❌ ダウンロードしながら測定しない。測定の途中でノードを切り替えない。
プロトコルも固定します。VMess はクライアントとサーバーの時刻が一致していることが前提で、システム時刻がずれると単に遅くなるのではなくハンドシェイクが失敗します。Hysteria2 と TUIC は QUIC ベースで UDP を使うため、パケットロスの多い経路では TCP 系のプロトコルより安定するのが普通ですが、自宅側のネットワークが UDP を制限している場合は逆の結果になります。プロトコルを変えたら必ず別の行に記録し、前のグループと混ぜて平均を取らないでください。
時間帯の割り振り:夜間ピークは別の行に
国際回線の帯域は共有です。20:00 から 23:00 にかけては、地域の通信事業者の出口と国外方向が同時に混み合い、同じ回線でもこの時間帯の実測値は午前の半分ほどになることがあります。空いている時間帯だけで測ると、その日の最も良い数字が得られるだけで、実際に使いたい時間帯の姿とは一致しません。
推奨は、午前 10:00 をベースライン、午後 15:00 を第 2 のベースライン、21:00 を夜間ピークのサンプル、深夜 00:30 を対照とすることです。各時間帯で 3 回測り、回と回の間は 2〜3 分あけて中央値を採ります。平均値は 1 回の異常なサンプルに引っ張られやすく、最良値はページを開くときの日常的な状態を表しません。中央値は個々の外れ値に鈍く、日々の体感に近い値になります。
レイテンシ・ジッタ・パケットロスの読み方
光ファイバー中の光の速度は秒速約 20 万 km で、往復距離がそのままレイテンシの下限を決めます。アジア近隣国のノードなら往復 1〜2 千 km なので、理論上の下限は数十ミリ秒です。太平洋をまたぐと往復 2 万 km 以上になり、下限だけで 100 ミリ秒を超えます。同じスクリーンショットに「東京 30 ミリ秒」と「ロサンゼルス 30 ミリ秒」が並んでいたら、後者はほぼ間違いなく最寄りの入口を測った値で、実際の出口ノードではありません。
- 同一地域:30 ミリ秒以内。クリックやページ送りはほぼ無感覚。
- アジア近隣国:30〜80 ミリ秒。Web ページ、動画、ファイルのダウンロードは問題なし。
- 大陸間:120〜250 ミリ秒。ページは開くが、対戦型のリアルタイム操作には遅れを感じる。
- 300 ミリ秒超:クリックしてから応答までに明らかな待ちが生じる。
ここに挙げたのは経験的な参考レンジで、保証値ではありません。実際の結果は地域の通信事業者、回線種別、接続先サイトの位置にも左右されます。ジッタは隣り合うサンプルの差を見るもので、連続 10 サンプルの最大と最小が 50 ミリ秒離れていれば、中央値が 60 ミリ秒でも音声通話は途切れます。リアルタイムの音声・映像では、ジッタはレイテンシ以上に致命的です。パケットロス率は 1% 未満ならほぼ気にならず、3% を超えると動画にブロックノイズが出はじめ、Web ページもたまに読み込みに失敗します。10% を超えると実用になりません。ロスが出たら、まず回線種別を変え、そのうえでプロトコルの変更を検討してください。
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
date/slot:日付と時間帯。時間帯は固定値(10:00、15:00、21:00、00:30 など)で書き、列で並べ替えやすくする。node/protocol:ノードの都市とプロトコル名。ノードやプロトコルを変えたら新しい行に書き、古いデータを上書きしない。rtt_med_ms/jitter_ms:レイテンシの中央値とジッタ。それぞれ 10 個以上のサンプルを取る。loss_pct:パケットロスの割合。ロスがなければ 0 と書き、空欄にしない。空欄は後の集計で行が抜ける原因になる。down_mbps/up_mbps:下りと上りの帯域。シングルスレッドとマルチスレッドを各 1 回測り、備考にスレッド数を明記する。note:自宅回線のプラン、ピーク時間帯かどうか、そのときの異常(動画を同時再生していた等)。
記入の順序は次の 6 ステップに固定するとよい:
- 未接続の状態で 1 回測り、自宅回線のベースラインとする。
- 目標ノードに接続し、10 秒待って接続が安定してから開始する。
- レイテンシ測定を 3 回連続、各回 10 サンプル。中央値とジッタを記録する。
- 帯域はシングルスレッドとマルチスレッドを各 1 回、下りと上りを別々に記録する。
- 時間帯を変えて手順 1〜4 を繰り返し、結果は同じ表に追記する。
- 1 週間後に「夜間ピークの下り ÷ 午前の下り」で低下率を算出する。
低下率が 20% 以内なら通常の変動で、対応は不要です。20% から 50% は体感できる速度低下で、他の回線を比べ始める目安になります。50% を超えるなら、その回線はその時間帯にかなり混雑しているということなので、プロトコルをあれこれ変えて運に頼るのではなく、回線種別を変えるべきです。
結果の読み解きとよくある誤解
回線は直結・中継・専用線の 3 種類に分かれます。直結は地域の通信事業者からそのまま国外へ出るため経路が最短ですが、ピーク時間帯は変動が大きくなります。中継はまず中国国内の入口を経てから国外へ出るので経路は 1 ホップ増えますが、安定性はたいてい良くなります。専用線はポイントツーポイントのリンクを使うため、レイテンシも帯域も安定し、その分コストは高くなります。測定するときは都市別ではなく回線種別ごとに集計すると、傾向が見えやすくなります。回線一覧では各回線に種別が付いているので、そのまま照らし合わせて記録表を埋められます。
- ドメイン名に対して ping でレイテンシを測る:1 回目の結果は DNS 解決の時間を含むため高めに出て、2 回目以降が本当の往復時間です。
- Mbps を MB/s と取り違え、帯域が公称値の八分の一しかないと思い込む。
- スピードテストサイトでノードから遠く離れたテストサーバーを選んでしまい、測っているのはそのサーバーとノードの距離であって、自宅とノードの距離ではない。
- 深夜にしか測らず「速度は落ちない」と結論づけ、21:00 に使ったことが一度もない。
- ノードを変えた後にベースラインを取り直さず、新旧のデータを同じ表に混ぜて平均を取る。
速度測定の目的は、見栄えのよい数字を 1 つ見つけることではなく、「実際に使いたい時間帯にいちばん安定している回線」を見つけることです。同じ時間帯、同じノード、同じプロトコルで 3 回続けて測った中央値だけが、判断の根拠になります。