VPNの速度を正確に測るには、最高値を探すのではなく、通信が実際に対象の経路を通っていることを確認し、条件をそろえて継続的な性能を比較することが重要です。速度測定サイトでは転送能力、ファイルのダウンロードでは実際の転送状況、動画再生では視聴体験を確認できます。それぞれの結果を照らし合わせ、単独で判断しないようにしましょう。
この記事では、自分の端末で再現できる測定方法を紹介します。実測していない経路のランキングは掲載していません。まずローカルネットワークを確認し、ノード・接続先サーバー・クライアント設定を固定してから、普段使う時間帯にも測定します。こうすることで、日々の利用状況に近い結果を得られます。
速度測定サイト・ダウンロード・動画再生の使い分け
どのツールが一律に「最も正確」ということはありません。測りたい対象に合ったツールを選びましょう。ブラウザーの速度測定は通常、複数の接続を同時に確立し、そのときの条件で得られる転送速度を測ります。ファイルのダウンロードは配信元の速度制限や接続数、ディスクへの書き込みにも左右されます。動画再生には、地域判定やコンテンツ配信ノード、プレーヤーの動作も影響します。
| 測定方法 | 主な確認項目 | わかること | 誤判定しやすい点 |
|---|---|---|---|
| 速度測定サイト | ダウンロード・アップロード速度、アイドル時と負荷時の遅延 | 現在の経路で利用できる転送速度 | 接続先サーバーが自動で変わる、または測定サイトの通信がVPNを経由していない |
| 実際のファイルダウンロード | 継続速度、速度の変動、転送の中断 | 普段のダウンロードを安定して完了できるか | 配信元の速度制限、キャッシュ、接続数による影響 |
| 動画再生 | 再生開始、シーク後の復帰、画質、バッファリング | 対象地域向けのコンテンツを実際に視聴できるか | キャッシュ済みの動画や自動画質調整によって経路の変化が見えにくい |
| 遅延の測定 | 往復遅延、遅延の変動、測定時のパケットロス | 操作の快適さ、経路の安定性 | 測定用の通信方式と実際のアプリ通信は異なる |
主にアニメや動画配信を見るなら、利用するプラットフォームで実際に再生し、速度測定サイトは補助として使いましょう。ファイルをよくダウンロードするなら、転送中の速度も記録します。測定サイトの結果が良くても、すべての地域のコンテンツが快適に再生できるとは限りません。接続先のプラットフォームによって、出口までの経路は異なる場合があります。
ダウンロード速度・遅延・ジッター・パケットロスの見方
転送速度はピークではなく継続値を見る
ダウンロード速度は、単位時間あたりに実際に転送されたデータ量を示します。開始直後の一時的な速度上昇は、バッファリング、測定時間の区切り方、複数接続などが原因の場合があります。継続中に速度が何度も落ち込むと、ファイルのダウンロードや動画のバッファリングに影響しやすくなります。比較する際は同じツールと単位を使い、Mbps（メガビット毎秒）とMB/s（メガバイト毎秒）を区別しましょう。数字の大小だけで判断してはいけません。
アップロード速度も確認しましょう。クラウドストレージの同期、ビデオ通話、バックアップなどで上り回線が埋まると、ウェブページの応答も遅くなることがあります。ダウンロード帯域に余裕があっても、操作が快適とは限りません。
遅延は応答速度、ジッターは安定性を見る
遅延はデータの往復にかかる時間であり、ダウンロード速度とは異なります。ノード選択画面に表示される遅延は、接続先入口とのハンドシェイク時間や特定のアドレスへの測定値にすぎない場合があります。端末から経路全体を通って接続先のウェブサイトに届くまでの往復時間とは限りません。
ジッターは遅延の変動幅を示します。平均遅延が同程度でも、一方の経路で遅延の急上昇が頻発すれば、通話や操作が大きく途切れることがあります。ジッターの算出方法はツールによって異なるため、同じツール内で比較しましょう。
パケットロスはアプリの症状と合わせて確認
パケットロスが起きると再送が発生し、実効速度が低下することがあります。ただし、測定用パケットのロスが実際のアプリ通信の損失を意味するとは限りません。ルーターが測定への応答を低い優先度で処理したり、接続先が応答を制限したりする場合もあります。測定結果だけで経路を評価せず、ダウンロードの中断、動画のバッファリング、クライアントのエラーも合わせて確認しましょう。
アイドル時の遅延が低くても、ダウンロード中に応答が速いとは限りません。負荷時の遅延を測れるツールなら、転送中に遅延が大きく上昇するかを確認できます。キューイングによる混雑の発見に役立ちますが、発生箇所まではこの指標だけで特定できません。
実測を始める前に、端末と通信経路を固定する
よくある誤りは、クライアントを起動すれば速度測定サイトの通信も自動的に対象ノードを通ると思い込むことです。ルールモードでは測定サービスへの通信が直接接続になる場合があり、システムプロキシもコマンドラインツールの通信を必ずしも制御しません。まず測定に使うアプリがどの経路を通るか確認しましょう。
- ✅ 端末と接続方法を固定し、できるだけ安定した有線接続を使います。Wi-Fiの場合は、端末の位置と周波数帯をそろえます。
- ✅ OSの更新、クラウドストレージの同期など、大量の通信を行うタスクを停止します。同じネットワーク上のほかの端末が帯域を使っていないかも確認しましょう。
- ✅ クライアント、ノード、モードを固定します。接続ログや通信記録を確認し、速度測定の通信に想定したプロキシルールが適用されているか確かめます。
- ✅ 測定サーバーを固定します。ツールがサーバーを自動で切り替える場合は、その変更を記録し、異なる経路の結果を同じ条件のデータとして扱わないようにします。
- ✅ 測定ツールとクライアントのバージョンを記録し、元の測定結果を保存します。見栄えのよいスクリーンショットだけを残すのは避けましょう。
- ❌ 測定中にプロトコル、ノード、測定先を同時に変更しないでください。どの変更が結果に影響したのか判断できなくなります。
TUNモードを使うと、より多くのアプリ通信を取り込めることがあります。ただし、除外ルートやアプリごとのバイパス設定が残っている場合もあります。測定後は、普段の利用に適したルーティングルールに戻しましょう。数値を上げるために、働きがわからないルート設定を長期間残すのは避けてください。
ブラウザーの出口地域を確認するには、当サイトのIPアドレス確認が参考になります。ただし、ブラウザーで正しい出口が確認できても、わかるのはそのウェブリクエストの経路だけです。コマンドラインのダウンロードツールも同じ出口を通っているか、クライアントの接続記録で確認してください。
基準値・ノード・時間帯をそろえて比較する
再現できる基準値を取るところから始めましょう。基準値の測定先には、現在のネットワークから直接アクセスできるものを使います。目的はローカル接続に異常がないか確認することであり、すべての測定先に直接接続とプロキシ接続の両方でアクセスできることを求めるものではありません。地理的に異なる経路の結果を単純に差し引いて、「経路による損失」とみなすこともできません。
- ローカルの基準値を記録する。プロキシ接続を一時的に切り、アクセス可能な測定先で速度と普段のウェブ応答を確認します。この段階でも不安定なら、まずWi-Fiの電波、ルーターの負荷、ローカル回線を確認しましょう。
- ノードを固定して測る。対象ノードに接続し、測定サーバーを固定して、転送速度と負荷時の遅延を測ります。ノードが自動で切り替わっていないことを確認してから、次の測定に進みましょう。
- 実際の用途を試す。信頼できる配布元の公開ファイルをダウンロードするか、対象のプラットフォームで動画を再生します。速度の推移、再生開始、シーク後の復帰状況を記録し、エラーがないか確認しましょう。
- ノードを切り替えて比較する。ツール、接続先、その他の条件は変えず、比較対象のノードだけを切り替えます。大きな差があれば元のノードに戻し、同じ結果を再現できるか確認しましょう。
- 普段使う時間帯にも測る。日常的に動画を見る時間帯と、比較的空いている時間帯で測定します。別の日の記録も残し、一時的な混雑を長期的な傾向と取り違えないようにしましょう。
記録は複雑にする必要はありません。日付と時間帯、端末と接続方法、クライアントのモード、ノード、測定先、継続時の状態、異常の有無を残しましょう。異常があれば、出口地域やエラーメッセージも記録します。共有するスクリーンショットには、機密性の高いサブスクリプションURL、アクセストークン、アカウント情報を載せないでください。
速度測定やダウンロードでは、実際に通信量を消費します。従量制プランの場合、通信を使い切るまで測定する必要はありません。問題を再現して条件を比較するほうが、最高値が出るまで何度も測り直すより有効です。変動の幅と典型的な状態を記録し、異なる条件の結果を一つの平均値にまとめないようにしましょう。
動画のビットレート・DNS・地域判定の確認方法
動画のビットレートは再生に必要なデータ転送速度であり、回線の最大転送速度ではありません。同じ解像度でも、コーデックや映像ソース、シーンによってビットレートは変わります。プレーヤーはバッファーの状態や端末の性能に応じて画質を自動調整するため、画質の低下が必ずしもネットワークだけに起因するとは限りません。
測定時は対象地域の同じコンテンツを選び、画質設定、字幕、プレーヤーの環境をそろえます。再生開始、連続視聴、シーク後の復帰状況を確認しましょう。ノードを切り替えた直後は、キャッシュ済みの動画が再生され続ける場合があります。再読み込みを行い、その後の通信が新しいノードを通っていることを確認してください。
速度測定に問題がないのにコンテンツを視聴できない場合は、「再生時のバッファリング」と「地域制限」を切り分けて確認しましょう。後者には、アカウントの地域、著作権、出口アドレスの判定、プラットフォームのルールなどが関係することもあります。回線速度が速くても、特定のコンテンツを視聴できる保証にはなりません。キャッシュを消去しても、コンテンツの配信地域は変わりません。
DNSリークとは、名前解決のリクエストが想定した経路を通らない状態であり、速度低下と同じ意味ではありません。ブラウザーの暗号化DNS、OSのリゾルバー、クライアントのDNS設定がそれぞれ名前解決に関与する場合があります。地域判定の異常や名前解決の失敗があれば、別のDNSツールをむやみに追加するのではなく、これらの設定がルーティング方針と一致しているか確認しましょう。
確認のために、証明書の検証やセキュリティソフトを最初に無効化しないでください。まずルールの適用状況、出口、エラーログを確認します。サポートに必要な記録を送る場合は、サブスクリプションURLとアクセス認証情報を隠しましょう。
経路やプロトコルの名称だけでは速度はわからない
IEPL専用線、中継、直接接続は、経路の構成方法を表すもので、共通の速度ランクではありません。専用線は一部のバックボーン伝送に使われる場合があり、中継では経路上に転送ポイントが追加されます。直接接続は通常、クライアントが接続先サービスの入口に直接接続することを指します。入口、地域間の伝送、コンテンツプラットフォームまでの出口など、経路のどの区間もボトルネックになり得ます。
同様に、Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどの名称は、主にプロキシ通信方式に関するものです。名称だけで、どれが速いかを判断することはできません。実際の性能は、通信設定、輻輳制御、サーバー負荷、端末の性能、ネットワーク側のUDP処理にも左右されます。クライアントが対象のプロトコルや設定に対応しているかも、事前に確認してください。
ブラウザー、デスクトップクライアント、モバイル端末では、通信を取り込む仕組みが異なります。システムプロキシ、TUN、アプリ内プロキシでは、対象となる通信が異なる場合があります。省電力設定がバックグラウンド接続に影響することもあります。パソコンで良い結果が出ても、別の端末での動画再生を保証するものではありません。最終確認は普段使う端末で行いましょう。
まず通信経路を確認してから測定条件を固定します。速度測定サイトで転送速度と応答を調べ、ダウンロードや動画再生で継続的な使用感を確かめ、最後に普段使う時間帯にも測定しましょう。同じ結果を再現でき、用途を安定してこなせるなら、その記録は選定の参考になります。特定の接続先だけで問題が起きる場合は、サービス全体の速度が原因と決めつけず、接続先までの経路や地域判定、ルールを確認してください。
経路の種類を確認するにはサーバーとネットワーク経路をご覧ください。クライアントの初期設定はクイックスタートから始められます。測定方法を統一しておけば、今後ネットワークやノードを変更した際も、同じ基準で違いを判断できます。