本文へスキップ

VPN速度を実測で比較:自分で本当の速度を測る方法

測定ツールの選び方や測る時間帯、遅延とパケットロスの見方を解説。再現できる測定手順で、広告上の数値と実際の使い心地を見分けます。

VPNの速度を比較するときに大切なのは、最高のダウンロード速度を探すことではなく、条件をそろえて各回線で同じタスクを試すことです。まず自宅のネットワークの基準値を測り、測定先を固定してから、Web閲覧・動画視聴・会議で確認しましょう。ボトルネックを見極められるよう、この記事では測定の順序と記録方法を紹介します。実測していない回線ランキングは掲載しません。

測定指標:ダウンロード速度以外に見るポイント

ダウンロード速度はデータを継続して受信する能力の目安で、大容量ファイルの転送や動画のバッファリングを確認するのに役立ちます。アップロード速度はファイル送信やクラウドへのバックアップ、会議中の映像に関わります。Webページの表示には、ドメインの名前解決や接続の確立、サーバーからの応答も必要です。そのため、帯域に余裕があっても初回表示が速いとは限りません。

遅延は通信の往復にかかる時間です。ジッターは遅延の揺れ幅、パケットロスは測定データが想定どおり届かなかった状態を指します。会議やリアルタイム操作では、ジッターとパケットロスの影響が表れやすくなります。比較前には単位も確認しましょう。帯域測定ツールでは Mbps、ダウンロードソフトでは MB/s と表示されることがあり、異なる単位の数値をそのまま比べることはできません。

指標ごとに分かることは異なります。一律の合格基準はありません
指標 主な用途 よくある誤解
ダウンロード・アップロード 継続的なデータ転送能力を確認する 一時的な最高値を全体の性能とみなす
アイドル時の遅延 ネットワークが混雑していないときの往復時間を確認する 測定先が異なる結果をそのまま比較する
負荷時の遅延 データ転送中の応答時間の変化を確認する ダウンロードで回線を使い切った後の遅延を見落とす
ジッター・パケットロス 会議や音声通話の安定性を確認する 中継ルーターが応答しないことを、通信のパケットロスと誤認する
実際のタスクでの挙動 初回表示、バッファリング、アップロードが用途に合うか確認する 測定ページの数値だけを見て、普段使うアプリを試さない

ツール選び:ツール名より測定先の固定が大切

ブラウザーの速度測定ツールは、スループットや遅延を手軽に記録するのに便利です。ただし、自動選択されるサーバーは接続経路によって変わる場合があります。自宅のネットワークを測るときは近くのサーバーが選ばれ、海外回線に接続すると別の地域のサーバーが選ばれた場合、測定結果は異なる経路を反映します。これだけで回線による速度低下を計算することはできません。できるだけサーバーを手動で固定し、地域と名称も記録しましょう。

クライアント内蔵の遅延テストは、候補を絞るための参考情報です。接続確立までの時間を測るもの、特定のWebページにリクエストを送るもの、ノードの応答だけを確認するものなど、測定方法はさまざまです。どれも「遅延」と表示されていても、測定定義が異なればクライアントをまたいだ順位付けには適しません。ノードが測定に応答しても、動画再生やアップロード、名前解決が正常とは限りません。

OS標準の ping は、測定先への応答が揺れているかを確認する補助になります。ただし、ICMPによる測定パケットがアプリのプロキシ経由になるとは限りません。システムプロキシでは通常、この種の通信は自動的にプロキシされません。TUNモードで通信を取り込むかどうかも、実装や設定によります。端末から測定先へ直接送った結果を、プロキシ回線の性能と取り違えないようにしましょう。

測定前の準備:まず端末側の条件をそろえる

自宅のネットワークの基準値を測ると、端末や接続環境がすでにボトルネックになっているか判断できます。プロキシを切断した状態で、通常どおりアクセスできる測定先を測り、接続後に同じ測定先を試して経路の影響を確認します。海外の測定先に直接接続できない場合、無理に直接比較する必要はありません。自宅の基準値を接続環境の参考にし、同じ海外の測定先に対する各回線の結果を比較しましょう。

  • ✅ 端末、ネットワーク、クライアントのバージョンを統一し、有線・無線の別も記録する。
  • ✅ クラウド同期、OSの更新、バックグラウンドのダウンロードを一時停止し、ほかの端末が共有ネットワークを大きく使っていないことを確認する。
  • ✅ 無線で測る場合は場所を固定し、電波状況の変化を回線の違いと取り違えないようにする。
  • ✅ 測定サーバー、接続モード、ルールを固定し、ノードが自動で切り替わる設定を無効にする。
  • ✅ クライアントの接続ログを確認し、測定先のドメインが想定した回線を通っているか確認する。
  • ❌ 1回の比較で、ノード・プロトコル・端末・測定サーバーを同時に変更しない。

