VPNの速度測定を正確に行う方法：ツール・時間帯・指標を実測比較

まず速度測定の通信経路を確認する

測定時の通信は、端末の無線LAN、インターネットサービスプロバイダー、プロキシの入口・出口、速度測定サーバーを経由する場合があります。結果は経路上のボトルネックによって変わります。接続先地域が同じでも途中の経路が同じとは限りません。また、クライアントに接続済みと表示されていても、すべてのアプリがプロキシを経由するとは限りません。

ルールベースの振り分けでは、速度測定用のドメインがプロキシを経由せず、直接接続されることがあります。ブラウザーのプロキシ設定はブラウザー内の通信しか対象にしない場合があり、コマンドラインツールがシステムのプロキシ設定を読み込むとも限りません。TUNモードはより多くのアプリ通信を取り込めますが、ルート除外、クライアントのルール、システム設定の影響を受けます。記録を始める前にクライアントの接続ログを確認し、測定リクエストに適用されたルール、使用ノード、接続先地域を特定してください。

プロキシを無効にした基準値の測定では、日本国内から通常アクセスできる測定先を選びます。無線区間やアクセス回線が混雑していないかを確認するための測定であり、異なる地域へのプロキシ接続の結果との差を、そのまま暗号化による速度低下とみなすのは適切ではありません。測定先が異なれば経路も変わり、差には距離、相互接続、サーバー負荷が含まれます。

接続先を確認するときは、確認用ページと速度測定の両方で同じプロキシ方式を使用します。ブラウザーに表示された接続先だけでは、別のコマンドラインプロセスも同じ回線を経由しているとは確認できません。

ツールの選び方：ウェブの最高速度と実際のタスクを分けて測る

一般的なウェブ速度測定ツールは、回線の最大スループットを手早く確認するのに便利です。ただし、回線をできるだけ使い切るため、複数の接続を同時に確立することがあります。単一ファイルのダウンロード、リモート端末、APIリクエストでは接続の挙動が異なるため、「速度測定は速いのにアプリは遅い」ということも起こり得ます。ツールだけですべての疑問に答えることはできません。実際の用途に近い方法で測定することが大切です。

回線を比較するときは速度測定サーバーを手動で固定し、名前と地域を記録します。毎回「最寄りのサーバー」を自動選択すると、測定先が変わっている可能性があります。速度測定サイトごとにアルゴリズム、測定時間、同時接続の方針も異なります。互いの結果を補足する用途には適していますが、同じランキングに並べて優劣を決めるのには向きません。

ウェブページの使い心地を調べるなら、実際に使うページを開いて読み込みの過程を確認します。ファイル転送を調べるなら、信頼できる提供元の、測定が許可された固定ファイルを使用してください。管理していない公開サーバーに継続的な負荷をかけたり、個人の認証情報を含むURLを公開記録に載せたりしないでください。

指標の見方：遅延・パケット損失・帯域幅

遅延とジッターは、操作の滑らかさを左右する

遅延は通常、リクエストの往復にかかる時間を指します。ただし、クライアントのノード確認、ウェブ速度測定、pingでは測定対象が異なる場合があります。クライアントはプロキシのハンドシェイクやウェブリクエストを測ることがあり、pingは通常ICMPの応答を測定します。単位が同じというだけで数値を直接比較せず、測定方法と対象をあわせて記録してください。

ジッターは遅延のばらつきを表します。平均値が近い回線でも、一方で大きな遅延の跳ね上がりが頻発すれば、音声通話、リモート操作、リアルタイムのやり取りが不安定になることがあります。通信が空いているときの遅延は、ダウンロード中の遅延と同じとは限りません。回線が混雑すると待ち行列が長くなり、応答が遅れるため、負荷がかかった状態の挙動も個別に確認する必要があります。

パケット損失は、診断への応答と実際の通信を分けて考える

中継ルーターは診断用の応答を低い優先度で処理することがあります。経路診断で特定のホップに損失が表示されても、その後の接続先から正常に応答があれば、そのホップが同じ割合の実通信を破棄しているとは限りません。最終接続先への測定、接続の再試行、転送の停止、実際のアプリの挙動をあわせて判断してください。

実際にパケット損失が起きると、信頼性のあるトランスポートプロトコルでは再送や輻輳制御が発生し、継続的なスループットが低下することがあります。UDPベースの通信でもパケット損失の影響が自動的になくなるわけではなく、回復や輻輳への対処方法が異なるだけです。プロトコル名だけで安定性が保証されると考えないでください。

帯域幅のピークは、単一タスクの速度とは限らない

速度測定のスループットは通常ビット毎秒で表示されますが、ダウンロードソフトではバイト毎秒を使うこともあります。まず単位を確認してから数値を比較してください。同時接続で合計スループットが高くても、単一接続が同じ速度になるとは限りません。一時的なピークが高くても、長時間のダウンロードで速度が落ちないとは言えません。ファイル転送では瞬間的な最高値より、持続速度と最後まで完了できるかどうかが参考になります。

日中と夜間の混雑時間帯：条件をそろえて再測定

夜間に速度が落ちる原因として、家庭内のネットワーク利用の競合、プロバイダー間の相互接続、プロキシの入口や出口、接続先サーバーの負荷が考えられます。発生時刻だけでは、どの区間が混雑しているか特定できません。日中の測定結果を比較対象にしつつ、同じ端末、アクセス回線、ノード、クライアントのバージョン、測定先をできるだけ維持してください。

