VPN速度測定の方法｜自分で速度を測る完全ガイド

VPNの速度測定で重要なのは、最高値を出すことではなく、再現可能な比較条件を作ることです。まず通常のネットワークを測定し、指定した回線に接続します。端末、接続方法、測定ツール、対象サーバーを固定し、遅延、ジッター、パケットロス、ダウンロード、アップロードを比較します。条件をそろえてこそ、回線の実力を判断できます。

ブラウザーで一度測った速度は、測定サーバーの負荷、無線干渉、バックグラウンドのダウンロード、通信事業者の経路変化に左右されやすいものです。スクリーンショットのピーク値はその時点の接続を示すだけで、普段の体感を直接表すものではありません。測定条件を保存し、通常の利用時間帯とネットワークが混雑する時間帯に再測定して、異常値と通常値を分けて記録しましょう。

VPN速度測定で何を確認するかを先に決める

測定前に確認したいことを書き出します。動画の途切れ、ウェブページの初回表示の遅さ、ファイルダウンロードの不安定さ、リモート端末の断続的な切断では、関係する指標が異なります。ダウンロード帯域だけを見ていると、より直接的な原因を見落とすことがあります。

遅延とは、データが往復するのにかかる時間です。地理的な距離、通信事業者間の接続、迂回経路によって変化します。遠い地域に接続すれば遅延が増えるのは自然なことです。同じ地域の回線間の差や、同じ回線が時間帯によって大きく変動するかを確認しましょう。

ジッターは、連続するデータパケットの遅延が安定しているかを示します。平均遅延が近い2つの回線なら、ジッターが小さいほうが音声通話、会議、リアルタイム操作に向いていることが多いです。パケットロスが起きると再送が発生し、映像の品質低下、ダウンロード速度の急落、端末入力の停止などにつながります。ブラウザーの速度測定では情報が十分に表示されない場合があるため、システムのネットワークツールやクライアントのログも確認してください。

再測定できる基準値を作る

基準値とは、同じ端末と同じネットワークで、VPNに接続していない状態で測定した結果です。現在の接続環境で得られる上限と変動幅を示します。基準値自体が不安定なら、どの回線に接続しても結果は変動します。

有線接続を優先してください。無線しか使えない場合は、端末の位置、接続帯域、ルーターを固定し、1回目はルーターの近く、次は壁を隔てた場所というような差が出ないようにします。測定中はクラウド同期、システム更新、ゲームの更新、ほかの端末での大容量通信を停止します。ブラウザーで再生中のメディアも止めてください。

• ✅ 同じ端末、同じ接続方式、同じ測定場所に固定する。
• ✅ ダウンロードやアップロード帯域を継続的に使うバックグラウンド処理を停止する。
• ✅ 未接続時の遅延、ジッター、パケットロス、ダウンロード、アップロードを記録する。
• ✅ 測定ツールと対象サーバーを固定し、比較の途中で変更しない。
• ✅ 回線名、プロトコル、測定時間帯、分割ルーティングモードを記録する。
• ❌ 無線と有線の結果を同じグループに入れて直接比較しない。
• ❌ 一度のピーク値で一連の測定を代用せず、見栄えのよい結果だけを残さない。

測定サーバーも固定します。自動選択では、その時点で応答が速いと判定されたサーバーが選ばれます。しかしVPN接続後は選択先が変わり、前後で異なる経路を測ることがあります。より確実なのは同じ対象を手動で選び、普段アクセスする地域に近い対象も追加して照合する方法です。

公開速度測定ツールに単一接続と複数接続のモードがある場合は、モードも記録します。複数接続では利用可能な帯域を早く使い切れますが、単一ファイルのダウンロード、1本の動画ストリーム、リモートセッションの実態を必ずしも反映しません。単一接続の結果は、セッション単位の混雑、速度制限、パケットロスを見つけやすくなります。両者が答える問いは異なるため、1つの指標として混同しないでください。

固定した手順で1回の実測を行う

完全な1回の測定には、元のネットワーク、対象回線、確認用回線を含めます。端末の温度、バックグラウンド処理、時間帯によるネットワーク変化を切り分けられるよう、順序をそろえます。特定ブランドのツールに依存せず、ブラウザーの測定ページ、システムのネットワークコマンド、クライアントのステータス画面を記録に利用できます。

