VPNの速度測定を正確に行うには、測定サイトを開いて大きな数字を見て終わり、では不十分です。まず自宅のネットワークを基準測定し、端末、接続方法、測定先、時間帯をそろえます。そのうえで、遅延、ジッター、パケットロス、下り・上りスループットを比較します。条件がそろっていなければ、計器は正確でも基準がずれた測定になってしまいます。
回線速度は、いつでも同じとは限りません。端末から入口ノードまでの接続品質、入口から出口までの中継経路、出口から目的サイトまでのルーティング、さらにサービス側の負荷が、最終的な体感に影響します。測定サイトで速くても、普段使うサービスで安定するとは限りません。目的は「世界最速のノード」ではなく、自分のネットワーク、端末、利用場面に合う回線を見つけることです。
まず、速度測定で何を測るのかを整理する
速度測定の結果は、複数の指標で構成されます。それぞれ示す内容が異なるため、目立つ数字だけを見ることはできません。下りスループットは大容量ファイル、動画の読み込み、Webリソースの取得速度を左右します。上りスループットはクラウド同期、添付ファイルの送信、ビデオ会議の上り通信に影響します。遅延はデータの往復にかかる時間、ジッターは遅延の安定性、パケットロスはデータが正常に届かなかった割合を示します。
| 指標 | 主に示すもの | 確認に適した場面 | よくある誤解 |
|---|---|---|---|
| 下りスループット | 遠隔地からデータを継続的に受信する能力 | 動画再生、Webページの読み込み、ファイルのダウンロード | ピーク値が高ければ、通信全体が安定している |
| 上りスループット | 遠隔地へデータを継続的に送信する能力 | ビデオ会議、添付ファイルのアップロード、クラウド同期 | 下りだけ測れば、利用感全体を判断できる |
| 遅延 | リクエストと応答の往復にかかる時間 | インタラクティブ操作、リモートターミナル、オンライン共同作業 | 遅延が低ければ、必ずスループットも高い |
| ジッター | 連続したリクエストにおける遅延の変動 | リアルタイム音声、ビデオ会議、継続的な操作 | 平均遅延が正常なら、変動は無視できる |
| パケットロス | 通信経路の継続性と信頼性 | リアルタイム通信、長時間接続、リモート操作 | Webページが開けば、パケットロスはない |
遅延とスループットは、単純に置き換えられる関係ではありません。距離が近く操作が快適な回線でも、出口の混雑でダウンロードが遅くなることがあります。スループットが高い遠隔回線でも、物理的な距離や迂回ルートによって遅延が大きくなる場合があります。回線を選ぶ前に用途を決めましょう。閲覧やダウンロードでは継続的なスループット、リアルタイム操作では遅延、ジッター、パケットロスを重視します。
測定前に条件をそろえる
一度だけの高スコアより、再現性が重要です。測定前に条件を管理しないと、バックグラウンド同期、無線干渉、ブラウザ拡張機能、システム更新、他の端末による通信が結果に混ざります。端末と接続方法を固定し、各回でクライアント、プロトコル、測定ツール、測定先をそろえるのが確実です。
- ✅ クラウドストレージの同期、システム更新、ダウンロード、動画再生を停止し、バックグラウンド通信による帯域の競合を避ける。
- ✅ 有線接続、または同じ場所の無線接続に固定し、移動しながら測定しない。
- ✅ 通信経路を変える他のプロキシ、アクセラレーター、ブラウザのネットワーク拡張機能を終了する。
- ✅ ローカルネットワーク、端末、OS、クライアント、プロトコル、回線名を記録する。
- ✅ 同じ測定先で複数回測定し、一度だけのピーク値で判断しない。
- ✅ 通常の時間帯と、普段利用する高負荷の時間帯を分けて記録し、回線の変動しやすさを確認する。
- ❌ 端末、接続ネットワーク、測定先が異なる結果を、そのまま同じ順位表に並べない。
- ❌ 測定直後に最速回線を決めず、異常値や偶然の高スコアを再測定する。
無線ネットワークは、特に誤差の原因になりやすい環境です。ルーターとの距離、壁による遮蔽、周辺帯域の混雑、省電力設定によって、VPNが突然不安定になったように見えることがあります。有線と無線で差が大きい場合は、まずローカルの無線環境を確認し、回線だけを原因と決めつけないでください。
クライアントが測定通信を本当にVPN経由にしているかも確認が必要です。ルールモードでは、測定サイトが直接接続になったり、一部のドメインだけがプロキシ経由になったりします。測定前に現在のモードと分流ルールを確認し、必要なら出口アドレスを調べて、選択した回線からリクエストが送信されていることを確かめます。
決めた順序で1回の測定を行う
信頼できる測定は、VPN未接続のローカル基準値から始めます。基準値は回線事業者の速度を証明するためではなく、現在の接続環境の上限と状態を把握するためのものです。基準値の時点でジッターやパケットロスが目立つなら、その後のVPN測定から回線の影響を正確に判断できません。
- ローカルの基準値を測定する。VPNを切断し、バックグラウンドで大容量通信が行われていないことを確認して、遅延、ジッター、パケットロス、下り・上りの結果を記録します。基準値が大きく変動する場合は、先に接続環境を見直します。
- 測定する回線に接続する。クライアントの状態が安定するまで待ち、選択した出口位置が正しいか確認します。接続直後に測定を始めないでください。ルーティングやDNSの切り替えが完了していない場合があります。
- 測定先を統一する。同じグループの回線では同じ測定先を使います。測定先は実際の用途に近い場所を選びましょう。ノードに近いサーバーだけを測ると、見栄えはよくても代表性に欠ける結果になりやすいです。
- 複数回測定する。各回の間に短い間隔を置き、結果をすべて記録します。一時的なピーク値より、継続して得られる水準のほうが信頼できます。
- 異常値を再測定する。ある回だけ極端に高い、または低い場合は、バックグラウンド処理、無線状態、測定先を確認してから再測定します。見たくないデータをすぐに削除してはいけません。
- 実際の用途で検証する。普段使うWebサイトを開き、よく見るコンテンツを再生し、ファイル転送やリモート操作を行って、測定結果が実際の体感に反映されるか確認します。
ブラウザの速度測定は手早い比較に向いていますが、ブラウザの実装、スクリプトの実行状況、タブの状態、測定サービスの割り当てに左右されます。デスクトップクライアントやコマンドラインツールは、パラメータを固定しやすいのが利点です。ただし、測定サービスの仕組みとデータの流れを理解していることが前提です。高機能なツールを使えば、結論まで自動的に正しくなるわけではありません。
測定記録は複雑でなくても構いませんが、後から確認できる形にします。少なくとも日付、時間帯、接続ネットワーク、端末、クライアント、プロトコル、回線、測定先、主な指標、実際の利用感を残しましょう。スクリーンショットだけでは、分流モード、プロトコル、出口方向が分からず、数日後には文脈を失った記念写真になりがちです。
速度測定で最も価値があるのは最高値ではありません。同じ条件で別の人が繰り返しても、同じ傾向を確認できることが重要です。
プロトコルは測定結果にどう影響するか
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、サブスクリプションサービスやさまざまなクライアントで使われています。しかし、プロトコル名だけで速度が決まるわけではありません。伝送方式、暗号化の実装、サーバー設定、クライアントのバージョン、OSのネットワークスタック、経路品質、混雑状況も影響します。プロトコル名だけを車種にたとえると、コース、タイヤ、運転方法が同時に変わっていることを見落とします。
TCP経路とパケットロスからの回復
基盤接続がTCPに依存する場合、パケットロス、再送、ヘッドオブラインブロッキングによって、高遅延回線のスループットが低下することがあります。Trojan、VMess、VLESSは異なる伝送方式と組み合わせられるため、名称だけで外側の転送方式を決めつけられません。Shadowsocksも実装、暗号化方式、通信環境の影響を受けます。比較時はクライアントと回線設定を固定し、プロトコル、ノード、その他の条件を同時に変えないようにします。
UDPベースの最新の伝送方式
Hysteria2とTUICは、通常QUICなどのUDPベースの伝送機構を利用し、高遅延やパケットロスのある環境で輻輳制御と復旧性を改善することを目指します。ただし、ローカルネットワークがUDPに適していない場合や、経路で速度制限、遮断、特殊なトラフィック制御が行われる場合は、不安定になることもあります。これらのプロトコルでは、開始直後のピーク値だけでなく、継続的なスループット、ジッター、接続復旧も確認してください。
直結、中継、IEPL専用線を比較する方法
直結回線は通常、利用者が遠隔地のサーバーへ直接接続する方式です。経路は主にローカルの通信事業者とパブリックネットワークのルーティングによって決まり、時間帯や事業者の方針で変化することがあります。中継回線は、近い、または適した入口へ接続してから、中継ネットワークを通って出口へ向かいます。経路の一部を調整できますが、体感は入口の接続品質、中継区間、出口方向のすべてに左右されます。
IEPL専用線は、特定の国際伝送区間に専用接続方式を使い、パブリックネットワークの国際ルーティングに伴う不確実性を抑えることを重視します。ただし、「専用線」だからといって、端末から目的サイトまでの全経路がパブリックネットワークから切り離されるわけではありません。入口までの接続、出口からサービスまでの区間、目的サイトの状態も測定結果に影響します。専用線は名称ではなく、安定性、夜間の変動、実際の利用感で判断しましょう。
| 回線タイプ | 経路の特徴 | 測定時の重点 | 適した判断方法 |
|---|---|---|---|
| 直結 | 端末から遠隔地の入口または出口へ直接接続 | 国際パブリックネットワークのルーティング、夜間の変動、パケットロス | 時間帯を変えて再測定し、異なる事業者の接続を比較する |
| 中継 | まず入口へ接続し、中継経路を通って出口へ到達 | 入口の品質、中継の安定性、出口方向 | 出口を固定し、継続的なスループットとジッターを比較する |
| IEPL専用線 | 国際区間に専用接続方式を使用 | 高負荷時間帯の安定性と実際の利用感 | 長期的に変動を記録し、一度だけのピーク値で結論を出さない |
回線を比較するときは、まず用途ごとに分けることをおすすめします。東アジアのサービスとヨーロッパのサービスでは、物理的な距離も出口方向も異なるため、同じ短距離走として扱うべきではありません。よく使う目的地ごとに安定した回線を選び、別の回線を予備として残す方法が現実的です。ノード一覧はランキングではなく、目的に応じて使い分ける道具箱です。
DNS、分流、クライアントが測定結果に与える影響
DNS解決によって、ドメインがどのアドレスへ向けられるかが決まります。VPNトンネルが正常でも、DNSリクエストをローカルネットワークが処理していると、DNSリーク、誤った名前解決、コンテンツ配信先の偏りが起きる可能性があります。測定前にDNSリクエストの処理元を確認し、リモート解決、ローカル解決、分流の設定が想定どおりか確かめてください。重要なのは特定のDNSリゾルバーに固定することではなく、測定時と実際の利用時で解決経路をそろえることです。
分流ルールによって、どの接続をVPN経由にするかが決まります。ルールモードは日常利用に便利ですが、測定の切り分けを難しくします。測定ページは回線経由でも、ページが呼び出す測定ドメインは直接接続になっていることがあります。逆の場合もあります。確認時はクライアントの接続ログやルールの適用情報を見て、測定通信の実際の経路を確認してください。分流の影響を一時的に切り離すにはグローバルモードが使えますが、診断後は通常設定に戻して検証します。
プラットフォームごとにクライアントの機能も異なります。デスクトップOSでは、接続ログ、仮想NICの状態、ルーティング情報を詳しく表示でき、問題の特定に役立ちます。モバイルOSでは、バックグラウンド処理、省電力設定、システムVPNインターフェースの制約により、画面ロック、ネットワーク切り替え、長時間のバックグラウンド動作後に再接続が起きることがあります。Apple、Android、Windows、Linuxでは、システムプロキシ、仮想NIC、DNSの制御方法が完全には同じでないため、プラットフォームごとに結果を記録してください。
サブスクリプションリンクは、設定を配布するための入口にすぎません。クライアントへインポートするとノードと関連パラメータが取得されますが、フィールド、プロトコルの機能、分流ルールへの対応はクライアントによって異なります。同じサブスクリプションでもクライアント間で差が大きい場合は、プロトコル対応、伝送パラメータ、更新状態、システム権限を先に確認し、回線が端末を選ぶようになったと急いで判断しないでください。
複数回の結果から適した回線を選ぶ方法
結果を整理するときは、最高の下り速度だけで並べ替えないでください。まず条件が異なるデータを除外し、各回線が複数回の測定で近い性能を維持しているかを確認します。安定した回線はピーク値が突出していなくても、遅延、ジッター、パケットロス、スループットが頻繁に崩れません。動画再生では継続的な転送とバッファの回復が瞬間的なピーク値より重要です。リモート操作では、大容量帯域より低いジッターと少ないパケットロスが役立つことがあります。
異常値も残しておく価値があります。通常の時間帯は安定している回線が、普段使う高負荷時間帯に繰り返し低下するなら、回線選びに必要な情報です。一方、ある回だけ遅く、再測定と実際の利用では正常なら、測定先の一時的な混雑かもしれません。単純な平均値より、異常が発生した条件を記録するほうが、後の判断に役立ちます。
最後は、1本の回線が永遠に首位を保つことを期待せず、主回線と予備回線を用意します。ネットワークの経路や目的のサービスの配信先は変化します。日常利用で安定する回線を主回線にし、入口や出口方向が異なる回線を予備として保存しましょう。変動があれば切り替えて再測定します。毎日ノード一覧で最速回線を探し続けるより効率的です。
- ✅ 主回線が普段使う時間帯に安定し、実際の利用感と測定結果の傾向が一致している。
- ✅ 予備回線は入口または出口方向が異なり、主回線と同じ障害点を避けられる。
- ✅ 動画では継続的なスループットとバッファの回復を優先し、開始直後のピーク値だけを信頼しない。
- ✅ リモート操作では、遅延、ジッター、パケットロス、長時間接続の安定性を優先する。
- ✅ クライアント、プロトコル、分流設定を変更するたびに、測定記録を新しく作成する。
- ❌ 回線名、プロトコル名、「専用線」という表示だけで測定結果を判断しない。
異常な結果が出たときの確認方法
VPNを切断しても基準値が遅い場合は、まず接続機器を再起動し、有線と無線の差を確認して、LAN内の大容量通信を停止します。基準値は正常なのにすべてのVPN回線が遅い場合は、クライアントモード、プロトコルの互換性、システムプロキシの競合、ローカルネットワークによるUDPや特定の伝送方式への影響を確認します。1本だけ異常なら、同じ地域の別の入口または出口に切り替えて比較します。
遅延は正常なのにダウンロードが遅い場合は、出口の混雑、目的サービスの速度制限、単一接続の性能、TCPの復旧効率などが考えられます。方向が近い別の測定先に変え、実際のファイル転送でも確認してください。ダウンロードは正常なのに動画が頻繁に低画質になる場合は、動画サービスへの実際の経路、DNSの振り分け、再生側のバッファを確認します。汎用の測定ページを繰り返し更新するだけでは解決しません。
接続直後は速いのに、継続的な通信で徐々に低下する場合は、端末の温度、省電力設定、無線信号、クライアントのリソース使用量、回線の混雑を確認します。モバイル端末では、バックグラウンド制御やネットワーク切り替えによって再接続が起きることがあります。画面とネットワークの状態をそろえて、比較測定を行ってください。
出口アドレスが正しいのにDNSリークが疑われる場合は、出口とDNSリクエストの送信元を別々に確認し、クライアントが想定したDNS制御方式を使っているか確認します。ルールを修正したら、古いDNSキャッシュを消去して目的のサービスを開き直してください。古いキャッシュが残っていると、設定を直してもブラウザが以前の経路を使い続けることがあります。