VPNの速度測定で何を確認するかは、ダウンロード速度、応答性、動画再生など、知りたいことによって異なります。一般的な測定ツールは回線の比較に、実際のアプリは使用感の確認に役立ちます。クライアントに表示されるノードの遅延は、候補を絞る目安にすぎません。同じ条件で繰り返し測定し、スクリーンショットの最高速度だけで判断しないことが大切です。

ツール選び:一般的な速度測定とアプリでの確認

測定結果はサービス自体の性能だけを示すものではありません。自宅のネットワーク、接続先の通信事業者、プロキシの入口、出口から測定サーバーまでの経路、サーバーの処理能力などが影響します。測定先を変えると、通る経路も変わることがあります。回線を比較するときはツールと測定先を固定し、実際の用途を確認するときは対応するアプリでも試しましょう。

主なツールで測れること・単独では判断できないこと
ツール・方法 適した用途 主な注意点
Speedtest ダウンロード・アップロード速度とツールが示す遅延の比較 測定先が自動で変わる場合がある。複数接続の結果は、単一のダウンロードの速度とは異なる
FAST Netflix 関連の測定基盤に対するスループットを確認 アカウントで特定のコンテンツを再生できることや、あらゆるサイトでの速度を保証するものではない
クライアントの遅延チェック ノードの候補を絞り、接続に応答があるか確認 TCP または HTTP で確認する場合があり、測定の意味はクライアントによって異なる
ping・経路診断ツール プロキシを経由しない経路や往復遅延、問題の発生箇所を調べる補助 ICMP通信がアプリのプロキシを経由するとは限らず、ルーターが応答を制限する場合もある
iperf と管理下の測定サーバー 管理できる両端でスループットや通信状況を比較 測定サーバーの利用許可と適切なルーティング設定が必要。不特定のサーバーをむやみに測定しない
実際のダウンロード・動画再生・オンライン会議 目的の作業を途切れずに完了できるか確認 コンテンツのキャッシュ、プラットフォームの仕様、接続先の負荷に左右されるため、一般的な測定も併用する

一般的な測定ツールである Speedtest は測定先を固定して比較し、動画視聴の確認には FAST や実際の再生を組み合わせましょう。ウェブページの表示が遅い場合は対象サイトの読み込みを、会議が不安定な場合は実際の通話で音声・映像・再接続の状況を確認します。ダウンロード速度だけで、すべての使用感を判断することはできません。

測定経路:通信がどの回線を通るか確認する

ルールによる振り分けによって、速度測定サイトには直接接続し、目的の海外サイトにはプロキシ経由で接続することがあります。この場合に測定されるのは国内回線の速度であり、出口回線の評価には使えません。測定前にクライアントの接続ログを確認し、測定先のドメインが想定したノードを通っているか、出口の地域が選択した地域と一致しているかを確かめましょう。

ブラウザーとコマンドラインの測定で、通信経路が異なることもあります。ブラウザーはシステムプロキシを使っていても、コマンドラインのプログラムは同じ設定を参照するとは限りません。アプリのプロキシは通常、ping の ICMP 通信を中継しません。仮想ネットワークアダプターを使う場合にその通信が経由するかどうかも、クライアントの実装と設定によります。端末で実行した ping の結果を、そのままプロキシノードの遅延として扱わないでください。

DNSを確認するときは、「名前解決が遅い」のか「DNSリクエストが想定外の経路を通っている」のかを分けて考えます。ブラウザーのセキュアDNS、OSのリゾルバー、クライアントのDNS設定が同時に関わることがあります。DNSチェックに表示されるDNSサーバーの所在地と、プロキシの出口の所在地は一致するとは限りません。設定やリクエストのログも確認し、地域が異なるという理由だけで漏えいと判断しないようにしましょう。

指標の見方:速度・遅延・揺らぎ・パケットロス

ダウンロード・アップロード速度:データ転送能力

ダウンロード速度は大容量ファイルの取得や動画のバッファリングに、アップロード速度は素材の送信、クラウド同期、会議での映像・音声送信に影響します。測定ツールでは Mbps、ダウンロードソフトでは MB/s と表示されることがあり、単位が異なるため数値をそのまま比べることはできません。複数の接続を使って帯域を最大限に利用するツールもあります。一方、単一接続のダウンロードでは、特定の経路や接続先による制限が表れやすくなります。

遅延と揺らぎ:応答の速さと安定性

遅延は一般に、リクエストを送信して応答が返るまでの時間を指します。アイドル時の遅延は負荷が低いときの応答を、ダウンロードやアップロード中の遅延は複数の通信を同時に行う普段の状況に近い応答を示します。帯域を使い切ると遅延が大きくなることがありますが、自宅のルーター内のキュー、上り回線の混雑、経路上の待ち時間などが原因として考えられます。ノードの問題とすぐに決めつけないでください。

揺らぎは遅延の変動を表します。計算方法はツールごとに異なるため、異なるツールの数値をそのまま順位づけするのは適切ではありません。対話型の用途では、応答の速さと継続的な安定性の両方が大切です。平均遅延が良好でも、一時的に大きく途切れることがあります。平均値だけでなく測定中の状況も記録しましょう。

パケットロス:測定方法も確認する

パケットロスが起きると通信の再送が発生し、リアルタイムの音声や映像に影響することがあります。経路上のルーターが測定への応答を返さなくても、データを正常に転送している場合があります。経路の問題を判断するときは、異常が最終地点まで続いているかを確認し、アプリのエラー、再送、接続切断などもあわせて見ましょう。クライアントにタイムアウトと表示されても、測定先がリクエストを拒否しているだけの場合があります。