1. 測定環境を整える。バックグラウンド通信を停止し、端末がネットワークを自動で切り替えていないことを確認します。現在の接続方式とネットワークを記録します。
2. 元回線の基準値を測る。VPNを切断したまま、固定した対象で遅延、ジッター、パケットロス、ダウンロード、アップロードを記録します。
3. 指定回線に接続する。地域、回線名、プロトコル、クライアントのグローバルモードまたは分割ルーティングモードを記録します。接続状態が安定してから測定を始めます。
4. 同じ項目を繰り返す。測定対象とモードをそろえ、サーバーを変えて経路が変わらないようにします。
5. 実際の用途で確認する。普段使うウェブサイトを開き、いつものコンテンツを再生するか、繰り返し使えるテストファイルを転送して、速度測定の数値と一致するか確認します。
6. 切断後に基準値を再測定する。元回線も遅くなっていた場合、その変化は特定の回線ではなく、ローカルネットワークや通信事業者の時間帯による可能性があります。
7. 候補回線を変えて再測定する。1回につき変更する変数は1つだけにします。回線を比較するとき、プロトコル、クライアント、接続ネットワークを同時に変更しないでください。

システムの ping では往復遅延、ジッターの傾向、パケットロスを確認できます。ただし、対象によってはこの種の探査を制限または無視するため、「応答がない」ことはウェブサイトにアクセスできないことと同じではありません。traceroute や tracert では経路の一部を確認できますが、通信事業者が中間ホップを隠す場合があり、ノード名だけで回線種別を断定することもできません。

自分で管理するリモートサーバーがある場合は、iperf のようなツールでエンドツーエンドのスループットを測定できます。自分の経路の調査には適していますが、結果をすべてのウェブサイトにそのまま当てはめるべきではありません。実際のアクセスでは、対象サイトのネットワーク、コンテンツ配信ノード、アプリケーション層の制限も関係します。

記録では最終的な数値だけを書き写さないでください。ツール名、対象、測定モード、接続プロトコル、測定時の状況を残します。スクリーンショットは元記録として保存しつつ、後から表に整理すると、同じ経路で混雑時間帯に似た変動が繰り返されているか確認しやすくなります。

通常の時間帯と混雑時間帯をカバーする理由

国際回線は固定された実験室環境ではありません。利用する通信事業者、接続する都市、ネットワーク間の接続、出口の方向、対象サイトは時間帯によって変化します。日中に快適でも夜間に同じ安定性が続くとは限らず、混雑時の一度の異常だけで回線が長期的に使えないとも判断できません。

実際にサービスを使う時間帯に再測定するのが適切です。主に夜間にコンテンツを見るなら夜間を中心に確認し、平日のリモート会議が目的なら会議が行われる時間帯を基準にします。目的は共通の「標準時刻」を探すことではなく、自分の利用時間帯を回線がカバーできるか確認することです。

再測定でも同じ対象を使います。複数の回線が同時に遅くなった場合は、まずローカルの基準値と測定対象を確認します。特定の回線だけで異常が繰り返されるなら、ノード負荷、経路の混雑、プロトコルの適合性を検討します。ダウンロードが安定しているのにウェブページの初回表示が遅い場合は、帯域不足と決めつけず、DNS、分割ルーティング、対象サイトの応答を確認してください。

回線種別が測定結果に与える影響

「直結」「中継」「IEPL専線」は異なる経路構成を表しますが、名称だけで実測を代用することはできません。直結は通常、クライアントがサービス側の国内中継ノードを経由せず、海外の入口に直接接続する方式です。経路は比較的単純ですが、性能はローカルの通信事業者と海外入口との接続品質に左右されます。

中継回線は通常、近い接続ノードにいったん接続し、そこから中継ネットワークを経由して海外の出口へ送ります。目的はネットワーク間の経路と出口方向を調整することです。中継によって経路の段階は増えますが、遅延が必ず高くなる、または低くなるわけではありません。接続ノードまでの距離、中継品質、出口の混雑、対象地点によって結果は変わります。

IEPLは通常、通信事業者が提供する国際イーサネット専線サービスを指します。個人向けの定額サービスで回線にIEPLと表示されていても、一般にはサービス側の中間伝送区間で専線リソースを使うことを示すものであり、端末から接続ノードまでのローカルネットワークも専線になるわけではありません。最後の接続区間は家庭用ブロードバンド、無線、公衆インターネットを経由する場合があります。

