VPN速度測定の方法｜ツール・時間帯・指標を実測比較し、広告の数値を見極める

VPNの速度を正しく測るには？まず自宅のネットワーク、接続先ノード、測定先を固定し、同じ時間帯に遅延・パケットロス・持続的な通信速度を比較します。ツールに表示されるピーク値は、その時点の測定経路での結果にすぎず、動画や会議、ファイル転送の使い心地をそのまま示すものではありません。

この記事では、誰でも再現できる実測方法を比較します。実際には確認していない回線の数値を掲載することはありません。自分に合う回線を見極めるには、最も大きな数値を探すのではなく、測定条件をそろえ、結果を実際の用途と照らし合わせることが大切です。

まず遅延・ジッター・通信速度を区別する

遅延とは、データが相手先まで往復するのにかかる時間です。Webページの操作やリモート操作、リアルタイム通話に影響します。クライアント一覧の「遅延」は、接続先の入口への応答時間の場合もあれば、プロキシ経由で指定したURLにアクセスするまでの時間の場合もあります。測定対象が異なる結果を単純に比較することはできません。

ジッターは、時間の経過に伴う遅延の揺れを示します。平均遅延が同程度でも、一方の回線で急な遅延増加が頻発すれば、通話が途切れることがあります。パケットロスは、測定用データが想定どおりに返ってこなかった状態です。ただし、測定方法も考慮する必要があります。測定への応答が制限されていても、実際の通信データが同じ割合で失われているとは限りません。

速度測定サイトの「通信速度」は、通常、アプリケーション層でのスループット、つまり測定中に実際に転送できたデータ量を指します。自宅の回線、Wi-Fiの電波状況、国際経路、プロキシの処理能力、接続先サーバーなどに左右されるため、契約したプランで専有できる回線容量を示すものではありません。

速度測定ツールの選び方：複数の方法で確かめ、結果を混同しない

速度測定サイト：スループットの比較に便利

ブラウザーでの速度測定は、ダウンロード、アップロード、負荷時の遅延を概観するのに適しています。SpeedtestやFastなどのツールは、測定サーバーや同時接続数、集計方法が異なるため、結果に差が出るのは自然です。ノードを比べる際は同じツールを使い、できるだけ同じ測定サーバーを手動で選びましょう。自動選択では、測定ごとに異なる経路が使われる場合があります。

複数接続での測定は、利用可能な容量を使い切りやすく、全体的なスループットの確認に向いています。単一接続での転送は、一部のダウンロード用途に近い一方、往復遅延や単一接続の制限を受けやすくなります。測定モードを記録し、複数接続のピーク値と単一接続のダウンロード速度を並べて優劣を判断しないようにしましょう。

コマンドラインでの測定：経路の特定に便利だが、実際の通信全体を測るものではない

ping は通常ICMPを使用します。一方、多くのシステムプロキシが中継するのはアプリケーションからのプロキシ通信だけなので、ターミナルからの測定はプロキシを経由しない場合があります。仮想ネットワークアダプター（TUN）モードを有効にしていても、こうした通信を中継するかどうかはクライアントとOSの実装によって異なります。数値を解釈する前に、通信経路を確認しましょう。

経路追跡ツールを使うと、一部の中継ノードの状態を確認できます。ただし、中継ルーターが応答しない、または応答が遅いからといって、通信を正常に転送していないとは限りません。特定のホップがタイムアウトしただけで障害と断定せず、最終的な接続先への到達性、継続的な測定、実際のアプリの動作を合わせて判断しましょう。

実際のアプリ：測定結果が用途に役立つか確認する

動画アプリでは、読み込みが続いているか、画質が頻繁に下がるかを確認できます。会議アプリでは音声の途切れや再接続、ファイル転送ではダウンロードやアップロードの持続的な速度を記録します。実際の用途に近い一方、キャッシュ、サーバー側の速度制限、アカウントの状態、コンテンツ配信サーバーなどにも左右されるため、回線全体の容量を証明するものではありません。

クライアントに「接続済み」と表示されていても、速度測定の通信が選択したノードを経由しているとは限りません。ルールによる振り分け、ブラウザーのプロキシ設定、アプリ独自のネットワーク処理によって、通信経路が変わることがあります。

測定条件を固定する：まず自宅のネットワークの影響を除く

測定前に、クラウドストレージの同期、システム更新、ゲームのダウンロードなど、継続中のデータ転送を一時停止します。可能であれば有線接続を使いましょう。Wi-Fiを使う場合は、端末とアクセスポイントの位置を変えず、電波状況や周波数帯が変化していないか確認します。測定中に接続ネットワークを切り替えると、それまでの比較条件がそろわなくなります。

まずプロキシ未接続時のネットワーク状態を記録し、次に指定したノードへ接続して測定を繰り返します。未接続時の結果は、端末やWi-Fi、接続回線の問題を見分けるための基準です。直結時とプロキシ接続時に異なる測定先へアクセスしている場合、結果の差を引いて「回線で失われた速度」を算出することはできません。

クライアントのルールモードも確認しましょう。接続ログやルールの適用記録で、測定先のドメインがどの出力経路を使ったか確認します。特定のドメインに一時的な出力先を指定できるクライアントなら、測定条件をそろえるのに役立ちます。測定のために保護機能を安易に無効化したり、普段使っている振り分けルールを恒久的に変更したりせず、終了後は元の設定に戻してください。

• ✅ 端末、接続ネットワーク、クライアントのバージョン、ノード、測定サーバーを固定する。
• ✅ ルールモードを記録し、測定通信が実際に使った出力経路を確認する。
• ✅ バックグラウンドの転送を一時停止し、端末の発熱や高負荷も確認する。
• ✅ 最高値だけでなく、失敗や停止、再接続の記録も残す。
• ❌ 複数の測定ツールを同時に起動して回線を取り合ったり、測定中にノードを切り替えたりしない。

