VPN速度実測のやり方：自分で客観的に測る方法・ツールと時間帯

VPN速度の実測はどうやるのか——まず前提を受け入れてください。1回の測定はあくまで1つのサンプルで、結論ではありません。同じ回線でも、午前と夜のピークではまったく違う数字が出ることがあります。ツールを変え、測定サーバーを変えれば、また差が出ます。ある回線が自分の用途を満たすかどうかを判断するには、変数を固定し、時間帯を分けて繰り返し測り、しかも遅延・ジッター・パケットロス・スループットの4指標を同時に見る必要があります。以下の手順は専門知識がなくても、OS 標準のコマンドとよくあるツールだけで実行できます。

まず4つの指標を区別する：遅延、ジッター、パケットロス、スループット

測定ページで一番目立つ数字はスループットにすぎず、「なぜ動画がカクつくのか」には答えてくれません。4つの指標にはそれぞれ役割があり、1つ欠けるだけで誤判定につながります：

• 遅延（RTT）：パケットが端末から対象サーバーまで往復するのにかかる時間で、単位はミリ秒。プロキシを経由すると、この往復には「端末 → 出口ノード → 対象」の2区間が含まれるため、直結より大きくなるのが自然です。したがって同じ対象・同じツール同士での横比較にとどめてください。
• ジッター：連続する複数パケットの遅延のばらつき幅。動画がカクつくか、音声が途切れるかは、平均遅延よりもジッターの方が重要です。平均遅延が低くてもジッターが大きいと、体感は安定したやや高めの遅延より悪くなります。
• パケットロス：送信したパケットのうち到達しなかった割合。わずかなロスでも再送が発生し、スループットが下がります。QUIC ベースのプロトコルはロスへの対処が TCP と異なるため、挙動も変わります。
• スループット：単位時間あたりに実際に転送されたデータ量。シングルスレッドとマルチスレッドを区別してください。シングルは単一ファイルのダウンロードや1本の動画再生の体感に近く、マルチは速度測定サイトのスコアに近くなります。

測定前に変数を固定する：端末、プロトコル、接続方法

測定結果に紛れ込みやすいのは、回線の違いよりも自分側の変数です。同じノードでも、端末を変え、プロトコルを変え、無線に変えるだけで数字が大きく変わることがあります。テストの前に、次の項目を固定しておきましょう：

• 端末とネットワーク：同じ端末・同じ回線で、できれば有線。無線を使う場合は周波数帯と位置を固定し、途中で変えない。
• バックグラウンド通信：OS の更新、クラウドストレージの同期、クラウドバックアップを止め、他の端末も大容量通信を一時停止する。
• プロトコル：Shadowsocks、VMess、VLESS、Trojan は TCP、Hysteria2、TUIC は QUIC ベースで UDP を使います。同じノードでもプロトコルによって挙動が異なり、国際回線でパケットロスが出ると差がより顕著になります。ノードを比較するときは、ノードとプロトコルを同時に変えないでください。
• 多重化（mux）：複数の接続を1本の TCP 接続に束ねる仕組みで、パケットロスが起きると head-of-line blocking（先頭詰まり）の影響を受けやすく、シングルスレッドのスループットが低くなります。全条件でオフに揃えるか、全条件でオンに揃えるかして、混在させないでください。
• ルールモード：分流モードでは、測定対象が直結ルールに一致していると、実際に測っているのは直結の速度です。テスト前に、対象がプロキシ経由になっているか確認してください。

よく使うツールと、それぞれ何の測定に向くか

ツールは数より、各指標に対応する測り方があるかが大事です。以下は遅延からスループットまでのチェック項目をカバーしています。2〜3個を組み合わせて使えば十分です：

時間帯の選び方：夜間ピークと空いている時間帯で何回ずつ測るか

国際回線の負荷にははっきりした時間帯の特徴があります。平日 20:00–23:00 はたいてい夜のピークで、国際出口が最も混雑し、遅延の上昇やパケットロスが出やすくなります。午前 9:00–11:00 と午後 14:00–16:00 は比較的空いており、数字は回線そのものの上限に近づきます。各時間帯で最低3ラウンド、数分間隔で測って中央値を取り、しかも2日以上にまたがって——平日と週末で1回ずつ測ってください。1回だけ測って出た良い数字は、何の根拠にもなりません。

