VPN速度テストの方法：自分で実測する速度の完全ガイド

VPN速度テストは、測定サイトを開いてダウンロード結果を記録すれば終わり、というものではありません。測定値は、利用中の回線、無線環境、測定サーバー、接続ノード、海外までの経路、プロトコルのオーバーヘッド、端末性能、その時点のネットワーク負荷などに左右されます。どれか一つの条件が変わるだけで、2回の結果を単純に比較できなくなることがあります。

信頼できる方法は、まずサービス未接続時のローカル基準値を測り、端末、ネットワーク、対象サーバー、測定方法を固定したうえで、比較したい項目だけを変えることです。回線を比較するならプロトコルを固定し、プロトコルを比較するなら回線を固定します。見栄えのよいスクリーンショットではなく、再確認できる記録を残すことが重要です。

まず今回の速度テストで何を確認するか決める

重視すべき指標は利用目的によって異なります。ウェブページの表示が遅い場合は、遅延、DNS名前解決、パケットロスを優先して確認します。大容量ファイルのダウンロードが遅い場合は、継続的なスループットが重要です。動画の画質が頻繁に下がる場合は、スループットの変動と回線の安定性を合わせて見ます。リモート端末が途切れる場合は、平均ダウンロード速度よりジッターと短時間のパケットロスを重視します。

測定前に確認したい問題を書き出しましょう。たとえば「同じ地域の中継回線と直結回線では、現在のネットワークでどちらが安定するか」や、「デスクトップで VLESS と Hysteria2 を使った場合、継続転送の性能に違いはあるか」といった内容です。問いを具体化するほど、管理すべき条件も明確になります。

速度テストの前にローカル環境の干渉要因を取り除く

サービス未接続時点ですでにローカルネットワークが大きく変動しているなら、その後の結果で回線を評価することはできません。システム更新、クラウド同期、動画再生など、帯域を使う処理をいったん停止してください。家庭内の別端末が継続的に通信している場合も、ネットワークが空くまで待ってから測定します。

無線接続は、見えにくい変動要因になりやすい環境です。端末とアクセスポイントの距離、壁、周波数帯の混雑、省電力設定などが結果に影響します。可能であれば同じ場所で測定するか、安定した有線接続を使ってください。部屋や接続方法が異なる結果を、そのまま比較してはいけません。

• ✅ 同じ端末、同じ接続方法、同じ測定場所に固定する。
• ✅ バックグラウンドのダウンロード、クラウド同期、システム更新、再生中のメディアを停止する。
• ✅ プロキシまたはトンネルを切断し、ローカルネットワークの基準値を記録する。
• ✅ 測定対象を固定し、ツールによる測定サーバーの自動切り替えを避ける。
• ❌ 無線信号の変化による速度低下を、すぐにサービス側のノードが原因だと決めつけない。
• ❌ プロトコル、回線、クライアント、測定サーバーを同時に変更しない。

端末自体の制限にも注意が必要です。古いプロセッサでは、暗号化、復号、ユーザー空間での転送処理が先に負荷の上限へ達することがあります。ブラウザー拡張機能、システムのセキュリティソフト、仮想ネットワークアダプターの競合も経路を変える可能性があります。測定中はプロセッサ使用率とクライアントログを確認しましょう。端末負荷が長時間高止まりし、ネットワークのスループットが伸びない場合、ボトルネックは回線以外にあるかもしれません。

再現可能な完全な速度テスト手順を作る

まず未接続状態でローカルの基準値を測り、ダウンロード、アップロード、遅延、ジッター、パケットロスを記録します。次に対象回線へ接続し、出口地域が変わったことを確認してから、同じ測定サーバーで再測定します。ブラウザーの測定は手軽ですが、ブラウザーやサーバーの振り分けの影響を受けやすい方法です。コマンドラインツールなら生の出力を残せます。管理可能な遠隔ホストがある場合は、スループット測定ツールを使うことで、公開測定サーバーの負荷変動による誤差を抑えられます。