測定する時間帯：実際に使う時間をカバーする

主に夜間に使うなら、夜間の結果を重視しましょう。仕事中のリモート作業が中心なら、その時間帯も測定対象にします。利用者が少ない時間の最高値だけでは、混雑時に使えるかどうかは分かりません。日によっても変動するため、繰り返し確認し、たまたま起きた変化を長期的な傾向として扱わないようにしましょう。

ノードを比較するときは測定順を入れ替え、毎回同じノードから測り始めないようにします。連続した速度測定は回線や端末のリソースを消費するため、前の転送が終わったらネットワークの動作が落ち着いてから次を始めましょう。異常があった場合は元の結果を残して再測定し、予想と違う結果をそのまま削除しないでください。

1. 会議の安定性、Webページの操作、ファイルのダウンロードなど、測定の目的を書く。
2. 日付、現地時間、端末、ネットワーク、クライアント、ルールモードを記録する。
3. ノードと測定サーバーを固定し、まずアイドル時の応答時間を確認してからデータを転送する。
4. 転送中の遅延の変化を確認し、終了後に実際のアプリで作業する。
5. 普段使う時間帯に同じ手順を繰り返し、典型的な結果、変動、失敗の有無を比べる。

ダウンロード中に遅延が大きく上がる場合、自宅のルーターや接続回線、経路上のキューイングによる負荷時の遅延が考えられます。まず他の転送を一時停止し、ルーターのキュー管理設定を確認しましょう。この現象だけで、接続先ノードの容量不足と判断しないでください。

測定結果が食い違うときは、経路を順に確認する

速度測定は速いのに、Webページの表示が遅い

まず、ドメイン名の名前解決、接続の確立、ページ内リソースの読み込みのどこで遅れているかを切り分けます。速度測定サービスとWebサイトでは、コンテンツ配信経路が異なる場合があり、ページが別のドメインに依存していることもあります。該当する通信が想定したルールに一致しているか確認し、他の正常なWebサイトとも比較して、単一サイトの問題を回線全体の問題と混同しないようにしましょう。

DNSリークは、名前解決の通信が想定した経路から外れている状態を指すプライバシー・設定上の問題です。速度だけでは判断できません。クライアントのDNS設定と名前解決テストで、実際の問い合わせ先を確認しましょう。DNSの経路とプロキシの経路が異なる場合も、想定した設計を踏まえて解釈する必要があり、違いがあるだけで問題と断定することはできません。

クライアントの遅延は低いのに、実際のダウンロードが遅い

接続先の入口までの距離が近くても、その先の経路が短いとは限らず、出口からダウンロードサーバーまでの接続が良好とも限りません。クライアントの遅延測定が何を測っているか確認し、同じダウンロード先を使って再測定します。端末の処理能力、接続先の速度制限、自宅のネットワークも調べましょう。ノード名だけから原因を推測することはできません。

プロトコルを変えると測定結果が異なる

Shadowsocks、VMess、Trojan、VLESSの実際の性能は、転送設定や実装、通信経路によって異なり、名称だけで固定の速度ランキングを作ることはできません。QUICベースのHysteria2やTUICも、UDPで通信できるかどうかや具体的な設定に左右されます。ネットワークの制限、輻輳制御、クライアントの実装も結果に影響します。サービスが該当する設定を提供している場合に限って比較し、プロトコル名を性能の保証と見なさないでください。

IEPL、中継、直結も、それぞれ異なる要素を表します。専用線は通常、特定区間の伝送方式を指し、中継は転送経路に中継地点が加わること、直結は該当経路がその中継を経由しないことを意味します。いずれも表記だけでエンドツーエンドの速度が保証されるわけではありません。自宅の接続から入口、ネットワーク間の伝送、出口、接続先のWebサイトまで、経路全体を測定する必要があります。

広告の数値を見極める：測定条件を確認してから結論を出す

速度測定のスクリーンショットを見たら、まず測定日時、接続事業者、出口の地域、測定サーバー、接続モード、使用ツールを確認しましょう。こうした条件が分からなければ、その数値はある時点で測定されたことを示すだけで、自分のネットワークでも再現できるとは限りません。ノード数や対応地域は選択肢の目安であり、個人の通信速度にそのまま置き換えることはできません。

単位にも注意が必要です。ビットとバイトは別の単位であり、速度測定ツールとダウンロードソフトで表示が異なる場合があります。比較前に単位をそろえ、転送開始直後のピークではなく、継続して得られる速度を確認しましょう。短時間の測定では安定する前に終わることがあり、長時間のダウンロードでは接続先の速度制限を受ける場合もあります。どちらも測定範囲を明記してください。

クライアントの違いも記録しましょう。システムプロキシ、仮想ネットワークアダプター（TUN）モード、モバイル端末のシステムネットワーク拡張機能では、通信を中継する範囲が異なる場合があります。同じサブスクリプションを読み込んでも、すべてのアプリが同じ経路を使うとは限りません。更新後にノードやルールが変わった場合は、出力先を再確認しましょう。スクリーンショットを共有する前に、サブスクリプションURL、アカウント情報、その他のアクセス認証情報を隠してください。

測定前にユーザーパネルからクライアントを入手し、使い方ガイドで設定を確認してから、ノード一覧で地域情報を確認できます。測定では実際の通信量を消費し、継続的な転送では特に多くなります。何を確認したいのかを先に決め、比較できる記録を残さないまま測定を繰り返すことは避けましょう。