VPNの速度測定：まず比較する内容を決める
VPNの速度を正しく比較するには、測定条件をそろえ、用途に合わせて結果を読み取ることが大切です。ダウンロード速度が速くても、ビデオ会議が安定するとは限りません。クライアントに表示されるノードの遅延が低くても、目的のサイトが速く表示されるとは限りません。測定前に、ファイルのダウンロード、動画視聴、リモートワーク、リアルタイム通信など、用途を明確にしましょう。
ひとつのアクセスは、端末、家庭内ネットワーク、プロバイダーの接続網、プロキシ回線、接続先サービスを経由します。測定結果が示すのは、その時点での特定の経路全体の状態であり、経路上の一部分だけの性能を証明するものではありません。測定サーバーや接続方法、ルールによる振り分けを変えると、結果を比較できなくなることがあります。
判断の基本：まず通常接続の基準値を測り、次にプロキシ経由の経路を測定し、最後に実際のアプリで確かめます。一時的なピーク値より、繰り返し再現できる結果のほうが参考になります。
速度・遅延・ジッター・パケットロスの見方
速度測定サイトではダウンロード速度が目立つ位置に表示されますが、用途によってボトルネックは異なります。関係のない数値で選んでしまわないよう、まず各指標と利用体験の関係を確認しましょう。
| 指標 | 示す内容 | 関係の深い用途 | 誤解しやすい点 |
|---|---|---|---|
| ダウンロードスループット | 一定時間内に実際に受信したデータ量 | ファイルのダウンロード、動画のバッファリング | 複数接続で測ったピーク値は、単一ファイルの持続速度とは異なる |
| アップロードスループット | 一定時間内に実際に送信したデータ量 | クラウドバックアップ、会議映像の送信 | ダウンロードが速くても、アップロードも速いとは限らない |
| 往復遅延 | リクエストを送信してから応答が戻るまでの時間 | リモートデスクトップ、インタラクティブな操作 | 測定対象までの往復時間のみを示す |
| ジッター | 連続測定における遅延の変動幅 | 音声通話、リアルタイム動画、ゲーム | ツールによって算出方法が異なる場合がある |
| パケットロス | ツールの定義に基づく、未到達または応答が得られなかった状態 | リアルタイム通信、接続の安定性確認 | 測定用パケットに応答がなくても、実際の通信データが失われたとは限らない |
| 負荷時の遅延 | ダウンロードまたはアップロードで回線を使用中の往復遅延 | ファイルを転送しながら会議に参加 | アイドル時の遅延が低くても、負荷時には大幅に遅くなることがある |
帯域幅は回線の容量を表す概念で、速度測定で実際に得られる値は通常スループットです。ツールでは Mbps、ダウンロードアプリでは MB/s と表示されることがありますが、単位が異なるため数値をそのまま比較できません。平均値、瞬間値、ピーク値のどれが表示されているかも確認しましょう。
ジッターは「最大遅延から最小遅延を引いた値」を指す統一用語ではありません。隣り合う測定値の変化から算出するツールもあれば、別の統計方法を使うものもあります。回線を比較する際はツールと設定をそろえ、異なるツールのジッター値を同じランキングに並べないようにしましょう。
速度測定ツール：一般的な測定と実際の利用確認を組み合わせる
ブラウザーで使える速度測定ツール
Speedtest や Fast.com などの一般的なツールでスループットを確認できます。ただし、接続先サーバーや測定方式はそれぞれ異なります。サーバーを手動で選べる場合は、回線ごとに同じ測定先を指定しましょう。自動選択の場合は、実際に選ばれたサーバーを記録します。自動で選ばれる近隣サーバーへの経路が、仕事で使うサイトへの経路を代表するとは限りません。
ブラウザー拡張機能のプロキシ、システムプロキシ、トンネルモードでは、プロキシを通る通信の範囲が異なります。測定サイトが開けても、測定通信が対象ノードを経由しているか確認が必要です。クライアントの接続ログ、ルールの適用状況、出口アドレスを確認し、通常接続の結果をプロキシ経由の速度として記録しないようにしましょう。
システムの測定機能と実際のアプリで確認する
システム標準の ping は接続先の応答の変化を確認するのに役立ちますが、主に ICMP を使うため、ブラウザーと同じシステムプロキシを通るとは限りません。システムプロキシのみを有効にしている場合、ping は通常接続のまま送信されることがあります。また、測定リクエストを制限または無視する接続先もあるため、タイムアウトだけで回線が使えないと判断しないでください。
実際のアプリでの確認も重要です。ダウンロードでは転送が継続するか、会議では音声や映像が途切れないか、動画ではバッファリングが安定しているかを見ます。ブラウザーの開発者ツールを使えば、DNS の名前解決、接続の確立、応答待ちなどの段階を切り分けられます。ただし、単一リクエストの待ち時間は接続先サーバーの処理速度にも左右されます。
クライアントの「遅延テスト」は、ノードの入口を測定する場合もあれば、ノード経由で指定 URL にアクセスする場合もあります。クライアントの説明を確認し、どの区間を示す結果なのかを判断しましょう。クライアントごとに測定値の意味が異なるため、数値をそのまま横並びで比較するのは適切ではありません。
実測手順：条件をそろえて回線を切り替える
以下の手順はパソコンだけでなく、モバイル端末でも使えます。モバイル端末では Wi-Fi とモバイルデータ通信のどちらを使ったかも記録し、測定中に接続方法を切り替えないでください。
- 端末とネットワーク環境を整える。クラウド同期、システム更新、バックグラウンドでのダウンロードを一時停止し、端末の設置場所と接続方法をそろえます。パソコンでは可能であれば有線接続を使い、無線の電波状況による変動を抑えましょう。
- 通常接続の基準値を測る。プロキシを経由しない状態で、現在のネットワークから利用できる同一の測定先を使い、スループットと遅延を記録します。通常接続では測定先にアクセスできない場合は、比較できる基準値がないと記録し、測定失敗を速度ゼロとして扱わないでください。
- クライアントの設定を記録する。ノード名、プロトコル、プロキシモード、ルール、測定サーバーを書き留めます。接続が安定したことを確認してから測定を始め、ノード切り替え時の一時的な切断を結果に含めないようにしましょう。
- 測定を繰り返し、ばらつきも記録する。最も良い結果だけを選ばず、各回の生データを残して、よく見られる値や大きな変動を確認します。可能であればノードの測定順を入れ替え、時間の経過による偏りを抑えましょう。
- 実際の用途で確認する。同じサイト、同種のファイル、同じ画質設定を使い、速度が持続するか、操作がスムーズかを確認します。ウェブページが一度開けたことだけで、実際の利用感を判断しないでください。
- 比較する条件だけを変える。プロトコルを比較するなら、地域、測定先、モードをできるだけそろえます。ノード、プロトコル、ルールを同時に変えた場合に比較できるのは設定全体であり、差をプロトコルだけに結びつけることはできません。
リモートの速度測定サーバーを使う場合は、利用許可を得たテスト用エンドポイントを使用し、出所のわからないサーバーに大量の通信を送り続けないでください。ブラウザーでの速度測定も通信量が大きくなることがあります。従量課金の場合は特に、ピーク値を追い求めて測定を繰り返さないようにしましょう。
測定する時間帯と記録方法
普段よく使う時間帯に加えて、比較的空いている時間帯も測定しましょう。夜間の混雑時間帯も確認する価値がありますが、混雑する時間は地域によって一律ではありません。自宅の接続網、ノードの所在地域、接続先サービスそれぞれで負荷の変化が異なります。「夜」とだけ記録するより、実際の日付と時刻を残すほうが役立ちます。
比較する回線はできるだけ交互に測定し、一方を空いている時間帯、もう一方を混雑時だけに測ることは避けましょう。異常な結果が出た場合は、まずローカル環境で誰かがファイルをアップロードしていないか確認してから、再測定します。日をまたいで比較する場合は、ネットワーク環境の変化も記録に残してください。
- ✅ ネットワーク環境：端末、接続方法、利用中のプロバイダー、バックグラウンド処理の有無。
- ✅ プロキシの条件：ノード、プロトコル、クライアントのモード、測定通信にプロキシのルールが適用されたか。
- ✅ 測定対象：ツール、サーバーの場所、実際の利用内容、測定日時。
- ✅ 生データ：ダウンロード、アップロード、遅延、変動、途切れや切断の記録。
- ❌ 出口が不明な結果、異なるサーバーでの結果、単位の異なる結果をそのまま並べて比較しない。
結果を整理する際は、中央値で一般的な水準を示しつつ、低い値や変動幅も残しましょう。会議やリモートデスクトップでは、一時的な大きな停止も結論に含め、見栄えのよい平均速度に隠さないことが大切です。測定回数が限られる場合は、「今回の環境と時間帯での結果」として記録し、長期的な性能保証のように一般化しないでください。
速度の異常を切り分ける：回線・ルール・接続先を確認
速度測定は速いのに、ウェブページの表示が遅い
まず、すべてのサイトで遅いのか、特定のサービスだけなのかを確認します。速度測定ツールは複数接続を使うことがありますが、ウェブページの表示には DNS の名前解決、接続の確立、CDN の接続先選択、サーバーの応答などが影響します。ルールによる振り分けで測定通信はプロキシ経由、対象サイトは通常接続となり、結果が食い違って見えることもあります。
DNS の処理が想定どおりかも確認しましょう。DNS リークとは、名前解決のリクエストが想定外の DNS リゾルバーに送信される状態を指し、単に「名前解決が遅い」という意味ではありません。プライバシーや CDN の接続先選択に関わりますが、ページ表示の遅さだけでリークが起きたとは判断できません。クライアントの DNS 設定、ルール、実際の名前解決経路をあわせて確認してください。
遅延は低いのに、ダウンロードが遅い
遅延が低いことからわかるのは、特定の接続先までの往復時間が短いということだけで、十分なスループットがあるとは限りません。ノードの出口、接続先による速度制限、ローカルの接続網、端末の処理能力がボトルネックになることがあります。まず同種の別のダウンロード先で確認し、通常接続の基準値と比較しましょう。最初から設定をあれこれ変更するのは避けてください。
プロトコル名や回線の種類から性能を予測できる？
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC は、それぞれ異なるプロキシプロトコルまたは方式です。通信方式、実装、動作条件が異なるため、名称だけでどれが必ず速いかを判断することはできません。ネットワーク上の制限やパケットロスへの反応も方式によって異なるため、比較時はクライアントとサーバーの設定に互換性があることを確認しましょう。
通常接続、中継、IEPL 専用線も、同じ階層の性能指標ではありません。中継は転送経路が増えますが、ルーティングが改善する場合があります。通常接続は経路がより直接的でも、インターネット上の相互接続の影響を受けます。IEPL は専用イーサネット接続サービスですが、実際のアクセスにはその先の出口や接続先までの経路も関わります。名称は構成を理解する手がかりになりますが、最終的な使い心地は同じ条件で確認してください。
用途に合わせて自分なりの判断基準を作る
ダウンロードやクラウド転送では、持続的なスループットと長時間転送が途切れないかを優先して確認します。動画再生では実際の画質とバッファリングの状態を、会議やリモートデスクトップではジッター、パケットロスの兆候、負荷時の遅延を重視しましょう。速度測定の順位を上げるために、本当に必要な安定性を犠牲にしないでください。
測定後は、普段使いに適した設定と、異なる特性を持つ予備の回線を残しておきましょう。ネットワークやクライアントの設定を変更した後に、重要な用途を再確認すれば十分です。回線の対応地域数は選択肢の広さを示すもので、速度の証明にはなりません。X5VPN の回線情報は回線一覧で、通信量のルールや料金体系はプラン・料金ページで確認できます。
サポートへ問い合わせる際は、測定日、ノード名、接続方法、クライアントのモード、発生した問題を伝えると、「遅い」とだけ伝えるより原因を特定しやすくなります。必要な情報は管理パネルのチケットから送信できます。スクリーンショットを共有する前に、サブスクリプションリンク、パスワード、アクセストークンを隠し、問題の説明のためにアカウント情報を公開しないでください。