VPN速度測定の正しい方法と実測ツール

VPNの速度測定で何が正確かは、帯域の上限、ウェブ応答、動画の継続再生、ゲームや通話のリアルタイム安定性のどれを測るかで変わります。ブラウザの測定値が高くてもリモートデスクトップが滑らかとは限らず、クライアントの低遅延表示から下り速度の高さを直接判断することもできません。最も正確な数値を一つ探すのではなく、まず直結時の基準値を取り、同じ端末・回線・測定対象で繰り返し、下り・上り・遅延・ジッター・パケットロスを記録するのが実用的です。

回線の体感は、ローカル接続、通信事業者の出口、地域間ルーティング、サーバー負荷、通信プロトコル、接続先サイトによって決まります。一度だけ測ると短時間の変動を長期的な性能と取り違えやすく、下り速度だけでは操作時の遅延や接続安定性を見落とします。以下の手順なら宣伝ページに頼らず、ブラウザの測定ツール、システムのネットワーク状態、実際のアプリで再現できます。

まず速度測定ツールが何を測っているか確認する

一般的な測定結果はどれも「速度」に見えますが、意味は同じではありません。ブラウザの測定では通常、テストサーバーが自動選択され、複数の同時接続で回線をできるだけ使い切るため、現在の環境におけるスループットを確認するのに適しています。クライアントのダウンロード表示は、その時点でプロキシ経由を通過している通信量にすぎないことが多く、バックグラウンド同期やキャッシュ、他のアプリの影響を受けます。ファイルのダウンロードや動画再生は実際の用途に近い一方、接続先サイトの速度制限やコンテンツ配信方式も結果に含まれます。

Speedtest、Cloudflare speed test、Fast.comなどの公開ツールは確認の入口として使えますが、どれか一度の結果を回線の結論にしてはいけません。ツールごとに測定ノード、同時接続数、転送方式が異なるため、結果に差が出るのは自然です。重要なのはツールと測定対象を固定し、同じ条件で比較できるようにすることで、複数ツールから最高値だけを選ぶことではありません。

比較できる直結時の基準値を作る

測定前にプロキシ接続を切り、現在のネットワークを直接接続した状態で記録します。直結時の基準値は、プロキシが必ず遅いと証明するためではなく、問題がローカルネットワークにあるのか回線にあるのかを切り分けるためのものです。直結時からジッターが大きい、無線が不安定、バックグラウンド通信が多い場合は、どのノードに切り替えても安定した結果を得にくくなります。

• ✅ 同じ端末を使い、有線・無線の接続方法もできるだけ揃える。
• ✅ システム更新、クラウド同期、動画再生、大容量ファイルのダウンロードを一時停止する。
• ✅ 経路を変える他のプロキシ、アクセラレーター、セキュリティトンネルを終了する。
• ✅ 公開測定ツールと測定サーバーを固定し、毎回自動で対象が変わらないようにする。
• ✅ 直結時とプロキシ接続時の下り・上り・遅延・ジッター・パケットロスをそれぞれ記録する。
• ❌ クライアントのノード一覧に表示される遅延の色だけを、完全な測定結果とみなさない。
• ❌ 端末、接続ネットワーク、測定対象を同時に変えた状態でノードの優劣を比較しない。

次に測定する回線へ接続し、出口地域が想定どおりであることを確認して、同じ手順を繰り返します。測定中にノード一覧を何度も更新したり、プロトコルを切り替えたりしないでください。接続の再構築、名前解決、キャッシュの変化が余分な変数になるためです。各回の測定後は、時間帯、ノード地域、回線タイプ、プロトコル、実際の使用感と一緒に結果を記録します。

測定記録
時間帯：
ローカル接続：
出口地域：
回線タイプ：
通信プロトコル：
測定ツール：
測定対象：
ダウンロード結果：
アップロード結果：
遅延・ジッター：
パケットロス：
ウェブ・動画の体感：
異常な現象：

この記録に複雑な計算は必要ありません。重要なのは文脈を残すことです。ある回線が昼間と夜間で一貫しているか、測定値のピークと実際の動画再生が一致するか、問題が特定のウェブサイトだけで起きるかを確認できます。文脈のない速度のスクリーンショットは再検証しにくく、キャッシュや一時的な経路変化が原因かどうかも判断できません。

時間帯を分けて測定し、ピーク値で安定性を判断しない