プラットフォームによる違いも記録しましょう。デスクトップクライアントはシステムプロキシを利用する場合もあれば、仮想ネットワークインターフェースを作成する場合もあります。モバイル端末では通常、OSが提供するVPNインターフェースを通じて通信します。ブラウザー拡張機能の影響は、ブラウザー内の通信に限られることが多いです。同じサブスクリプションでも通信を取り込む範囲は異なるため、測定結果を同じ条件のものとして単純比較できません。

測定の順序:基準値、回線、実際のタスク

  1. 基準値を記録する。プロキシに接続していない状態でネットワークの性能を測り、測定先へ直接アクセスできるかも記録します。基準値がすでに不安定なら、無線の電波状況、ルーター、バックグラウンド通信を先に確認しましょう。
  2. 有効なサブスクリプションを追加する。アカウント画面からサブスクリプションURLをコピーし、クライアントのインポート機能で設定を更新します。サブスクリプションはノードやルールなどの設定を取得するためのもので、個別ノードのアドレスではありません。インポート先の種類を間違えないようにしましょう。
  3. 回線と経路を確認する。測定する回線を手動で選び、接続ログで測定リクエストが通ったノードを確認します。測定先のドメインが直接接続になっている場合は、クライアントの案内に従ってルールを調整してから記録を始めましょう。
  4. 同じ測定を繰り返す。測定先、ツール、モードを変えずに結果を記録します。回線を交互に測ることで、前半の回線だけが空いている時間帯、後半の回線だけが混雑する時間帯に測られる偏りを防げます。
  5. 実際のタスクで確かめる。同じWebページを開き、同じコンテンツを再生し、同じファイルをアップロードして、初回表示までの待ち時間やバッファリング、転送の安定性を確認します。使い心地と測定ツールの結果をあわせて判断しましょう。

サブスクリプションURLにはアクセス用の認証情報が含まれることがあるため、機密情報として管理してください。サポートへ記録を送る際は、URL全体、トークン、アカウント情報を隠し、問題の特定に必要なノード名、時刻、エラーメッセージだけを残しましょう。URLが漏えいした場合は、公開したまま転送を続けず、管理画面で利用できる方法に従って再発行してください。

時間帯と記録:最も良かった結果だけを残さない

普段利用する時間帯を選び、比較的空いているときと混雑しているときの両方を測りましょう。継続的なダウンロード測定は、共有帯域、サーバー負荷、経路の混雑の影響を受けやすく、1回の最高値から分かるのはその瞬間の状態だけです。測定結果は元のまま保存し、典型的な性能や変動幅、失敗したケースにも注目してください。見栄えのよい結果だけを切り取るのは避けましょう。

繰り返し測った結果は、中央値で典型的な水準を把握しつつ、最も悪かった値と異常時の状況も残します。OSの更新、無線の再接続、測定先の変更があった場合は、無効な記録として印を付けて再測定し、回線の順位付けに混ぜないでください。以下は記録項目の例であり、VPNPackの実測データではありません。

速度測定の記録表:実測後に記入し、結果を先に決めない
記録項目 記入内容 目的
測定環境 日時・時間帯、接続ネットワーク、端末、クライアント 同じ結果を再現できるか確認する
接続経路 ノード名、モード、適用されたルール 測定対象の回線を正しく通ったか確認する
測定先 ツール、サーバー名、地域 異なる経路の結果を比較しないため
測定結果 ダウンロード、アップロード、遅延、ジッター、パケットロス スループット不足と接続の不安定さを見分ける
実際のタスク 初回表示の待ち時間、バッファリング、会議の中断、異常 数値と普段の使い心地を照らし合わせる

結果の見方:回線名だけでは性能は分からない

直結は通常、クライアントから海外の入口へ直接接続する方式を指します。中継は、接続先に届く前にアクセス用または転送用のノードを経由します。IEPL専線は一般に、通信事業者が提供する専用のイーサネット伝送回線を指します。いずれも経路や伝送方式の説明であり、速度の順位を示すものではありません。入口の負荷や共有容量、海外側の出口、接続先のWebサイトも結果に影響するため、名称だけで優劣を判断しないようにしましょう。

