VPN の速度測定で結論を左右するのは、スピードテストサイトの画面ではなく、どの区間を・どの時間帯に・何回続けて測ったかです。同じ端末、同じサブスクリプションでも、測定先のサーバーを変えたり時間を1時間ずらしたりするだけで、結果は何倍も変わります。回線が嘘をついているのではなく、2回の測定がそもそも別の問いに答えているだけです。ここでは測定を3つの層・4つの指標・再現できる手順に分解し、回線同士の比較を意味のあるものにします。
まず条件を揃える:4つの指標がそれぞれ何を表すか
日常的に言う「回線が遅い」は、少なくとも4つの異なる量に対応します。遅延・ジッター・パケットロスは回線の品質、スループットは転送の結果です。4つのうちどれが悪化しても体感は「重い」になりますが、対処法はまったく別です。パケットロスなら回線を変える、ジッターならピーク時間帯を避ける、スループットが伸びないだけならシングルスレッドの問題で、回線の良し悪しとは関係しないこともあります。
| 指標 | 何を測るか | 悪化したときの体感 | 主な測り方 |
|---|---|---|---|
| 遅延 RTT | パケットが往復するのにかかる時間 | ページの初回表示が遅い、ゲーム操作にもたつきが出る | ping、mtr、クライアント内蔵の遅延表示 |
| ジッター(jitter) | 連続測定した遅延のばらつき幅 | 音声が途切れる、動画が突然止まる | 20 回以上連続で測り、最大値と最小値を比べる |
| パケットロス(loss) | 送信したパケットが届かなかった割合 | TCP は再送を繰り返してスループットが落ち、UDP はそのまま詰まる | ping と mtr のロス率を見て、TCP 側の挙動と照らし合わせる |
| スループット(throughput) | 単位時間あたりに実際に転送できたデータ量 | ダウンロードが遅い、高画質動画が繰り返しバッファリングする | マルチスレッドのスピードテスト、シングルスレッドのダウンロード、iperf3 |
帯域幅とスループットは別物です。帯域幅は回線の公称上限、スループットは端末で実際に得られた量であり、その間にはプロトコルのオーバーヘッド、サーバー側の速度制限、単一接続のウィンドウ制限、同じ回線を使う他のユーザーの占有があります。ですから Mbps という単位を見たら、それが帯域幅なのかスループットなのかを先に確認し、比較の根拠にしてよい数字かどうかを決めましょう。
ツール:3つの層に分けて測り、1つのWebスコアで結論を出さない
測定を3つの層に分け、それぞれに適したツールを使えば、結論は揺らぎません。層を混ぜて使うと、数字同士が食い違います。
| 層 | ツール | 何が分かるか | 限界 |
|---|---|---|---|
| リンク層 | ping、pathping(Windows)、mtr(Linux と macOS) | 遅延・パケットロス、どのホップから悪化するか | ICMP は制限・遮断されることがあるため、ロスは TCP 側の挙動と照らし合わせる |
| スループット層 | スピードテストサイト、iperf3 | マルチスレッドまたはポイントツーポイントの実効スループット | スピードテストサイトは近いサーバーを既定で選ぶため、数字は楽観的になりやすい |
| アプリ層 | 実際に対象のサイト・動画・ゲームを開く | 実際の体感と初回表示までの時間 | キャッシュが結果を汚すため、2回目の再生は回線の能力を表さない |
Web のスピードテストサイトはほとんどがマルチスレッド HTTP で動くので、その回線の上限を見るのに向いています。ただし既定では近いサーバーを選ぶため、出てくる数字は「最寄りの測定サーバーまでどれだけ速いか」であって、「使いたいサービスまでどれだけ速いか」ではありません。この2つの数字は同時に成り立ち、片方が高く片方が低くても、どちらも間違いではありません。
iperf3 はポイントツーポイントの検証に向いており、同時接続数と測定時間を指定できるので、ブラウザやスピードテストサイトの影響を排除できます。代わりに、両端に制御できるノードが必要です。日常の自己測定なら、マルチスレッドのスピードテストで上限を、シングルスレッドのダウンロードで下限を見て、両方の数字を記録するのが現実的です。
測定サーバーの位置が結論を決める
2つの回線を比べるときは、測定サーバー・テストファイル・同時接続数を完全に揃える必要があります。どれか1つでも変えたら、その数字は並べて比べられません。
時間帯と回数:2回の測定を比較可能にする
1回の測定はあくまで1つのサンプルです。国際回線の負荷にははっきりした時間帯の傾向があり、夜のピークと未明の差は、回線同士の差より大きいことがよくあります。ですから時間帯をまたぐ比較は傾向を見るために使い、同じ時間帯の中での横比較だけが順位付けの意味を持ちます。
- ピーク時と閑散時に1回ずつ測り、それぞれの中央値を記録する。
- 同じ回線で3回続けて測り、最大値ではなく中央値を採る。
- 毎回記録する:日付、回線名、プロトコル、クライアントのバージョン、シングルかマルチスレッドか。
- 回線を変えるときは変数を1つだけ動かし、端末・クライアント・測定サーバーは固定する。
- 測る前にサブスクリプションを更新し、ノード一覧が変わっていないことを確認する。
最大値で結論を出すのが最もよくある誤り
ピーク値はキャッシュ、短時間のバースト、あるいはたまたま誰もその回線を使っていなかったことから生まれます。1日の大半の体験を表すのは中央値です。
指標の読み方:数字から結論へ
数字が出たら、決まった順番で読むほうが、勘で判断するよりはるかに信頼できます。
- まずパケットロス。ゼロにならないロスが続くなら、クライアントの設定をいじるより回線を変えるのが先です。MTU を調整しても戻りません。
- 次にジッター。ジッターが遅延そのものに近いなら、回線が待ち行列を抱えている証拠で、多くは中継区間の混雑か共有帯域の使い切りです。
- 続いてスループット。遅延が正常でジッターも小さく、それでもスループットが伸びないなら、シングルスレッドの制限、サーバー側の速度制限、プロトコルのオーバーヘッドが疑わしいです。
- 最後に体感。初回表示までの時間、動画の再生開始、ゲーム内の操作レスポンスは、前の3項目の総合結果であり、長期的に追う価値がある唯一の指標です。
遅延の大きい回線には見落とされがちな仕組みがあります。単一の TCP 接続のスループットは帯域遅延積に制限されるため、遅延が大きいほど1本の接続で高帯域を使い切るのは難しく、複数の並列接続が必要になります。つまり「マルチスレッドなら出るがシングルスレッドでは出ない」のは正常な現象で、回線に問題があるとは限りません。
判断の順序:パケットロス → ジッター → スループット → 体感。前の項目を排除しないうちは、後の項目の数字に参考価値はありません。
プロトコルと回線種別で結果は変わる
プロトコルの違いは主に2点
1つはトランスポート層の選択です。Shadowsocks、VMess、VLESS、Trojan は主に TCP で通信し、UDP も転送できます。Hysteria2、TUIC は QUIC ベースで UDP を使います。パケットロスが目立つ回線では QUIC 系の輻輳制御のほうが積極的で復帰も速いですが、ネットワーク側で UDP が制限・遮断されている場合は逆に悪化します。この点は自己測定で「プロトコルがダメ」と誤判定されやすいところです。
もう1つはハンドシェイクとオーバーヘッドです。VMess はタイムスタンプ検証を伴うため、端末の時刻が大きくずれているとハンドシェイクに失敗します。VLESS 自体はステートレスで、XTLS と組み合わせると TLS の暗号化・復号を1回減らせるため、高帯域では CPU 負荷が低くなります。Trojan は標準 TLS に依存するので、通信の形は通常の HTTPS に近くなります。これらの差は低帯域ではほとんど測れず、帯域遅延積の大きい回線で初めて現れます。
回線種別:直結・中継・IEPL 専用線
- 直結。端末がそのまま出口に接続する方式で、遅延は国際出口の混雑度に左右され、夜のピークで最も変動します。
- 中継。いったん中継ノードに入ってから出口へ転送する方式で、中継区間の帯域が専有かどうかがピーク時の性能を直接決めます。
- IEPL 専用線。ポイントツーポイントの専用回線で、公衆の国際出口を通らないため遅延とパケットロスが最も安定しますが、コストも最も高くなります。
ですから同じ「地域」のノードでも、回線種別が違えば測定カーブはまったく別物になります。比較するときは回線種別も記録に残しましょう。そうしないとデータを使い回せず、来週また最初から測り直すことになります。
地域ごとに回線を切り替えるときに参照できる事実:100+ の国・地域をカバー、250+ の回線。同時接続デバイス数は無制限なので、端末を変えて測り直すときも再設定は不要です。30 日間の返金保証があるため、測ってみて合わなければそのまま返金できます。
誤判定を排除:よくある妨害要因
測定結果が狂うのは、多くが回線の問題ではなく、次のような手順の詰めが甘いためです。
- ✅ 測る前にサブスクリプションを更新し、同じ回線を測っていることを確認する。ノード名が変わったり IP が変わったりしたら、以前の結論は無効です。
- ❌ 分割ルールを有効にしたまま測る。一部の通信が直結経由になるため、結果に2つの経路の性能が混ざり、どちらが良いのか分からなくなります。
- ✅ ドメイン解決の経路を確認する。解決がローカルの回線事業者を通ると、近くの CDN ノードが返ることがあり、数字は良くても出口の品質を表しているとは限りません。
- ❌ 動画を1回再生しただけでスループットを判断する。キャッシュに当たった後は、再生の滑らかさと回線の能力は関係ありません。
- ✅ 同じクライアントの中で横比較する。クライアントごとに既定の MTU、UDP 転送のオン・オフ、分割ポリシーが異なるため、クライアントをまたいで数字を比べても意味がありません。
- ❌ 「加速率」「何パーセント改善」を指標にする。換算された数字には基準がなく、再現もできません。
DNS リークがあると測定結果は狂う
見分け方は簡単です。任意の DNS リーク検出ページを開き、解決サーバーの所在地が出口の地域と一致しているかを確認します。一致しなければ、ドメイン解決がプロキシを通っておらず、対象サイトへアクセスしたときに近くのノードへ振り分けられ、実際には別の経路を測っていることになります。分割ルールの中で DNS の扱いを確認し、解決をプロキシ側に任せてから、もう一度測り直しましょう。
再現できる自己測定の手順
次の手順を順番に実行すれば、結果を横比較でき、1週間後に測り直して安定性を見ることもできます。
- 変数を固定する。同じ端末、同じクライアント、同じ測定サーバーを先に決めてから始めます。
- サブスクリプションを更新する。回線名とプロトコルを記録し、以降の記録はすべてこの行を基準にします。
- リンク層を測る。20 個のパケットを連続で送って遅延とロスを見て、さらにホップごとの経路を確認し、問題がどの区間にあるかを特定します。
- スループット層を測る。マルチスレッドのスピードテストを1回、シングルスレッドのダウンロードを1回行い、2つの数字を別々に記録します。
- アプリ層を測る。実際に使うサービスを開き、初回表示までの時間とバッファリングの有無を記録します。
- 次の回線に切り替えて、3 から 5 の手順を繰り返します。変数は動かしません。
- 1 行の記録にまとめて、どの回線を残すか、どの時間帯にどれを使うかを決めます。
コマンドラインは2つで十分です。Windows では ping を ping -n 20 に、mtr を pathping に置き換えてください。ここでは公共の DNS サービスを参照点にしています。そのノードは通常近くにあり遅延が小さいためです。実際の対象の経路を判断したいときは、アドレスを実際にアクセスするドメインに置き換えますが、同じ比較の中では対象を必ず揃えてください。
# 遅延とパケットロス:20 個のパケットを連続送信し、平均遅延とロス率を見る
ping -c 20 1.1.1.1
# ホップごとの経路:各ホップ 50 個のパケットで、ロスがどの区間で起きているかを特定する
mtr -rwc 50 1.1.1.1結論:変数を固定してこそ1回の測定に意味があり、記録を残してこそ回線を選ぶ根拠が生まれます。数字は順位付けに使い、絶対的な判断には使いません。
よくある質問
測定値が宣伝よりずっと低いのですが、回線の問題ですか?
まず3点を確認してください。測定サーバーが同じか、シングルスレッドか、測った時間が夜のピークか。3点を揃えてから比較します。マルチスレッドの測定は上限寄り、シングルスレッドのダウンロードは下限寄りで、もともと違う値を示します。
スマートフォンとパソコンで同じ回線を測ると結果が違うのはなぜですか?
両端でクライアントの実装が異なり、既定の MTU、UDP 転送のオン・オフ、分割ルールも違うことがあります。無線ネットワーク自体がジッターを持ち込むこともあります。比べるなら同じ端末・同じクライアントの中で比べてください。
使うたびに毎回測る必要がありますか?
いいえ。回線を選ぶ段階で集中的に1回測って記録を残し、その後は体感がはっきり変わったときだけ測り直します。たとえばネットワーク環境を変えたとき、クライアントのバージョンを変えたとき、決まったピーク時間帯に入ったときなどです。
測定中は自宅の他の機器の電源を切るべきですか?
はい。同じ出口でのダウンロード、バックアップ、動画再生は帯域を占有します。特に共有型の回線では影響が大きくなります。回線そのものの品質を測りたいなら、測定中は他の通信を止めてください。