VPNの速度を実測比較する際に大切なのは、最高値を探すことではなく、条件をそろえることです。まずローカルネットワークの基準値を測り、同じ端末・測定先・方法で回線を比較します。最後に、実際に使うアプリでも確認しましょう。ダウンロード速度のスクリーンショットだけでは、ビデオ会議の安定性や混雑時の使いやすさは判断できません。
重要な測定指標：ダウンロード速度以外に見るポイント
通信経路は、ローカル回線、回線の入口、出口、接続先サーバーで構成されます。測定結果が示すのは、測定中における経路全体の状態であり、特定のノードが常に発揮する性能ではありません。指標の意味を把握すれば、回線を切り替えるべきか、Wi-Fiを確認すべきか判断しやすくなります。
| 指標 | 意味 | 主な確認ポイント | 誤解しやすい点 |
|---|---|---|---|
| 往復遅延 | リクエストを送信してから応答が戻るまでの時間。通常はmsで表します。 | 会議でのやり取り、リモートデスクトップ、ウェブページのリクエスト。 | 遅延が小さくても、大容量ファイルのダウンロードが速いとは限りません。 |
| ジッター | 連続して測定した遅延のばらつき。 | 音声の途切れや、映像の動きにむらがないか。 | ツールによって算出方法が異なるため、単純に比較できません。 |
| パケットロス | ツールの判定基準に従って応答が確認できなかった測定パケット。 | 継続的なロスに伴い、遅延や再送、切断が起きていないか。 | 端末が測定用パケットを制限する場合があります。アプリでの確認も必要です。 |
| ダウンロード・アップロードのスループット | 単位時間あたりに実際に転送されたデータ量。一般にMbpsで表します。 | ファイルのダウンロード、添付ファイルのアップロード、会議映像の送信。 | 測定時のピーク値が、転送中ずっと続くとは限りません。 |
| 負荷時の遅延 | アップロードまたはダウンロードで回線を使用中に測定した応答時間。 | ファイル転送中に、ほかの操作が大きく遅くならないか。 | アイドル時の遅延が正常でも、通信が集中すると待ち時間が発生することがあります。 |
速度を記録するときは単位も残しましょう。速度測定サイトではMbps、ダウンロードソフトではMB/sが使われることがあり、数値だけでは比較できません。また、クライアントのサーバー一覧に表示される「遅延」を、そのまま実際の通信の遅延と考えないでください。サーバーへの接続を測るものもあれば、指定したURLへの応答を測るものもあり、測定先や手順が異なります。
ツール選び：まず測定する通信経路を確認
ブラウザーでの速度測定は、通信経路全体のスループット確認に適しています。Speedtestなど測定先を表示するツールを使い、同じサーバーを手動で指定しましょう。自動選択では出口の変更に伴って測定先も変わり、回線を切り替えた際に、接続先までの距離やサーバー負荷の違いが結果に混ざることがあります。
OS標準の ping は、基本的なネットワークの応答を確認するのに便利ですが、通常はICMPパケットを送信します。システムプロキシだけを有効にしている場合、この種のパケットは一般にアプリのプロキシを経由しません。TUNを有効にした場合に通信が取り込まれるかどうかは、クライアントの実装によります。そのため、ターミナルに表示される遅延が、現在使っているプロキシ回線のものとは限りません。クライアントのHTTPプローブはウェブリクエストに近いものの、測定先とルールによる振り分けも確認してください。
継続的なスループットを調べる場合はiperf3を使えますが、利用する権限のあるサーバーに接続してください。公開サーバーは混雑や利用制限の影響を受けるため、回線性能を判断する唯一の基準にはなりません。普段使いのために専用環境を用意する必要はありません。同じ測定先をブラウザーで使い、実際の会議やファイル転送でも確認するほうが、再現しやすいでしょう。
測定前に、テスト通信が選択した回線を実際に通っているか確認します。クライアントの接続ログにある一致ルール、出口アドレス、測定先を照らし合わせて判断し、「接続済み」と表示されていることだけで済ませないでください。接続ログにはアクセス先が含まれる場合があります。共有する前に、機密情報を隠しましょう。
基準値の測定：ローカルネットワークの影響を除く
まず、クラウドストレージの同期、OSの更新、バックグラウンドのダウンロードを一時停止します。端末の位置と接続方法を変えず、可能であればWi-Fiの電波状況に左右されにくい有線接続を使いましょう。測定中に複数の速度測定ページを同時に実行すると、帯域を奪い合い、競合した状態の結果が出てしまいます。
プロキシをオフにし、ローカルネットワークから直接アクセスできる測定先を選んで、基本的な遅延と継続的な通信が正常か確認します。直接接続でも何度も途切れる場合は、ルーター、Wi-Fiの干渉、接続回線を先に確認してください。この基準値はローカル側の問題を特定するためのものです。中国国内からの直接接続と、海外経由のプロキシ接続を単純に優劣比較するものではありません。通る経路が異なるためです。
- ✅ 端末、OS、クライアントのバージョン、接続方法を記録し、比較時も同じ条件にします。
- ✅ プランの状態、残りのデータ通信量、サブスクリプションの更新状況を確認し、状態の異常を回線性能の問題と取り違えないようにします。
- ✅ システムプロキシまたはTUNのモード、ルールによる振り分け、使用中のノードを記録し、測定通信が実際にどこを通るか確認します。
- ✅ ほかの通信を使うタスクを停止し、測定項目を一つ終えてから次に進みます。
- ❌ 端末、Wi-Fiの接続場所、測定サーバーが異なるスクリーンショットを並べて順位付けしないでください。
サブスクリプションURLは、クライアントが設定を取得するための認証情報であり、速度測定用のURLではありません。インポートしたら設定を更新してから回線を選択してください。不審な測定サイトにサブスクリプションURLを渡したり、公開スクリーンショットに表示したりしないでください。クライアントのダウンロード方法とサブスクリプションのインポート方法は使い方で確認できます。
通常時と混雑時の実測手順
普段サービスを使う時間帯を選び、空いている時間だけで測定しないようにします。混雑時間帯の境目は地域や通信事業者によって異なるため、実際に利用する地域の状況を基準にしてください。通常時と混雑時に同じ手順で測定すれば、負荷の変化に対する回線の状態を比較できます。
- 測定条件を固定します。測定先、接続回線、クライアントのモード、ノードを記録し、バックグラウンドで通信していないことを確認します。
- アイドル時の応答を確認します。最低値だけでなく、遅延の変化や異常な途切れも記録します。ツールにパケットロスが表示される場合は、測定方法も書き添えます。
- 次にスループットを測定します。ダウンロード、アップロード、負荷時の遅延をそれぞれ記録し、一時的な速度上昇ではなく、安定して続くかを確認します。
- 比較する回線を切り替えます。測定先を変えず、同じ手順でテストします。時間の経過による偏りを抑えるため、後で測定順を逆にして再確認します。
- 異常値を再測定します。明らかな異常があれば、まずローカルの基準値を確認してから、同じ項目をもう一度測ります。見栄えのよい結果だけを選ばず、異常値も記録に残します。
- 実際に使うアプリでも確認します。普段利用する会議ツール、共同編集ドキュメント、動画配信サービスを開き、操作感、読み込み、継続利用の状態を確認します。
記録表には、日付と時間帯、通信事業者、接続方法、ノード、測定サーバー、測定モード、各指標、実際の使用感を残しましょう。複数回測定すれば、単発の最高値ではなく、中央値やばらつきを比較できます。速度測定では通信量を消費します。特に大容量のスループット測定を、ピーク値を更新するためだけに繰り返す必要はありません。
結果の見方：単一指標の順位ではなく用途で判断
ビデオ会議では、応答が途切れないか、アップロードが安定しているか、混雑時にジッターが大きくならないかを優先して確認します。リモートデスクトップでは操作に対する遅延が重要です。大容量ファイルのダウンロードでは、継続的なスループットと再試行の有無を見ます。動画視聴は、配信サービスが割り当てるコンテンツサーバー、アカウントの状態、キャッシュにも左右されるため、速度測定サイトのダウンロード結果だけで再生状況を判断できません。
ダウンロードは速いのにウェブページの表示開始が遅い場合は、DNSの名前解決、接続の確立、ルールによる振り分けを確認します。DNSはドメイン名をIPアドレスに変換する仕組みです。利用するリゾルバーやDNSリクエストの経路が、結果に影響することがあります。いわゆるDNSリークとは、DNSリクエストが想定外の経路を通る状態です。プライバシー上の境界に関わるだけでなく、接続の使い勝手にも影響する場合があります。ページの表示が遅いというだけでは判断せず、クライアントのDNS設定と実際の名前解決経路を確認してください。
速度測定では問題がないのに特定のアプリが遅い場合は、そのアプリに別のルールが適用されていないか確認します。ブラウザーはシステムプロキシを使っていても、ほかのアプリは使っていないことがあります。TUNはより多くの通信を取り込めますが、ルーティング、除外設定、クライアントの実装にも左右されます。原因を切り分けるため、一度にDNS、プロトコル、ノードを変更せず、一項目ずつ変更して再測定してください。
回線選びの結論：普段使う時間帯に変動が小さく、実際のアプリで問題なく使える回線を優先しましょう。ピーク速度が高くても頻繁に止まる回線を、速度測定の結果だけで安定した回線より上位にするべきではありません。結論には測定したネットワーク、測定先、時間帯を明記し、すべての利用者に当てはまる順位として示さないでください。
回線とプロトコル：測定結果から分かること
直接接続では通常、ローカルネットワークから出口サーバーへ直接アクセスします。中継接続では経路上に転送区間が加わり、入口、中継ネットワーク、出口の状態によって使用感が変わります。IEPL専線は回線の伝送方式を指すもので、アプリのプロトコルではありません。また、利用者の端末から接続先ウェブサイトまでの全区間が専線になるという意味でもありません。中継区間が安定していても、ローカル回線や出口から接続先までの経路がボトルネックになることがあります。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは伝送方式や実装が異なります。クライアント、サーバー設定、接続回線を切り離して、固定の速度ランキングを付けることはできません。Hysteria2とTUICはQUICをベースとしており、UDPの経路状況に左右されます。現在のネットワークでUDPが制限されている場合、性能が変わることがあります。ほかのプロトコルも、具体的な伝送設定、端末の処理能力、サーバー負荷の影響を受けます。
プロトコルを比較する際は、出口と測定先をできるだけ固定し、制御できない条件も記録してください。プラットフォームごとのシステムネットワークインターフェース、バックグラウンドの動作、クライアントの実装も結果に影響します。デスクトップPCでの測定結果は候補回線の絞り込みに使えますが、モバイル端末ではその端末自身のネットワークで確認し、結果をそのまま当てはめないでください。
記録を残す：問題を再現できる形にする
最終的な記録には、測定条件、元の結果、実際に起きた症状をまとめます。たとえば「同じネットワークで混雑時間帯に会議の映像送信が途切れ、回線を切り替えると改善した」と書けば、「速度が出ない」だけより原因を調べやすくなります。複数の回線が同時に遅くなり、直接接続の基準値にも異常がある場合は、まず共通して通るローカルネットワークを確認してください。
サポートが必要な場合は、お問い合わせ窓口から、クライアントのバージョン、発生した時間帯、回線名、試した確認手順をお知らせください。スクリーンショットを共有する際は、サブスクリプションの認証情報、アカウント情報、アクセス内容を隠してください。詳しい確認手順はトラブルシューティングをご覧ください。速度測定の目的は、特定の回線が常に最速だと証明することではありません。現在のネットワークと用途に合い、継続して確認できる回線を見つけることです。