1. 測定への干渉を減らす。クラウド同期、システム更新、他の端末による大容量通信を一時停止します。端末の電源状態と放熱環境を一定に保ち、省電力設定による変化を回線の影響と取り違えないようにしてください。
2. 基準値を記録する。プロキシを無効にし、通常アクセスできる固定の測定先をテストして、アクセス方法とローカルネットワークの状態を記録します。無線接続が不安定な場合は、有線接続を試すか、アクセスポイントに近い場所で測定してください。
3. 経路を固定する。接続先ノードを指定し、自動でノードが切り替わるグループを一時停止して、測定用ドメインがそのノードを経由していることを確認します。記録中にプロトコルと地域を同時に変更しないでください。
4. 同じ条件で比較する。同じツールとサーバーを使って繰り返し測定し、代表的な範囲や異常を記録します。最も良い結果だけを残さないでください。ダウンロードテストでは、プランのデータ通信量を消費します。
5. 時間帯を変えて再測定する。普段利用する夜間の混雑時間帯にも同じ手順を繰り返し、実際のタスクでも確認します。1日の偶然の変動を傾向とみなすより、複数日にわたる結果を比較するほうが確実です。

異なる回線を比べる場合は交互に測定し、特定の回線だけ空いている時間帯に測ることがないようにします。前の測定で発生した通信が落ち着くまで時間を空け、ダウンロードが続いているうちに次の測定を始めないでください。スマートフォンとパソコンの結果は別々に記録し、同じサンプル群に混ぜないようにします。

実測記録：測定条件と結果をセットで残す

信頼できる記録には、少なくとも「どのような環境で、どの経路を通り、何を対象に、どのような測定をしたか」が必要です。条件がなければ、スクリーンショットの数値が目立っていても再現は困難です。以下の項目は手元のメモにそのまま使えます。アカウントのパスワードやサブスクリプションURLを記入する必要はありません。

• ✅ 環境：日付、時間帯、端末、OS、クライアントのバージョン、アクセス方法、バックグラウンドタスクの状態。
• ✅ 経路：ノード名、接続先地域、プロトコル、プロキシ方式、測定リクエストに適用された振り分けルール。
• ✅ 測定先：速度測定ツール、固定サーバーまたは実際のサービスのドメイン。キャッシュや同時接続を使用したかも記録。
• ✅ 結果：上り・下りの持続的な速度、遅延の変化、確認できたパケット損失、再試行や中断の状況。
• ✅ 判断：今回の結果がどのタスクの参考になるか、再測定が必要な点、ピーク値だけでなく異常の記録も残す。

結果を共有するときは、サブスクリプションURL、トークン、アカウント情報を隠してください。サブスクリプションURLはクライアントがノード設定を取得するためのもので、アクセス認証情報を含む場合があるため、公開用の速度測定資料には適しません。サポートに問い合わせる際は、個人情報を伏せたログ、発生した時間帯、接続先の情報を添えると、「速度が遅い」と繰り返し伝えるより原因を特定しやすくなります。

結果が一致しないときは、経路を区間ごとに確認する

速度測定は速いのにウェブページの表示が遅い

まず対象ドメインに想定したルールが適用されているか確認し、DNSの名前解決、接続確立、応答待ち、リソースのダウンロードを順に確認します。ウェブページのTime to First Byteには配信元サーバーの処理時間も含まれるため、回線の遅延そのものとはみなせません。DNSが適切でないコンテンツ配信ノードを返した場合、通信経路が遠回りになることもあります。

DNSリークとは、プロキシのルールに従うはずの名前解決リクエストが、想定外の経路から送信されることです。これはプライバシーと経路の一貫性に関わる問題であり、「DNSが必ず遅い」という意味ではありません。ブラウザーの暗号化DNS、システムのリゾルバー、クライアントのDNS設定が互いに影響する場合があるため、ログもあわせて確認してください。検査ページに表示されたリゾルバーの地域だけでは、リークの有無を判断できません。

プロトコルを変えて速くなったら、プロトコルの性能が上がったと言える？

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICでは、通信の仕組みやクライアントの対応状況が異なります。このうちHysteria2とTUICはQUICをベースにしています。結果は個別の通信設定、輻輳制御、端末の性能、ネットワーク側のUDP処理にも左右されます。プロトコルと同時にノードも変更した場合、速度の変化をすべてプロトコルの違いに帰することはできません。

専用線・中継・直接接続をどう比較する？

直接接続とは一般に、クライアントから海外のノードへ直接接続する方式です。中継では通常、まず入口に接続し、そこから出口へ転送します。IEPL専用線は特定の伝送経路を指し、クライアントのプロキシプロトコルではありません。サービスで専用線と呼ばれていても、利用端末から接続先ウェブサイトまでの全区間が専有されるわけではありません。回線の名称はネットワーク構成を理解する手がかりにはなりますが、エンドツーエンドの実測に代わるものではありません。

Windows、macOS、Linux、モバイル端末では、プロキシが通信を取り込む方式が異なる場合があります。あるプラットフォームでは正常で、別のプラットフォームでは問題が起きる場合、速度を比べる前にルール、DNS、TUNの権限、実際の接続記録を確認してください。関連するトラブルシューティングは技術リファレンスをご覧ください。地域や回線の情報を確認する場合は、回線一覧をご覧ください。

回線の選び方：実際のタスクに合うものを優先する

ウェブ閲覧ではリクエストへの応答と読み込みの安定性、ファイル転送では持続的なスループット、リモート操作では遅延とジッター、長時間の接続では切断や復旧の状況が重要です。まず用途を決め、普段使う時間帯にタスクを継続して完了できる回線を選びましょう。ピーク速度を上げるためだけに接続先を何度も切り替える必要はありません。