判断の目安:大容量ファイルの作業では持続的なスループット、ウェブ閲覧やリモート操作では応答速度と変動、会議では上り速度と安定性を重視しましょう。用途を問わず使える単一の回線スコアはありません。

実践手順:比較・再確認できる速度測定を行う

まず条件を固定してから、一つずつ変更します。端末、ネットワーク、ノード、測定サーバーを同時に変えると、速度が変わっても原因を特定できません。次の手順は普段使う回線の選定だけでなく、サポートに問題を伝えるときにも役立ちます。

  1. 他の通信を止める。クラウド同期、大容量ファイルのダウンロード、OSの更新を一時停止し、ほかの端末が帯域を継続的に使っていないか確認します。Wi-Fiの変動が大きい場合は、有線接続でも測定して比較しましょう。
  2. 直接接続時の基準を記録する。プロキシを無効にし、通常アクセスできる測定先を固定して測定します。ツール、サーバー、自宅のネットワーク、時間帯も記録しましょう。測定先に直接接続できない場合は、その基準値がないことを記録し、無理に速度低下を計算しないでください。
  3. プロキシの条件を固定する。出口の地域とノードを選び、測定リクエストがそのノードを経由することを確認します。クライアントのモード、プロトコル、ルール設定も記録しましょう。
  4. 測定先を固定する。ツールでサーバーを手動選択できる場合は、同じサーバーを使い続けます。自動選択で測定先が変わった場合は別のサンプルとして記録し、直接比較しないようにしましょう。
  5. 繰り返し測定し、結果を残す。最高値だけを記録しないでください。よく見られる速度、変動、失敗の状況を記録します。ノードを切り替えた後は接続が安定するのを待ってから、次の測定を始めましょう。
  6. 実際の用途で確認する。目的のウェブサイトを開く、ファイルをダウンロードする、動画を再生するなど、普段の作業を行い、途切れがないか確認します。測定後は元の振り分け設定に戻してください。

記録表は簡潔で構いません。日付と時間帯、自宅のネットワーク、出口ノード、測定サーバー、ダウンロード・アップロードの結果、遅延の変動、アプリの状況を残しておけば、あとから確認できます。記録を共有する際は、サブスクリプションURL、認証情報、個人アカウントの内容を隠してください。

時間帯の選び方:普段の時間と夜間ピークを比較

どのネットワークにも当てはまる測定時刻はありません。実際にサービスを使う時間帯を含め、比較用に普段の空いている時間帯と夜間のピーク時間帯の両方で記録を残しましょう。同じ時間帯に回線を比較するほうが、早朝に測ったノードと夜に測った別の回線を比べるよりも参考になります。

夜に遅くなる原因は、自宅のWi-Fi、通信事業者間の接続、プロキシの入口、出口から接続先のプラットフォームまでのいずれにも考えられます。直接接続時の基準値とプロキシ経由の結果がどちらも低下しているなら、まず自宅の接続を確認しましょう。直接接続が安定していてプロキシ経由の結果全般が低下している場合は、入口と出口の経路を比較します。特定の接続先だけ遅い場合は、そのプラットフォームと出口からの経路をさらに確認してください。

IEPL 専用線、中継、直接接続は、異なるネットワーク構成や通信方式を指すもので、速度測定の結果そのものではありません。専用線と呼ばれていても、エンドツーエンドの経路全体に混雑がないとは限りません。また、中継が直接接続より必ず遅いわけでもありません。比較するときは測定先、時間帯、端末の条件をそろえましょう。回線の種類とプロトコルについては回線とプロトコルの解説をご覧ください。

測定結果の確認:ツール側とアプリ側を切り分ける

  • ✅ 速度測定は速いのに動画が途切れる:出口と経路が同じか確認し、動画プラットフォーム、コンテンツのキャッシュ、実際の再生状況も確認しましょう。
  • ✅ ノードの遅延は小さいのにウェブページが遅い:DNS、接続確立、接続先サーバーの応答を確認しましょう。測定時の遅延が小さくても、ページ内のすべてのリソースが速く読み込まれるとは限りません。
  • ✅ アップロード中に操作への応答が大きく遅れる:上り通信を一時停止して比較し、自宅のネットワーク内のキューや帯域の使用状況を確認してから、回線を切り替えるか判断しましょう。
  • ✅ 特定のクライアントだけ遅い:プロキシモード、プロトコルの対応状況、バージョンの互換性、ルールを比較し、測定リクエストが同じ出口を通っているか確認しましょう。
  • ❌ 最速のスクリーンショットだけで順位をつける:測定先、時間帯、振り分け設定がわからないスクリーンショットでは、再現性のある回線比較はできません。

Windows、macOS、iOS、Android、Linux のクライアントは、通信を取り込む方法がそれぞれ異なる場合があります。システムプロキシと仮想ネットワークアダプターでは対象となるアプリの範囲が異なり、OSの権限、バッテリー設定、ほかのネットワーク拡張機能も通信状況に影響します。複数のOSで試した結果は個別に記録し、端末による違いをそのままサービスの違いと判断しないようにしましょう。

プロトコルも速度ランキングではありません。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC は通信方式、クライアントの実装、ネットワークへの適応性がそれぞれ異なります。プロトコル名だけで実際の性能は判断できません。プロトコルを比較するなら、出口と測定先をできるだけそろえましょう。条件が違うと、プロトコルではなく回線の違いを測っている可能性があります。

選び方:まず目的の作業を安定して完了できる回線を見つけ、そのうえで持続速度とピーク時間帯の変動を比べましょう。測定ツールは判断材料を示し、実際のアプリで使って結果を確かめます。両者の結果が一致しない場合は、見栄えのよい数値を選ぶのではなく、まず通信経路を確認してください。