1. 環境を記録する。端末、OS、接続方法、利用中のネットワーク環境、クライアント、プロトコル、回線名を書き留めます。
2. ローカルの基準値を測る。トンネルを切断し、バックグラウンド通信がないことを確認して、基本的なネットワーク状態を記録します。
3. 対象を固定する。用途に合った対象地域を選び、測定サーバーを変更しないようにします。
4. 接続後に確認する。クライアントの状態と出口 IP を確認し、接続が有効になっていない状態を測定結果として扱わないようにします。
5. 複数回測定する。最高値だけを残してはいけません。各回のデータと、再生停止、再接続、異常な変動が起きた時刻を記録します。
6. 時間帯を変えて再確認する。普段の利用時間帯とネットワークが混雑する時間帯でそれぞれ観察し、同じ傾向が再現するか確認します。
7. 一度に一つの条件だけ変える。回線を比較するときはプロトコルを変えず、プロトコルを比較するときはノードを変えず、クライアントを比較するときは他の条件をそろえます。

公開測定サーバーは、距離の近いノードを自動選択することがあります。海外回線へ接続した後、ツールが出口の位置に応じてサーバーを再選択する場合もあり、測定対象そのものが変わります。その結果、速くなったり遅くなったりして見えても、回線自体が同じ割合で変化した証拠にはなりません。測定サーバーを手動で固定し、記録にサーバーの地域を残すことが基本的な対策です。

遅延・パケットロス・スループットの読み方

遅延は最低値だけでなく、分布を見て判断します。回線の距離が遠いほど、通常は伝送時間が長くなります。迂回経路、中継地点の増加、回線上の待ち行列が発生すれば、遅延はさらに上がります。海外回線では、たまたま出た低い値より、往復時間が安定していて変動が小さいことのほうが参考になります。

パケットロスが起きると再送が発生します。TCP はネットワーク状態に応じて送信ペースを調整するため、ローカル回線に余裕があっても、継続的なスループットが大きく低下することがあります。UDP 系プロトコルは TCP と同じ動作をすべて行うわけではありませんが、アプリケーション層では信頼性、輻輳制御、データ復旧への対応が必要です。パケットロスを確認したら、ローカルの無線区間、通信事業者の入口、海外までの経路、対象サーバー付近のどこで発生しているかを切り分けます。

スループットはピーク値と持続値を分けて見ます。測定開始直後は、キャッシュ、接続のウォームアップ、並列処理の影響で、一時的に高い数値が出ることがあります。ダウンロードや動画再生で実際に感じる速度は、一定時間転送したときの安定した水準に近いものです。アップロードも無視できません。ビデオ会議、ファイルのバックアップ、リモート協業はいずれも上り経路に依存します。

同じ回線で「遅延は許容範囲だが、スループットが安定しない」という状態は同時に起こり得ます。矛盾ではありません。往復確認で使うデータ量は小さく、継続的な転送テストの代わりにはならないためです。

VPNプロトコルで結果が変わる理由

Shadowsocks、VMess、Trojan、VLESS はいずれもプロキシ通信を運べますが、実際の性能はトランスポート層、暗号化方式、カプセル化の組み合わせ、クライアントの実装、サーバー側の設定にも左右されます。同じ名前のプロトコルでも、異なるネットワーク経路では結果が大きく変わることがあります。プロトコル名だけで速さを判断するのは適切ではありません。

VMess と VLESS は、さまざまなトランスポートとの組み合わせで使われます。追加のカプセル化は異なる導入環境に対応しやすくする一方、パケット処理やハンドシェイクの工程を増やします。Trojan は通常 TLS を利用して通信するため、ハンドシェイク、証明書設定、経路品質、クライアント実装の影響を受けます。Shadowsocks は比較的シンプルな構成ですが、最終的なスループットは暗号化処理、輻輳、ノードまでの経路に制約されます。