そのため、回線種別を比較するときは、同じ出口地域と同じ測定対象を選びます。近距離の中継回線と遠距離の直結回線を遅延だけで比較するのは、公平な条件ではありません。回線ラベルは分類の手がかりとして使い、実際の性能は測定記録で判断しましょう。

プロトコルの違いを比較するときの条件統一

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、カプセル化方式と通信特性が異なります。ネットワーク環境を離れて固定的な速度順位があるわけではありません。クライアントの実装、サーバー設定、暗号化方式、下位トランスポート、ローカルシステムのネットワークスタック、中間ネットワークのポリシーが結果に影響します。

Shadowsocksは暗号化プロキシのプロトコル体系で、一般的な実装ではTCPとUDPの通信を扱えます。VMessとVLESSはそれぞれ対応するプロキシコアのエコシステムで使われることが多く、性能は組み合わせるトランスポート層とクライアント実装によって変わります。TrojanはTLSに見える形で接続を確立するため、TLSハンドシェイク、証明書設定、伝送経路が測定結果に反映されます。

Hysteria2はQUIC関連の仕組みとUDP転送を基盤とし、パケットロスや帯域変動のある経路向けに輻輳制御を提供します。TUICもQUICとUDPを基盤としています。ネットワークによっては変動する経路を活用しやすい一方、接続環境でUDPが制限されていると、接続性や速度に影響する場合があります。プロトコルの設計目標を、どの環境でも成り立つ速度保証として扱わないでください。

プロトコルを比較するときは、プロトコルだけを変更し、その他の条件を固定します。同じ地域、同じ出口、同じクライアントバージョン、同じ測定対象を使ってください。異なるプロトコルに異なるサーバーが割り当てられるサブスクリプションなら、その測定ではプロトコルとノードを同時に変えています。結果をプロトコルだけに帰することはできません。

• ✅ サブスクリプションリンクが更新され、クライアントに想定したノードとプロトコルが表示されていることを確認する。
• ✅ プロトコル比較では、回線地域、測定対象、ネットワーク接続方式を固定する。
• ✅ 接続成功率、遅延の変動、実際のアプリケーションでの状態も同時に確認する。
• ✅ UDP系プロトコルで異常がある場合は、現在のネットワークが該当する通信を許可しているか確認する。
• ❌ 異なる出口やサーバーの結果を、そのままプロトコル比較と呼ばない。
• ❌ 一度のダウンロードピーク値だけで、プロトコルに恒久的な順位を付けない。

サブスクリプションの取り込みとクライアント設定も結果を変える

サブスクリプションリンクは通常、ノード、プロトコル、接続パラメータをクライアントへ配布するために使われます。取り込みが成功したことは設定を読み込めたことを示すだけで、すべての通信が選択した回線を想定どおり通っているとは限りません。測定前にサブスクリプションを更新して明確なノードを選び、自動フォールバック、接続失敗、頻繁な再接続がないか接続ログを確認します。

プラットフォームによってクライアントの動作は異なります。WindowsとmacOSのクライアントは、システムプロキシ、仮想ネットワークインターフェース、またはその組み合わせを使うことがあります。システムプロキシはプロキシ設定に従うアプリに主に影響します。仮想ネットワークインターフェースはより広範囲の通信を取り込める一方、ルーティングテーブルと分割ルーティング規則の影響を受けます。Linuxクライアントでは、ネットワークインターフェース、ルート、DNS設定を自分で確認する必要がある場合があります。

iOSとAndroidは通常、システムが提供するVPNインターフェースでトンネルを確立します。モバイルOSの省電力設定、ネットワーク切り替え、バックグラウンド制限によって、継続測定が中断されることがあります。端末が無線からモバイル通信へ切り替わった時点で、元の測定条件は変わっています。切り替え前後の結果を同じ組にせず、基準値を取り直してください。

分割ルーティング規則は、どのドメインやアドレスをプロキシ経由にし、どれを直接接続するかを決めます。速度測定サイトが直結と判定されれば、表示されるのは元ネットワークの出口かもしれません。測定ページはプロキシを通る一方で、測定データのドメインが直結になると、結果が混在した経路になることもあります。測定前にグローバルモードで完全なトンネルを確認し、その後、通常の分割ルーティングモードで再測定するとよいでしょう。

