VPNの速度を比較するときに大切なのは、最速の測定結果を探すことではなく、同じ条件で回線を比べることです。まず通常のネットワーク速度を測り、ツール・測定先サーバー・プロキシモードを固定して、時間帯を変えながら繰り返し記録します。最後に実際のアプリでも確かめれば、遅さの原因がローカル回線、国際経路、接続先サイトのどこにあるかを見分けやすくなります。
この記事では、根拠のない回線ランキングや測定結果は掲載しません。契約中の回線を比較したい場合や、「測定値は速いのに実際の利用では遅い」と感じる場合に役立つ方法を紹介します。測定結果はその時点のネットワーク環境を示すもので、今後の利用を保証するものではありません。
用途に合わせて測定指標を選ぶ
ネットワークの速さは、ひとつの指標だけでは表せません。ウェブページの表示には、DNS名前解決、接続確立、暗号化ハンドシェイク、コンテンツ転送が含まれます。一方、大容量ファイルのダウンロードでは、継続的なスループットがより重要です。これらをひとまとめに「速い」と表現すると、使い勝手を左右する本当のボトルネックが見えにくくなります。
| 指標 | わかること | 利用時の注意点 |
|---|---|---|
| 往復遅延（RTT） | リクエストから応答までの往復時間。操作への反応に影響します。 | クライアントの測定対象がノードまでで、サービスのサーバーまで届いていない場合があります。 |
| ジッター | 時間の経過に伴う遅延のばらつき。音声通話やリアルタイムの共同作業に影響します。 | 定義はツールごとに異なるため、同じツール同士で比較してください。 |
| パケット損失 | 測定データに応答がなかった割合。経路上の問題を把握する手がかりになります。 | 測定パケットが速度制限やフィルタリングの対象になっても、実際の通信で同じ割合の損失が起きるとは限りません。 |
| ダウンロード・アップロードのスループット | 継続してデータを転送する能力。動画の読み込みやファイル同期に関係します。 | 測定先サーバー、同時接続数、端末の性能にも左右されます。 |
| TTFB（最初の1バイトまでの時間） | 応答の先頭を受信するまでの待ち時間。ウェブページの表示待ちに近い指標です。 | サーバー側の処理時間も含むため、回線の遅延と同じではありません。 |
オンライン会議ではジッター、アップロード速度、接続の安定性を優先して確認しましょう。ファイルのダウンロードでは継続的なスループット、ウェブや開発ツールでは接続確立や応答までの待ち時間も重要です。アイドル時の遅延が小さくても、アップロードやダウンロードで帯域を使い切ると通信が滞ることがあります。転送中に操作への反応が明らかに遅くならないかも確認してください。
ツールの使い分け：帯域幅・疎通・アプリで実測
帯域幅測定ツール：ブランドより測定先の固定が重要
Speedtest系のツールは上下のスループットの確認に向いており、Fast.comは同社のコンテンツ配信ネットワークへの接続状況が測定結果に反映されやすい傾向があります。測定先のネットワークや同時接続の方法が異なるため、結果を同じランキングに混在させないでください。ツールを決めたら、可能な限り測定サーバーを手動で固定し、サーバー名と地域を記録しましょう。
自動サーバー選択では、接続元が変わると測定先も切り替わることがあります。回線が速くなったように見えても、実際には測定サーバーが変わっただけかもしれません。サーバーを固定できないツールを使う場合は測定先の情報を残し、その結果がツールによる自動選択を反映したものだと明記してください。
疎通確認ツール：まず通信経路を確認
システムの ping は通常ICMPを使うため、ブラウザーの通信で使われるプロキシを経由しない場合があります。システムプロキシモードでは、ブラウザーの速度測定とターミナルからの測定で経路が異なることがあります。TUNモードでも、ルーティングやクライアントが測定用通信をどう処理するかを確認しましょう。ノード一覧の遅延はTCP接続やHTTPリクエストを測った値の場合もあり、システムのpingと同じ指標として扱うことはできません。
tracerouteなどの経路追跡ツールは経路の確認に役立ちますが、中継ルーターが応答しないからといって、実際の通信が途切れているとは限りません。curlで接続時間や応答時間を調べるときは、プロキシ設定が適用されているか確認してください。ターミナルの通信がブラウザーと同じ経路を通るとは限りません。
アプリで確認：実際の作業で使い勝手を確かめる
よく使う文書を開く、ファイルを同期する、会議に参加する、同じ動画を再生するといった実作業での確認は、別の速度測定サイトを試すより参考になることがあります。初回表示とキャッシュ利用後の読み込みは分けて記録しましょう。動画の自動画質調整も負荷に影響するため、コンテンツ、画質、操作手順をそろえて測定してください。
ウェブブラウザー上の速度測定でわかるのは、そのページへの通信経路の状態です。端末全体やすべてのアプリの通信を示すわけではありません。ブラウザー拡張機能のプロキシ、システムプロキシ、TUNモードでは、プロキシの対象範囲が異なります。
基準値を確認：ローカル回線と設定の違いを切り分ける
まずプロキシを有効にせずにローカル回線を測定し、Wi-Fiの電波、ルーター、プロバイダーの接続に明らかな問題がないか確認します。直接接続時の基準値は、通常どおり接続できる測定先を使ってください。特定の海外サーバーに直接接続できない場合は「接続不可」と記録し、帯域幅がゼロだったと扱わないでください。
- ✅ 端末と接続方法を固定し、安定した有線接続を優先しましょう。Wi-Fiを使う場合は端末の位置を変えないでください。
- ✅ クラウドストレージの同期、OSの更新、ほかの大容量通信を一時停止し、同じネットワーク上で帯域を取り合っていないか確認しましょう。
- ✅ クライアントのバージョン、プロキシモード、ルールを固定し、測定先のドメインが想定した経路を通っているか確認しましょう。
- ✅ IPアドレスの確認でウェブの出口をチェックし、測定したいアプリの通信経路も確認しましょう。
- ✅ 端末の発熱、省電力モード、リソースの異常な使用状況を記録し、端末の性能不足を回線の速度制限と取り違えないようにしましょう。
サブスクリプションURLは、ノードや関連設定を互換性のあるクライアントに取り込むためのもので、速度測定用のURLではありません。更新後にノード名やルールが変わる場合があるため、比較する前に実際に選択されているノードを確認してください。測定結果を共有するときは、サブスクリプションURL、アクセストークン、アカウント情報を削除しましょう。これらは公開してよいネットワーク情報ではありません。
DNSの測定条件もそろえてください。ブラウザーの暗号化DNS、クライアントの名前解決設定、システムのリゾルバーがそれぞれ使われる場合があります。名前解決の経路が変わると、初回接続の待ち時間に影響したり、想定外のDNS出口が使われたりすることがあります。見慣れないDNSアドレスを見ただけで情報漏えいと断定せず、クライアントの仕様、名前解決の場所、実際のリクエスト経路をあわせて確認しましょう。
測定する時間帯：順番を入れ替えて比較し、記録を残す
空いている時間帯だけ測ると、普段使う時間帯の混雑を見落としやすくなります。反対に、最も混み合う時間だけでは回線の基本性能を判断しにくくなります。普段利用する仕事中や夜間の時間帯を対象にし、別の日にも繰り返し測定しましょう。複雑なスケジュールを組む必要はありません。一度に多くのノードを測るより、同じ手順を繰り返せることが大切です。
- 環境を記録。日付、時刻とタイムゾーン、接続回線、端末、クライアント、プロキシモード、ノード、測定先を書き留めます。
- その日の基準値を測定。ローカル回線の状態を確認し、直接接続できる測定先の結果を残します。異常があれば、比較を始める前に原因を確認してください。
- 候補の回線を交互に測定。1つの回線を測ってから長時間空けて別の回線を測るのではなく、次の測定では順番を入れ替え、測定順による影響を抑えます。
- ツールの設定を固定。同じ条件で繰り返し測り、すべての結果を残します。最高値だけを記録したり、複数の帯域測定を同時に実行したりしないでください。
- アプリでも確認。近い時間帯に同じ実作業を行い、動作の引っかかり、再接続、転送の中断を記録します。
大容量通信を連続して測定すると、端末が熱くなったり、プランの通信量を消費したりすることがあります。結果が続けて低下する場合は、測定を重ねるのではなく、一度止めて環境を確認してください。ダウンロードとアップロードの測定はいずれも通信量に加算される場合があります。利用中のサービスの計量ルールを確認しましょう。
結果を整理するときは、代表的な値とばらつきの範囲を記録しましょう。測定回数が十分にあれば、単発の最高値より中央値のほうが普段の状態を表しやすくなります。外れ値には理由を添えて記録し、都合が悪いからという理由で削除しないでください。原因を説明できない外れ値も、安定性を判断する情報になります。
結果の見方：速度が速くても使い勝手がよいとは限らない
速度測定は速いのに、ウェブページの表示が遅い
まずDNSの名前解決、接続確立、最初の1バイトまでの待ち時間を確認し、ページ内のリソースが複数のドメインに分かれていないか調べましょう。速度測定では継続的にデータを並列転送することが多い一方、ウェブページでは短い接続やサーバー側の処理が多数発生します。測定サーバーが近くにあっても、アクセス先のサービスが同じ地域にあるとは限りません。
クライアントの遅延は低いのに、会議が途切れる
ノードの測定で確認できるのは接続先までで、その先の出口から会議サーバーまでの経路が含まれていない場合があります。アプリの通信がプロキシを通っているか、UDPが想定どおり転送されているか、アップロードの混雑で通信待ちが発生していないかも確認してください。ゲームや会議では、ノード一覧の単一の遅延値より、アプリ内のネットワーク診断のほうが実際の使い心地に近い情報を得られることがあります。
同じ回線でも、プラットフォームによって結果に差が出る
Windows、macOS、iOS、Android、Linuxの各クライアントでは、システムプロキシ、仮想ネットワークインターフェース、バックグラウンド動作の仕組みが異なります。モバイル端末では省電力機能やネットワークの切り替わりも影響します。回線を比較するときはプラットフォームを固定し、クライアントを比較するときは回線を固定して、一度に変える条件をひとつにしましょう。
専用線や新しいプロトコルなら必ず速い、とは限らない
IEPL専用線、中継、直結は、通信経路や伝送方式を表すものであり、エンドツーエンドの測定に代わるものではありません。専用の伝送路を使っていても、最終的な速度は入口、出口、接続先のネットワークに左右されます。Shadowsocks、VMess、Trojan、VLESSはプロキシ関連のプロトコルです。Hysteria2とTUICはQUICをベースにした伝送方式を採用していますが、実際の性能はネットワーク環境や実装に左右されるため、プロトコル名だけで優劣は判断できません。
プロトコルがUDPを必要とする一方で、接続回線でUDPが厳しく制限されている場合、接続に失敗したり使い勝手が低下したりすることがあります。反対に、現在のネットワークで特定のプロトコルが良好でも、すべてのネットワークに適しているとは限りません。プロトコルを比較するときは、地域や測定先を変えず、プロトコルだけを個別に比較してください。
結論をまとめる：用途に応じてメイン回線と予備回線を選ぶ
最終的な記録では、普段使う時間帯に安定している回線、大容量ファイルの転送に向く回線、応答性が求められる作業に向く回線、そして異常が再現するかどうかを確認できるようにしましょう。すべての用途をひとつの総合スコアにまとめる必要はありません。接続先に近い地域は候補を選ぶ手がかりになりますが、それだけで結論を出すことはできません。
速度測定のまとめ：端末、ネットワーク、測定先、モードをそろえ、回線を交互に繰り返し測定してから、実際のアプリでも確認しましょう。最高ダウンロード速度だけでなく、普段使う時間帯のばらつきが小さく、作業を安定して完了できる回線を優先してください。
VPNCBを利用する場合は、まず実際に使う地域から候補を選び、ここで紹介した方法で記録を取りましょう。回線の提供地域はサーバーページで確認できます。クライアントはログイン後、ユーザーパネルから入手してください。速度測定のために出所不明の設定をまとめて読み込んだり、サブスクリプション情報を公開したりしないでください。
プランを選ぶときは、普段の利用内容と測定に伴う通信量の両方を考慮しましょう。VPNCBの月額プランは利用開始日を基準に毎月リセットされます。データ容量パックは使い切るまで有効で、期限はありません。測定記録は回線と用途の相性を判断する参考になります。プラン料金やデータ容量はプランページで確認し、測定結果だけで予算を決めないようにしましょう。