VPNの速度を正しく測るには、最高ダウンロード速度を探すのではなく、測定条件をそろえ、通信が目的の経路を通っていることを確認したうえで、遅延・パケットロス・実際のアプリの動作を見ます。再現できる測定手順に沿って、各ツールで分かることと分からないことを比較します。
この記事では、実測していない回線ランキングを掲載したり、ツールの画面例を測定結果として扱ったりしません。ここでの「実測比較」は、ご自身の端末とネットワークで条件をそろえて確認する方法を指します。同じ回線でも、ブラウザーの速度測定、クライアントの遅延表示、動画再生で結果が異なることがあります。それぞれ測定対象が違うためです。
速度測定の数値と実際の使い心地を区別する
速度測定サイトのダウンロード値が示すのは、端末と測定サーバー間の通信速度です。どのサイトにも同じ速度でアクセスできるという意味ではありません。ページの表示、動画の読み込み、オンライン会議には、DNSの名前解決や接続確立、接続先の負荷、アプリ側の仕様も影響します。
| 指標 | 主に分かること | 判断する際の注意点 |
|---|---|---|
| ダウンロード速度 | データを継続して受信する能力。ファイルのダウンロードや動画の読み込みに関係 | 測定サーバー、同時接続数、ローカル回線の帯域に左右される |
| アップロード速度 | ファイル送信、データ同期、会議での上り通信の能力 | ダウンロードが速くても、アップロードが速いとは限らない |
| 往復遅延(RTT) | リクエストを送り、応答が戻るまでにかかる時間 | 測定先と測定方法を併せて確認する |
| ジッター | 遅延のばらつき。リアルタイムの音声・映像の安定性に関係 | ツールによって集計方法が異なる場合がある |
| パケットロス | 測定時に期待した応答を受信できなかった状態 | 測定用パケットが速度制限やフィルタリングを受けていないか確認する |
| 負荷時の遅延 | ダウンロードやアップロード中に応答時間がどう変化するか | ローカルルーターのキュー詰まりが原因の場合もある |
どの用途にも当てはまる「合格遅延」を一律に決めるのは適切ではありません。遠距離の経路では伝搬遅延が発生します。また、大容量ファイルの転送に向いた回線が、双方向の会議にも向いているとは限りません。まず実際の用途で支障がないかを確かめ、その状況を各指標から読み解きましょう。
ローカル環境の基準値を測り、ルール分岐の経路を確認する
測定前にクラウドストレージの同期、システム更新、ほかのダウンロードを一時停止し、実行中の速度測定も終了します。端末、接続方法、場所はできるだけ固定してください。可能なら有線接続にして無線の影響を除きます。有線が使えない場合は、無線環境を記録しましょう。ルーターの近くで測った結果と、壁を隔てて使った結果をそのまま比較するのは避けてください。
まずプロキシを有効にせず、通常アクセスできる測定先で速度を測り、ローカルネットワークが混雑していないか確認します。この基準値は、端末や接続環境に起因するボトルネックを見分けるためのものです。基準測定とプロキシ測定でサーバーが異なる場合、数値を割り算して回線の損失率を求めることはできません。
次にクライアントを有効にし、選択したノードと動作モードを記録します。ルール分岐の設定によっては、速度測定サイトへの通信が直接接続になることがあります。クライアントに接続済みと表示されていても、測定がプロキシ経由とは限りません。接続ログで、測定サイトのドメインに適用されたルール、出口の設定、実際のノードを確認してください。測定中だけ経路を確認しやすいモードにすると、条件をそろえやすくなります。終了後は普段のルールに戻しましょう。
出口の確認だけでは、すべての通信経路を確認したことにはなりません:確認サイトに表示される出口アドレスで分かるのは、そのサイトへの通信経路だけです。速度測定では別のドメインや接続が使われる場合もあるため、該当する通信に想定どおりのルールが適用されているか確認してください。また、ブラウザーの通信だけを処理するプロキシでは、システムの ping コマンドがプロキシを経由しないことがあります。
速度測定ツールを比較:測定対象に合わせて選ぶ
ツールによって結果に差が出るのは珍しいことではありません。ブラウザーのテストでは帯域を使い切るために複数の接続を使うことがありますが、実際のファイルダウンロードでは接続数が少ない場合があります。自動選択されるサーバーも、出口の地域によって変わることがあります。回線を比較するときは、同じツールと測定サーバーを使い、サーバー名も記録しましょう。サーバーの変更を回線の変化と取り違えずに済みます。
| ツール・方法 | 確認に向いていること | 利用時の注意点 |
|---|---|---|
| Speedtest | サーバーを固定した場合の通信速度と遅延の比較 | サーバー情報を記録する。ブラウザーとアプリでは測定経路が異なる場合がある |
| Fast.com | Netflixの測定インフラまでの通信状況 | 特定地域のコンテンツをアカウントで再生できることの証明にはならない |
| Cloudflare Speed Test | ダウンロード・アップロード速度、遅延、および負荷時の変化 | 測定インフラまでの経路を反映した結果 |
| クライアントの遅延測定 | ノードが応答するかを手早く確認する | TCP接続またはURLへのプローブの場合があるため、クライアントの説明を確認する |
| ping / mtr | プローブの経路上の遅延と応答状況 | ICMPがプロキシを経由するとは限らない。途中のホップが応答しなくても、実際の通信でパケットロスが起きているとは限らない |
| 実際のアプリやファイル転送 | 目的の作業ができるか、動作が安定して続くか | 接続先サービスの速度制限、キャッシュ、アカウントの利用条件に左右される |
無理のない組み合わせは、ブラウザーツールで帯域と負荷による変化を確認し、クライアントの記録で経路を照合し、目的のアプリで実際の使い心地を確かめる方法です。複数のテストを同時に実行すると帯域を奪い合い、結果を個別に評価できなくなります。速度測定では通信量を消費するため、特に高速通信を長時間続けるテストの自動実行は控えましょう。
再現可能な実測手順と記録方法
- 利用環境を記録する。端末のOS、クライアントのバージョン、接続方法、通信事業者、現地時刻、ほかに大きな通信を行っているかを記録します。
- 通常時の基準を測る。基本的なWebサイトが開けることと、ローカルネットワークが安定していることを確認します。基準値が大きく変動する場合は、まず接続環境を調べてください。
- 測定する経路を固定する。自動切り替えの影響を一時的に避け、ポリシーグループの名前だけでなく、実際に接続しているノードを確認します。
- 測定の通信経路を確認する。接続ログで測定通信が対象ノードを経由していることを確認し、使用したツールとサーバーを記録します。
- ネットワークが空いてから再測定する。最高値だけでなく、各回の結果と変動幅を残します。中断や失敗も記録してください。
- 実際の用途で確かめる。目的の動画を再生する、普段使うファイルをアップロードする、会議の接続テストを行うなどして、開始までの待ち時間、再生中の読み込み、音声の途切れを確認します。
- 普段使う時間帯にも測定する。ほかの条件をできるだけそろえ、空いている時間帯と夜間の結果を比較してから、メインと予備の経路を決めます。
記録には、以下のテンプレートをそのまま使えます。速度測定のメモにアカウント情報や完全なサブスクリプションURLを貼り付けないでください。他の人に相談するときは、スクリーンショットに含まれる機密情報も事前に消しましょう。
現地の日付・時間帯:
端末のOS・クライアントのバージョン:
ローカルネットワーク・接続方法:
選択したノード・実際のノード・動作モード:
測定ツール・測定サーバー:
速度測定の接続に適用されたルール:
ダウンロード・アップロード・アイドル時の遅延・負荷時の遅延:
ジッターまたはパケットロスの測定方法:
再測定時の変動・失敗の有無:
目的のアプリでの実際の動作:
ノードを比較する場合は、一方を測り終えてから長時間後にもう一方を測るより、交互に測定すると時間帯による偏りを抑えやすくなります。それでもネットワーク状況の変化を完全には取り除けません。結論は「この環境と時間帯ではこちらが適している」とし、回線に恒久的な速い・遅いの評価を付けるのは避けましょう。
夜間の混雑、プロトコル、回線の種類が測定結果に与える影響
夜間を避けて測ると分かるのは、比較的空いている時間帯の状態だけです。夜間の使い勝手を確認することはできません。夜に使うことが多いなら、夜間も測定し、現地のほかの時間帯とは分けて記録しましょう。現地のネットワーク、回線の入口、国際通信、接続先サービスのいずれも混雑する可能性があります。1回の速度低下だけでは、どの区間に原因があるか特定できません。
IEPL専線は、一般に通信事業者が提供するイーサネット専用線による伝送を指します。「中継」は途中のサーバーを介して通信を転送する方式、「直結」は通常、クライアントが海外側の入口に直接接続する方式です。これらは伝送方式やネットワーク構成の異なる側面を示しており、組み合わせて使われる場合もあります。専線という表示があっても、端末から接続先サイトまでの全区間が同じ品質で保証されるわけではなく、実際の環境での測定に代わるものでもありません。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルです。実装や通信設定によって接続の挙動が変わります。Hysteria2とTUICはQUICベースの通信を利用するため、ネットワーク側のUDPの扱いが結果に影響することがあります。ほかのプロトコルも、名前だけで速度を判断することはできません。サービスが実際に提供し、クライアントが明確に対応している設定だけを比較してください。プロトコル、地域、サーバーを同時に変更して、その差をプロトコルだけの影響と考えるのは避けましょう。
同じサブスクリプションでも、デスクトップとモバイル端末で結果が異なる場合があります。クライアントのコア、システムプロキシの適用範囲、TUNやシステムネットワーク拡張、省電力設定、無線接続の違いなどが原因として考えられます。サブスクリプションを読み込んだら、ノードとルールが更新されているか確認してください。速度測定の数値を上げるために、配布元が不明な設定を安易にインストールしないでください。
ダウンロード速度は速いのに使いにくい場合の確認方法
- ✅ Webページの初回表示が遅い:DNSの名前解決と接続確立を確認します。DNSの設定やキャッシュ、ルールの適用状況が初回表示に影響することがあります。ダウンロード速度が速くても、これらの問題は解消されません。
- ✅ ダウンロード中に会議が途切れる:アイドル時と負荷時の遅延を比べ、大容量通信を一時停止して再度試します。ノードの通信速度ではなく、ローカル側の上り通信が混雑している可能性があります。
- ✅ クライアントの遅延は低いのにWebページが遅い:プローブの測定先を確認します。プロキシの入口まで速く接続できても、入口から接続先サイトまで速いとは限りません。
- ✅ 特定のプラットフォームだけで問題が起きる:そのプラットフォームが利用可能な地域、アカウントの要件、通信ルールを確認します。1つのサービスの問題だけで、回線全体が使えないと判断しないでください。
- ❌ 途中のホップが応答しないだけでパケットロスと判断する:ルーターが測定用パケットの優先度を下げている場合があります。最終的な接続先からの応答や、アプリの実際の動作もあわせて確認してください。
- ❌ 最高速度のスクリーンショットだけを保存する:夜間の速度低下、測定の失敗、継続通信中の変動を見落とすため、普段使う回線を選ぶ根拠として不十分です。
DNSリークの確認と速度測定は、目的が異なります。前者ではDNSの問い合わせが想定した経路を通っているかを確認し、後者では通信性能を測ります。DNSサーバーの所在地だけでは、リークが起きているとは判断できません。クライアントのDNSモード、システム設定、想定する名前解決の経路をあわせて確認してください。出口アドレスが変わったことも、DNS設定が正しい証拠にはなりません。
問い合わせの際は、「遅い」とだけ伝えるより、発生した時間帯、クライアントのバージョン、ノード名、接続先サービス、機密情報を伏せた接続ログを添えると原因を特定しやすくなります。基本設定は使い方ガイド、よくある接続の問題はヘルプセンター、回線情報は回線情報ページをご覧ください。
まとめ:正確なVPN速度測定に必要なのは、最高速度の数値ではなく、条件を記録した比較結果です。まずローカル環境のボトルネックを取り除き、通信経路を確認します。測定ツールと測定先を固定し、普段使う時間帯を含めて測定したうえで、実際のアプリでも確かめましょう。メインの回線は用途に必要な安定性を優先し、予備の回線も同じ条件で実際に測っておくことが大切です。