グローバルモードは回線そのものを確認するのに適していますが、長期利用に最適な設定とは限りません。日常の分割ルーティングでは、ローカルサービスを直結のままにし、海外の対象だけを規則に従って回線へ通せます。最終的な記録にはモードを明記し、後からグローバルの結果と分割ルーティングの結果を同じ列で比較しないようにします。

出口アドレス、DNS、分割ルーティングが機能しているか確認する

速度が正常でも、経路が正しいとは限りません。測定の前後で、パブリックな出口アドレスがローカル通信事業者の出口から選択した回線の出口へ切り替わっているか確認します。出口地域の情報はアドレスデータベースに基づくため、更新の遅れがある場合があります。複数の確認元で照合し、都市名の表示だけでノードの実際の位置を判断しないでください。

DNSリークとは、トンネルや指定したリゾルバーで処理されるはずのドメイン問い合わせが、ローカルネットワークのリゾルバーへ送信され続ける状態です。問い合わせ元が推測されるほか、分割ルーティングの判定、コンテンツの振り分け、地域識別に不一致が生じる可能性があります。接続前後でリゾルバーの変化を確認し、クライアントのDNSモードとルーティング規則を合わせて結果を判断します。

検査ページにローカル通信事業者のリゾルバーが表示されても、すべての通信がトンネルを迂回していると単独で証明することにはなりません。クライアントによっては、システムリゾルバー、暗号化DNS、リモートDNSを組み合わせる場合があります。逆に、海外のリゾルバーが表示されても、すべてのアプリが同じ経路を使っているとは限りません。ブラウザー、OS、アプリはそれぞれキャッシュを持つことがあるため、設定変更後は接続を作り直して再測定します。

ブラウザーのWebRTC検査では、ローカルインターフェースのアドレスが表示される場合もあります。最新のブラウザーではローカルアドレスの表示方法が異なるため、インターフェース情報が見えたことを、そのままパブリックな出口アドレスの漏えいとみなしてはいけません。パブリック候補アドレス、実際の出口、クライアントのルーティングが一致しているかを確認します。

異常な結果の読み方と問題の切り分け

未接続の状態ですでにジッターが大きい、またはパケットロスが続いているなら、まずローカルネットワークを確認します。有線接続に切り替える、ほかの端末の通信を止める、ネットワーク機器を再起動するなどを行い、通信事業者にも回線状態を確認します。この段階で海外ノードを繰り返し切り替えても、接続区間の問題は解決しにくいでしょう。

基準値が安定しているのにすべてのノードが遅い場合は、クライアントモード、プロトコルの適合性、システムリソース、測定対象を確認します。暗号化とカプセル化には処理負荷がかかるため、性能の低い端末では高スループット時に処理上限へ先に達することがあります。タスクマネージャーやシステムモニターでCPU、メモリ、ネットワーク使用率を確認すると、端末側と回線側のボトルネックを切り分けやすくなります。

特定の地域だけが遅い場合は、地理的距離、出口の方向、対象サーバーの位置、その経路の時間帯による混雑が関係している可能性があります。物理的に最も近いノードを無条件に選ぶより、対象サービスに近い出口を選ぶほうが合理的なことがあります。たとえばコンテンツノードは出口アドレスに応じて振り分けられるため、経路は利用者から入口までの距離だけでは決まりません。

速度測定の数値が正常なのに動画がバッファリングする場合は、コンテンツプラットフォームの振り分け、画質の自動調整、ブラウザーのハードウェアデコード、アカウント地域を確認します。ウェブページが遅くてもファイルのダウンロードが安定しているなら、DNS応答、接続確立時間、分割ルーティング規則を調べます。リモートセッションが途切れる一方でダウンロードが速い場合は、ジッター、パケットロス、上り帯域がほかの処理に占有されていないかを重点的に確認します。

最後に元の記録を保存します。同じ手順で時間を置いて再測定すれば、問題が一時的なものか、時間帯に依存するものか、継続しているものかを確認できます。クライアント、プロトコル、回線を変更した場合も新しい組として記録し、以前の条件と混在させないでください。