Hysteria2 と TUIC は、UDP と QUIC の考え方を基盤に構成され、それぞれの輻輳制御や多重化の仕組みを利用できます。変動やパケットロスのあるネットワークでは、従来の TCP 経路とは異なる挙動を示すことがありますが、どの環境でも速くなるわけではありません。ローカルネットワークで UDP が制限されている、無線のパケットロスが深刻、または端末の処理能力が不足している場合、結果が伸びないこともあります。

プロトコルを比較するときは、同じ端末、同じ入口と出口地域、同じ測定対象を使い、クライアントのルーティングモードもそろえます。そうしなければ、測定しているのはプロトコルではなく、回線やルーティングの違いかもしれません。

IEPL専用線・中継・直結を比較する方法

直結は通常、クライアントが海外ノードへ直接接続する方式です。経路は比較的シンプルですが、利用中の通信事業者から対象地域までの公衆ネットワーク経路の品質に左右されます。迂回経路、事業者間接続の混雑、国際出口の変化などが、夜間の変動として現れることがあります。

中継回線では、まず近い入口へ接続し、その後、中継ネットワークを通じて海外の出口へ通信を送ります。管理しにくい長距離経路の改善を目的としますが、実際の効果は入口の品質、中継区間、出口の負荷に依存します。入口が近くても、経路全体が短いとは限りません。測定では端末から対象までの結果を確認する必要があります。

IEPL 専用線は通常、専用の伝送特性を持つ海外接続回線を指します。公衆インターネットを全面的に通る直結経路とは異なりますが、ユーザーから入口まで、また出口から対象サイトまでの両端は通常のネットワークを通る可能性があります。「専用線」だからといって、すべてのネットワーク要因がなくなるわけではなく、実測の代わりにもなりません。

これらの回線を比較する際は、測定サーバーを同じ地域に置きます。まず混雑時間帯のパケットロスとジッターを確認し、その後で継続的なスループットを見ます。中継や専用線のピーク値が目立たなくても、複数回の結果が集中し、再送が少ないなら、長時間の接続に向いている可能性があります。直結経路の品質が十分なら、追加の中継が必ずしもメリットになるとは限りません。

DNS漏洩とルーティングルールは測定に影響するか

DNS漏洩とは、トンネル接続後もドメイン名の解決要求が、想定していないローカルの名前解決経路へ送られる状態です。主に経路とプライバシーの確認に関する問題であり、帯域幅の低下と単純に同一視すべきではありません。ただし、DNSの解決場所はコンテンツ配信ネットワークの選択に影響します。遠い配信ノードを指す結果になると、ウェブや動画の実際のダウンロード経路が長くなり、回線速度が落ちたように見えることがあります。

確認時は、出口 IP、DNS リゾルバーが属するネットワーク、クライアントの DNS 設定を同時に確認します。ブラウザーで暗号化 DNS を有効にしていると、システム設定とは別の経路で名前解決されることがあります。OS のキャッシュに接続前の結果が残っている場合もあります。設定を変更した後は、古い接続を終了してから再測定し、新しい解決経路が有効になったことを確認してください。

ルーティングルールは、測定通信がトンネルに入るかどうかを直接決めます。ルールモードでは、測定サイトのページはプロキシ経由でも、測定データの接続は直結と判定されることがあります。逆のケースもあります。その場合、得られた数値は回線全体を表しません。測定前にクライアントの接続ログを確認し、測定サーバーへのリクエストが想定したルールに一致していることを確かめます。

• ✅ 出口 IP と選択した回線地域が一致しているか確認する。
• ✅ 測定データの接続が実際にプロキシ経由か直結か確認する。
• ✅ ブラウザーの暗号化 DNS とシステム DNS が異なる経路を使っていないか確認する。
• ✅ ルーティングルールを変更したら、接続を再確立してから測定する。
• ❌ ウェブページに「接続済み」と表示されただけで、すべての通信がトンネルに入ったと判断しない。

各プラットフォームのクライアントによる測定差