ネットワーク回線には時間帯による特徴があります。平日、夜間、スポーツ配信中は、通信事業者の出口、地域間リンク、コンテンツプラットフォームにかかる負荷がそれぞれ異なります。ネットワークが空いている時間に高いスループットが出ても、普段使う時間帯で安定するとは限りません。一度の混雑で不調だったからといって、長期的な性能を否定することもできません。

実際にネットワークを使う時間帯に繰り返し測定し、最高値だけでなく毎回の結果を残すことをおすすめします。ダウンロードやクラウドストレージでは、継続転送が安定しているかを確認します。ライブ配信、会議、ゲームでは、遅延が急に跳ねるか、連続したパケットロスがあるか、短時間の混雑後に回復するかを重視します。平均値はピークを平らにしますが、そのピークこそ映像の停止、音声の途切れ、操作の遅れを引き起こします。

なぜジッターが下り速度より重要になることがあるのか

遅延はデータの往復にかかる時間、ジッターは測定中に遅延がどの程度変動するかを示します。ダウンロードではキャッシュや同時接続が一部の変動を吸収できますが、リアルタイムアプリではデータがなるべく均一に届く必要があります。十分なスループットがある回線でも、遅延が大きく上下すれば、通話やリモート操作は滑らかになりません。

パケットロスは、データが想定どおりに届かなかったことを意味します。信頼性のある転送では失われたデータを再送するため、ユーザーにはエラーではなく速度低下や応答の遅さとして現れることがあります。UDPやQUICを使うアプリは独自の輻輳制御と回復処理を行いますが、連続したパケットロスは映像、音声、操作性に影響します。そのため「安定しているか」を評価する際は、ピーク速度より先にジッターとパケットロスを確認すべきです。

プロトコルと回線タイプで結果が変わる理由

Shadowsocks、VMess、Trojan、VLESSはいずれもプロキシ通信を運べますが、ハンドシェイク方式、暗号化、トランスポート層の組み合わせ、クライアント実装が異なります。プロトコル名だけで速度を決めることはできません。同じプロトコルでも、サーバー、経路、クライアントが違えば性能は大きく変わります。測定時はまず回線を固定してからプロトコルを切り替えないと、差がプロトコルによるものかネットワーク経路によるものか判断できません。

Hysteria2とTUICは通常、QUICの考え方に基づいて通信を処理するため、ある程度のジッターやパケットロスがある経路では、従来のTCPとは異なる輻輳回復特性を示すことがあります。ただし、どの環境でも速くなるわけではありません。ローカルネットワークがUDPに適していない場合や、中間機器が関連通信を制限している場合は、かえって接続が不安定になることがあります。正確に比較するには、同じ対象、同じ時間帯、同じ端末で測定します。

IEPL専線、中継、直結は回線の構成方法を示すもので、単独で速度測定の結論になるものではありません。IEPLの地域間コア区間は一般的な公衆ネットワーク経路の一部を避けられますが、端末から入口まで、出口から接続先サイトまでは公衆ネットワークを通る場合があります。中継回線は追加の入口によって一部の通信事業者からの接続経路を改善する一方、管理が必要なリンクも増えます。直結構成は単純ですが、地域間の公衆ネットワーク混雑の影響をより直接的に受ける可能性があります。

したがって、回線のラベルは実測結果と合わせて確認してください。ウェブや文書の処理が目的なら、ダウンロードを使い切ることより安定した応答が重要です。大容量ファイルの転送では継続スループットと上り速度を確認します。ライブ配信や会議では、ジッター、パケットロス、混雑時間帯の性能を優先して見ます。

ブラウザ、クライアント、実際の用途でどう相互検証するか

信頼できる測定結果は、複数の証拠を照合して得られます。まずブラウザの公開ツールで基本的なスループットと遅延を確認し、実際のウェブ閲覧、動画、ファイル転送、リモートアプリで体感を検証します。公開測定が高いのに対象サイトだけ遅い場合は、出口から接続先までの経路、対象プラットフォームの速度制限、ブラウザ拡張機能、名前解決に原因があり、プロキシ入口の帯域が原因ではない可能性があります。

クライアント内蔵の速度測定は初期選別に適していますが、クライアントによってTCP接続時間、プロキシのハンドシェイク時間、簡易リクエスト時間などを遅延値として使うため、測定の定義は統一されていません。WindowsとmacOSのデスクトップクライアントでは、システムプロキシ、仮想ネットワークアダプター、プロセスごとの通信量を確認しやすい傾向があります。AndroidとiOSでは、システムのネットワークインターフェースやバックグラウンド制御の影響を受け、アプリを切り替えた後の記録方法も異なります。モバイルネットワークは場所や電波状態でも変わるため、スマートフォンの結果をデスクトップの有線ネットワークと直接比較しないでください。