Shadowsocks、VMess、Trojan、VLESSはプロキシのプロトコル、またはプロトコル体系です。Hysteria2とTUICは、QUICをベースにした伝送方式を採用しています。プロトコル名だけで最終的な速度が決まるわけではなく、クライアントの実装、伝送設定、端末の性能、ネットワーク側のUDP通信の扱いも影響します。サブスクリプションが対応する方式は、管理画面とクライアントの互換性情報で確認しましょう。名前から対応状況を推測しないでください。

プロトコルを変更して性能に差が出た場合は、できるだけ同じ回線と測定先を使って比較しましょう。それができない場合に分かるのは接続構成全体の違いであり、差をすべてプロトコルの影響と断定できません。マルチスレッド測定では合計スループットが高くなる一方、単一接続でのダウンロードが遅い問題を見落とすこともあります。大容量ファイルを利用する場合は、総合スコアだけでなく実際のダウンロードでも確認してください。

トラブルシューティング:症状から原因を切り分ける

速度測定は速いのに、Webページの初回表示が遅い

まずDNSの名前解決、接続の確立、適用されるルールを確認しましょう。速度測定ツールは継続的にデータを転送するのが一般的ですが、Webページは複数のドメインにアクセスすることがあります。一部のリソースだけ経路が誤っていると、ページ全体の表示が遅くなる場合があります。ブラウザーのキャッシュや既存の接続によって、同じページを再度開いたときに速く見えることもあるため、比較時はキャッシュの条件をそろえてください。

DNSリークとは、名前解決のリクエストが想定外の経路を通ることです。「Webページの表示が遅い」こととは別の問題です。プロキシの出口とDNSサーバーの地域が異なるだけで、DNSリークとは判断できません。クライアントのDNS設定、ブラウザーの暗号化DNS、OSの名前解決経路、接続ログをあわせて確認しましょう。速度を優先して、証明書の検証やセキュリティ機能をむやみに無効にしないでください。

ダウンロードは正常なのに、会議が途切れる

アップロードの使用状況、負荷時の遅延、アプリが実際に使っている経路を確認しましょう。ダウンロードで帯域を使い切ると、通信の待ち行列が長くなり、リアルタイムのリクエストに時間がかかる場合があります。また、会議アプリではWeb閲覧と異なる伝送方式が使われることもあります。大容量の通信を停止して同じ通話環境でもう一度試し、自宅のネットワークの混雑か、特定の回線の問題かを確認しましょう。

測定ではパケットロスがあるのに、実際の利用に問題がない

中継ルーターが測定パケットへの応答を制限したり、応答の優先度を下げたりすることがあります。経路測定で途中のノードが応答しなくても、その地点で実際の通信データが失われているとは限りません。後続の測定先が正常に応答しているなら、なおさら断定はできません。最終的な測定先への継続的な応答、アプリの通信切断、再送の有無をあわせて判断しましょう。

特定のアプリだけ接続できない

まず、アプリがシステムプロキシに従うか、ルールで除外されていないか、UDPに依存していないかを確認しましょう。ほかのWebページが使えるからといって、すべての経路が正常とは限りません。さらに調べる場合はトラブルシューティングガイドを参照し、サポートチケットから環境情報とエラー記録を個人情報が分からないように加工して送信してください。

結論:用途に合った回線を選ぶ

普段使うタスクで安定している回線を選び、同じ方法で確認した予備の回線も用意しておきましょう。結果に大きな差がなければ、実際に使うときに中断が少なく、切り替えが簡単な方を優先してください。わずかな測定差を理由に設定を頻繁に変える必要はありません。ネットワーク経路は変化するため、測定を常時続けるより、問題が続いたときに再測定する方が有効です。

VPNPackのプランを選ぶ際は、測定に使うデータ量と普段の利用量をあわせて検討できます。月額プランのデータ容量は利用開始日を基準に毎月リセットされ、データパックには有効期限がありません。容量と料金はプラン・料金ページで確認できます。VPNPackでは7日間の理由を問わない返金に対応しています。申請方法はよくある質問をご覧ください。プランの容量は速度を保証するものではありません。回線の性能はこの記事の手順に沿ってご確認ください。

無料で始める