Windows と macOS のクライアントでは、通常、システムプロキシ、仮想ネットワークアダプター、TUN モードを利用できます。モードによって対象となるアプリの範囲が異なり、データが通るネットワークスタックも変わります。測定記録にはモードを明記し、ブラウザーのプロキシ結果と全体トンネルの結果を混同しないようにしてください。

Android と iOS は、システムが提供する VPN インターフェースを通じて通信を引き受けます。省電力設定、バックグラウンド制限、無線接続とモバイル接続の切り替えによって、トンネルが再構築されることがあります。測定中はアプリを前面に表示し、接続方法が変わらないようにしてください。アプリごとのプロキシ、DNS、IPv6 の扱いもクライアントによって異なる場合があります。

Linux では、GUI クライアントを使うことも、コアプログラムを直接実行してルーティングテーブルを設定することもできます。この場合は、デフォルトルート、ポリシールーティング、DNS 設定を特に確認してください。コマンドライン上でプロセスが動作していても、対象の通信が想定どおりトンネルに入っているとは限りません。

サブスクリプションリンクをクライアントへ読み込むと、ノードと接続パラメーターの集合が取得されます。クライアントには、遅延測定、自動選択、負荷分散、ルールセットについて独自の実装がある場合があります。再現性を保つため、測定時はノードを手動で固定し、回線を自動切り替えする機能を無効にして、クライアントのバージョンと接続モードを記録してください。

速度テストの異常はどの順番で確認するか

結果に異常が見つかっても、すぐにすべての設定を次々と変更しないでください。ローカルから遠隔側へ順番に確認すると、問題の境界を特定しやすくなります。

1. ローカルの基準値を再測定する。未接続状態でも遅い場合は、回線、無線環境、端末負荷を先に確認します。
2. 接続が有効か確認する。出口 IP、クライアントログ、ルーティングルールの一致状況を確認します。
3. 同じ地域のノードへ切り替える。特定のノードだけに異常があるなら、ノードまたは上流経路に問題が集中している可能性があります。
4. ノードを固定してプロトコルを変更する。UDP の利用可否、ハンドシェイクの失敗、再送、端末負荷に変化があるか確認します。
5. 測定対象を変更する。公開測定サーバーの混雑や、コンテンツ配信ノードの選択異常を切り分けます。
6. 時間帯を変えて再確認する。問題が継続しているのか、ネットワークが混雑する時間帯だけ発生するのかを確認します。

ウェブ閲覧は正常なのに測定ツールだけ失敗する場合は、測定対象、並列接続、ルーティングルールに問題がある可能性があります。遅延測定は正常でもファイル転送が遅い場合は、パケットロス、再送、プロトコルの輻輳制御、対象サーバーの速度制限を確認してください。同じ端末上のすべてのノードで異常が出て、別の端末では正常なら、クライアント設定とシステムのネットワークスタックを優先して確認します。

信頼できる速度テストの結論を導く方法

記録を整理するときは、各回の測定を1行にまとめると便利です。環境、回線、プロトコル、測定サーバー、遅延、ジッター、パケットロス、ダウンロード、アップロード、メモを記録します。正常に測定できた低い結果を削除したり、最もよい1回だけを切り取ったりしないでください。価値があるのは、複数回および異なる時間帯で結果が一貫しているかどうかです。

合成ベンチマークと実際の作業も分けて考える必要があります。公開測定ツールは横並びの比較に便利ですが、日常の利用感は対象サイト、コンテンツ配信ネットワーク、アプリケーションプロトコルにも左右されます。基本測定が終わったら、普段利用するウェブサイト、動画、ファイル同期、リモート作業でも確認してください。合成テストは速いのに実際の作業が遅い場合は、より高いピーク値を追うのではなく、対象サービスまでの経路とルーティングを確認します。

最終的な結論には、環境の範囲を添えましょう。たとえば「現在の家庭内ネットワーク、端末、時間帯では、この中継回線は複数回測定しても変動が小さい」といった書き方です。「特定のプロトコルが常に最速」とするより正確で、ネットワーク環境が変わったときにも再検証しやすくなります。