サブスクリプションリンクをクライアントに取り込んだ後は、ノード名やグループルールも測定に影響します。自動選択グループがバックグラウンドでノードを切り替えたり、負荷分散グループがリクエストごとに異なる出口を使ったりする場合があります。再現性を高めるには、明確な一つのノードを一時的に選び、測定中に自動切り替えが起きていないことを確認します。終了後に普段使う自動選択やフェイルオーバーのルールへ戻します。

分割ルールによって測定通信が意図しない経路を通ることがある

ルールによる分割は通常、ドメイン、IP、アプリのプロセス、地域データベースに基づいて直結とプロキシを決めます。公開測定サイトが直結と判定されれば、表示されるのはローカルネットワークの速度です。測定ページはプロキシを通っていても、測定サーバーへの接続だけが直結なら、結果は同じく正確ではありません。グローバルモードでプロキシの基準値を作り、その後ルールモードへ戻して、普段の分割が想定どおりかを確認できます。

確認時は、まず出口IPを確認してから測定ツールを開きます。測定後に出口が同じかを再確認してください。クライアントが接続ログに対応していれば、測定ドメインがどのルールに一致したかを確認できます。ただし、ログにある一つのドメインだけで全通信を判断しないでください。測定ページが複数のAPIや測定サーバーを呼び出す場合があるためです。

DNSリークと速度異常は分けて判断する

DNSリークとは、ドメインの名前解決リクエストが想定した解決経路を通っていない状態です。主にプライバシー、地域判定、アクセスの一貫性に関わる問題で、ダウンロード速度と同じ意味ではなく、速度測定だけで発見できるものでもありません。DNS経路の異常によって名前解決が遅れたり、適切でない配信ノードが返されたりすると、ウェブの初回表示が遅くなることがありますが、接続確立後のファイル転送速度は正常な場合もあります。

測定では「名前解決にかかる時間」と「接続後の転送性能」を分けて考えます。ウェブの初回表示だけ遅く、更新後に明らかに改善するなら、DNS、キャッシュ、配信ノードの選択を確認します。接続確立後も継続して遅いなら、回線のスループット、パケットロス、接続先サーバーを調べます。出口IPの確認、DNS検査、速度測定はそれぞれ異なる問題に答えるもので、相互に代用できません。

• ✅ 測定前に出口地域を確認し、直結経路を誤って測らないようにする。
• ✅ 分割ルールにより測定ドメインと測定接続が同じ経路を通っているか確認する。
• ✅ ウェブの初回表示が遅い場合と継続ダウンロードが遅い場合を分けて記録する。
• ✅ 普段使う複数の時間帯で再測定し、最高値ではなく結果全体を残す。
• ✅ 動画、ファイル転送、リモート操作で公開測定の結果を検証する。
• ❌ 一度の低遅延だけで、その回線がライブ配信やゲームに必ず適すると判断しない。
• ❌ DNS検査の結果を、そのまま帯域の速さとして解釈しない。

記録から安定した回線を選ぶ方法

結果を整理するときは、すべての用途を一つの総合点にまとめず、目的に応じて指標の優先順位を決めます。日常の閲覧では接続確立の速さとページ素材の安定した読み込みを確認します。動画やライブ配信では継続転送、バッファ、混雑時間帯の変動を重視します。ファイル同期では下りと上りを両方見ます。会議、ゲーム、リモートデスクトップでは遅延、ジッター、パケットロスを優先します。

次に、結果を再現できるかを確認します。ある回線が一時的に非常に高い下り速度を出しても、普段の時間帯に頻繁に変動するなら、最高値だけで選ぶべきではありません。別の回線はピーク値が普通でも、複数回の結果が近く、実際の用途で中断が少ないなら、日常用に適していることが多いでしょう。ここでいう「安定」とは変化しないことではなく、変動幅を予測でき、異常後に回復できることです。

最後に、経路が用途に合っているかを確認します。特定地域のサービスにアクセスする場合は、通常、プラットフォームに近い出口から測定し、現在の通信事業者で直結、中継、IEPLの各経路を比較します。距離が近いからといってルーティングが良いとは限りませんが、初期選別の条件にはなります。近いノードの性能がかえって低い場合は、地図上の距離だけで選ばず、経路、プロトコル、混雑時間帯の結果を合わせて調べます。