再利用できる測定手順

まず測定前チェックリストを一通り確認し、その順に実行します。1回のテストは15分以内に収め、時間帯の境目に食い込まないようにしましょう：

• ✅ 有線 LAN を使うか、5GHz 帯に固定し、テスト中は位置もネットワークも変えない。
• ✅ OS の更新、クラウドストレージの同期、クラウドバックアップ、進行中のダウンロードを止める。
• ✅ 1回のテストでは同じノード・同じプロトコル・同じ mux 設定だけを使う。
• ✅ ルールモードと測定対象を確認し、「直結」がプロキシの結果に混ざらないようにする。
• ❌ 公共 Wi-Fi やテザリングで比較しない。こうした回線自体に追加の制約がある。
• ❌ 1回の測定で出た最高値を回線の実力とみなさない。

1. ベースライン測定：プロキシを外し、同じ測定サーバーで1ラウンド走らせ、遅延とスループットを記録する。
2. ノードに接続して ping を100個連続で送り、遅延の範囲とパケットロスを記録する。
3. mtr（または tracert）を1回実行し、国際区間で継続的なロスが出ていないか見る。
4. 同じ測定サーバーでマルチスレッドのスループットを測り、続けてシングルスレッドのダウンロードも測り、両方の数字を記録する。
5. 実際の利用に戻る：よく使う動画サービスやクラウドストレージを開き、1〜2分ほど実際に転送して、ビットレートが落ちないか観察する。
6. 夜のピークに手順2〜5を繰り返し、2回の結果を並べて比較する。
7. 3日間連続で記録し、最高値ではなく中央値をそのノードの代表値とする。

# Windows：100個のパケットを連続送信
ping -n 100 1.1.1.1

# macOS / Linux：同じパケット数
ping -c 100 1.1.1.1

# 1リクエストの所要時間とダウンロード速度。複数回実行して中央値を取る
curl -o /dev/null -s -w "%{time_total} %{speed_download}\n" https://example.com/file

結果の読み方：単発のピークに惑わされない

数字が高く出る典型的な原因をいくつか挙げます。遭遇したらそのまま採用せず、記録に注記しておきましょう：

• TCP スロースタートとバースト：接続直後は速度がまだ立ち上がっておらず、測定時間が短すぎると立ち上がり区間や一時的なバースト区間を切り取ってしまいます。
• キャッシュヒット：同じアドレスを繰り返し測ると CDN キャッシュに当たることがあり、数字は良くても出口帯域を表しているとは限りません。
• 測定サーバーの位置：測定ポイントとノードが同じ都市・同じデータセンターだと、測っているのはデータセンター内の速度に近く、目的のサイトにアクセスする速度ではありません。
• シングルとマルチの差：マルチは出るのにシングルが出ない場合、ボトルネックは1本の接続のスケジューリングにあります。大きいファイルをダウンロードすると最も気づきやすいです。

よくある誤解とノードを替える判断

もう一つ見落とされがちな点があります。測定値は正常なのに、Web ページを開く最初の一歩だけが極端に遅い場合は、まず DNS を疑ってください。一部のクライアントには「リモート解決 / ローカル解決」のオプションがあり、ローカル解決にすると名前解決がローカルネットワーク経由になるため、初回アクセスが遅くなるだけでなく、解決リクエストがトンネルを通らない（いわゆる DNS リーク）原因にもなります。こうした問題はスループットの数字には現れないので、別途確認が必要です。

次のような状況が出てから、ノードの変更を検討してください。1回の測定だけで結論を出さないように：

• 夜のピークに何日も続けてパケットロスが出て、ping と mtr の両方で再現する；
• シングルスレッドのスループットが目的の用途に必要な水準を長期的に下回るのに、マルチスレッドは正常；
• ジッターが大きく、動画のビットレート低下や音声の途切れが頻発する。