VPN速度の実測方法：遅延と帯域幅を自分で測り、広告の数字に惑わされないために

VPN速度は、1回だけウェブテストをして得たピーク値だけで判断できません。実際に参考になるVPN速度の実測では、端末、接続回線、測定先、ノード、プロトコルを固定し、時間帯を変えて繰り返し確認します。結果は広告ページほど目立たなくても、ウェブページが遅い理由、動画がバッファリングする理由、会議が途切れる理由、ノード変更で改善するかを判断できます。

速度は単一の指標ではありません。遅延は操作への反応、パケットロスは再送、ジッターは音声やリアルタイム映像の安定性、帯域幅は大容量ファイルや高ビットレートコンテンツを継続転送する際の上限に影響します。これらを一括して「速い」「遅い」と扱うと、ローカルWi-Fi、接続先サーバーの制限、ルール分岐の誤り、回線混雑を同じ問題と誤認しやすくなります。

測定前にローカルネットワークの基準値を確認する

サービスに接続する前に、プロキシ経由ではないネットワーク状態を測定します。これは現在の接続環境における参考上限であり、国際ノード接続後も同じ帯域幅になることを意味しません。出口地域が変わると、より長い物理距離、複数の通信事業者ネットワーク、異なる接続先サーバーを経由するため、遅延の増加は完全には避けられません。

基準値を測る際は、家庭やオフィスのネットワークにある一時的な干渉をできるだけ取り除きます。大容量ファイルの同期、システム更新、クラウドへのアップロードを停止し、他の端末が回線を継続利用していないことを確認してください。無線ネットワークは距離、壁、同じ周波数帯の機器、自動ローミングの影響を受けます。結果が大きく変動する場合は同じ場所で再測定するか、安定した有線接続と比較します。

• ✅ 現在の接続方法と、無線ネットワークを使用しているかを記録する。
• ✅ 継続的にデータをアップロード、ダウンロード、同期するバックグラウンド処理を停止する。
• ✅ 同じ測定先で、未接続時と接続時の状態をそれぞれ記録する。
• ✅ 端末、電源モード、ブラウザー、クライアントのバージョンを揃える。
• ✅ 測定トラフィックが想定したノードを実際に通過し、ルール分岐で迂回していないことを確認する。

ウェブ測定はダウンロード、アップロード、応答時間をすばやく確認するのに適していますが、ブラウザー、同時接続方式、測定サービスの負荷、サーバー選択の影響を受けます。OS標準のネットワーク診断ツールは遅延やパケットロスの継続観察に向いています。ただし、サーバーによってはICMP応答の優先度を下げるため、コマンドライン上のパケットロスが業務トラフィックのロスと一致するとは限りません。実際の判断では、ツールの数値をウェブ、動画、ファイル転送、リモートセッションの状態と合わせて確認します。

遅延、パケットロス、ジッター、帯域幅の意味

遅延とは、端末から接続先へデータを送り、戻ってくるまでの時間です。検索候補、ウェブページの初期表示、リモートデスクトップ、オンラインゲーム、対話型AIリクエストに影響します。ノードの地理的位置だけでなく、接続事業者、ネットワーク間の経路、入口の負荷、中継構成も往復経路を変えます。地図上で近いノードが、実際のネットワーク経路でも短いとは限りません。

パケットロスは、一部のデータが正常に届かなかった状態です。TCP接続では欠落データを再送するため、ダウンロード速度の低下、ウェブページの停止、動画ビットレートの自動低下として現れることがあります。UDPベースのリアルタイム通信では適時性が重視され、遅れて届いたデータが役に立たない場合もあるため、音声の途切れ、映像のフリーズ、操作の引っかかりとして表れやすくなります。

ジッターは、時間経過に伴う遅延の変動幅です。平均遅延が正常でも、すべてのパケットが安定しているとは限りません。応答時間が速くなったり遅くなったりすると、リアルタイムアプリは途切れることがあります。帯域幅は単位時間あたりに転送できるデータ量で、継続的なダウンロード、アップロード、バックアップ、ストリーミングの容量上限に近い指標です。帯域幅が大きくても深刻なパケットロスは補えず、低遅延でも大容量ファイルが速く転送できるとは限りません。

ピーク時間帯と深夜を分けて測る理由

国際回線の使用感には、時間帯による差がはっきり出ます。夕方から夜のピーク時間帯は、ローカルアクセス網、事業者間接続、ノード入口、接続先サイトが同時に多くの通信を処理する可能性があります。深夜は経路が空いていることが多いものの、低負荷時の性能しか示しません。深夜に1回だけ高速な結果が出ても、普段の利用時間帯に同じ状態が続くとは判断できません。

より適切なのは、実際にサービスを使う時間帯に測定する方法です。仕事用途なら、普段の会議、アップロード、資料検索の時間帯を含めます。動画や音楽なら、よく視聴する時間帯を確認します。毎回同じ測定先と操作順を使い、結果を保存してください。1回の結果が低かったからといって複数の設定をすぐ変更すると、原因が時間帯なのか設定なのか分からなくなります。

測定サーバー自体が混雑している場合もあります。ある測定先だけ急に遅くなったら、同じ地域の別の測定先に切り替えて検証します。複数の測定先が同時に低下し、未接続時の基準値が安定しているなら、回線混雑の可能性が高いでしょう。特定のウェブサイトやダウンロード元だけが異常なら、接続先サービス、配信ノード、または双方の接続経路に原因がある可能性があります。

ノード構成とプロトコルが実測結果を変える仕組み

直結回線は通常、ユーザーのネットワークから海外の入口へ直接接続するため経路が単純ですが、相互接続の品質はローカルの通信事業者やインターネット接続に左右されます。中継回線は近い入口に接続してから中継ネットワーク経由で出口へ送るため、一部の経路を調整できますが、保守と制御が必要な区間が1つ増えます。IEPL専線は通常、企業向けの国際イーサネット専線または関連する伝送方式を指し、入口と出口の接続に使われます。これは回線区間を表すもので、端末から入口まで、また出口から接続先サイトまでの全区間が専線とは限りません。

そのため、「IEPL」「中継」「直結」という表示だけで判断せず、ローカルでの実測を基準にします。端末に近く、利用する事業者との相性がよい中継ノードは、地理的には近くても経路が迂回する直結ノードより安定することがあります。逆に、中継入口が混雑していたり、出口から接続先までの相互接続が不安定だったりすれば、回線の表示だけでボトルネックは解消できません。

プロトコルも結果に影響します。Shadowsocksは暗号化プロキシプロトコルで、クライアントはシステムプロキシやTUNモードで通信を取り込みます。VMessとVLESSは同じクライアントエコシステムでよく使われ、VMessは認証と暗号化の設計を備え、VLESSはより軽量で、通常は外側の安全な通信方式によって機密性を確保します。TrojanはTLSベースの伝送方式を使用します。Hysteria2とTUICは主にUDPおよびQUIC系の仕組みに基づき、それぞれの輻輳制御と伝送設計で複雑な経路に対応します。

これは、どのネットワークでも特定のプロトコルが速いという意味ではありません。UDPを適切に扱えるネットワークでは、Hysteria2やTUICがスムーズに動くことがあります。一方、UDPを制限、整形、または不安定に転送するネットワークでは、TCPベースの方式のほうが予測しやすい場合があります。プロトコルを比較する際は、同じ地域と近い出口を固定し、接続確立、継続転送、パケットロス、実際のアプリの動作を確認します。名称だけを比べないでください。

再現可能なVPN速度測定の手順

以下の手順の目的は、見栄えのよいスクリーンショットを作ることではなく、ノードとプロトコルを比較できる状態にすることです。日付、時間帯、端末、接続ネットワーク、ノード名、プロトコル、測定先、実際の使用感を表に記録します。契約更新後はノード名が変わる場合があるため、地域と回線タイプも併記するとよいでしょう。

1. 環境を整える。バックグラウンド通信を停止し、端末の位置と接続方法を固定して、システムが更新中でないことを確認します。
2. 未接続時の基準値を測る。選んだウェブ測定先と実際に使うサービスを利用し、遅延、パケットロスの状態、ダウンロード、アップロードを記録します。
3. 指定したノードに接続する。クライアントが接続済みと表示することを確認し、出口地域が想定どおりか確認します。
4. 短時間のウォームアップを行う。通常のウェブページを開くか軽いリクエストを送り、接続、DNS解決、ルートの状態を安定させます。
5. 決めた順番で測定する。まず遅延と継続的な安定性を確認し、次にダウンロードとアップロード、最後に実際の作業を1回行います。
6. 切断後に基準値を再測定する。測定中にローカルネットワークが変化していた場合、この結果には個別に印を付け、安定していた時間帯の結果と混ぜないようにします。
7. 変更する変数は1つにする。ノードだけ、またはプロトコルだけを変更して、同じ手順を繰り返します。測定サーバー、クライアント、ネットワークを同時に変更しないでください。
8. 普段の時間帯に再測定する。ピーク時間帯と低負荷の時間帯を分けて比較し、差が継続して現れるかを確認します。

実際の作業を使ったテストも重要です。ウェブ測定は同時転送の影響を受けやすく、ファイルのダウンロードは配信元の制限を受け、動画サービスはバッファーや端末性能に応じてビットレートを自動調整します。リモートワークでは、文書同期、コードリポジトリへのアクセス、会議の安定性を確認します。動画や音楽では、再生開始までの待ち時間、シーク後の復帰、継続再生を見ます。ゲームではダウンロード帯域幅より、遅延、ジッター、パケットロスを重視してください。

クライアントのルール分岐とDNSで結果は変わるか

変わることがあります。多くのクライアントはルール分岐に対応しており、ローカルサイトは直結、国際サイトはノード経由、LANアドレスはローカルアクセスという構成にできます。測定サイトが直結と判定されると、表示されるのはノードの速度ではなくローカル回線の速度です。一方、グローバルモードやTUNモードを有効にすると、より多くのシステム通信がプロキシ経路に入り、ブラウザーのシステムプロキシモードとは異なる結果になる場合があります。

測定前に、クライアントの接続ログ、アクティブな接続、ルートに関する表示を確認し、測定ドメインがどのルールを通っているかを確認します。プラットフォームによって機能も異なります。デスクトップクライアントは接続ログ、ルーティングテーブル、システムプロキシの状態を確認しやすい傾向があります。モバイル端末では、システムのネットワークインターフェース、バックグラウンド制御、省電力機能の影響を受け、アプリを切り替えた後に挙動が変わることがあります。アプリごとの分岐、TUN、システムプロキシ、カスタムDNSに対応しているかは、クライアントの実際の機能を確認してください。

DNSリークとは、ドメインの問い合わせが想定した解決経路に渡されず、ローカルネットワークや別のDNSサービスへ送られる状態です。帯域幅を直接下げるとは限りませんが、不適切な配信ノードへ解決されたり、アクセス経路と出口地域が一致しなくなったりすることがあります。確認する際は、まずクライアントのDNSモードを確認し、解決結果からDNSサービスと出口地域が妥当かを見ます。

ブラウザー内蔵のセキュアDNSがクライアント設定を迂回し、システムツールとブラウザーで異なる結果になることもあります。確認時は一時的にDNS経路を1つに固定し、システムでの名前解決とブラウザーでのアクセスを比較します。テスト後は、自分の用途に合った安全設定へ戻してください。測定値を上げるために必要な保護機能を長期的に無効化してはいけません。

• ✅ 測定ドメインがプロキシルールに一致し、直結ルールになっていないことを確認する。
• ✅ ブラウザーとシステムが異なるDNS経路を使用していないか確認する。
• ✅ システムプロキシ、TUN、アプリ内プロキシを比較する際は、それぞれのモードを記録する。
• ✅ 出口地域が異常な場合は、ノード障害と判断する前にルール分岐を確認する。
• ✅ 測定結果を共有する前に、契約用URL、ノードの認証情報、完全なログを隠す。

速度測定のよくある誤解と結果の見方

契約用リンクをオンラインツールに直接貼り付ける

契約用リンクからは通常、ノード設定を取得できます。アカウントの認証情報と同じように扱ってください。出所の不明なオンライン測定ページに送信せず、完全なリンクをスクリーンショット、フォーラム投稿、共有ドキュメントに載せないでください。ノードをまとめて比較する場合は、信頼できるクライアントに契約情報を取り込み、ローカルで個別に測定します。

ダウンロードだけ測り、アップロードと安定性を見ない

ビデオ会議、クラウド同期、画像の送信、リモート開発はいずれもアップロードに依存します。アップロードを別の作業が使い切ると、ネットワークの待ち行列が発生し、ダウンロードと操作も同時に遅くなることがあります。測定中にアップロード時の遅延が大きく変動するなら、ダウンロードのピーク値だけでなく、ローカルの上り回線使用量とキューを確認してください。

異なる測定先でノードを比較する

一方のノードはローカルの測定サーバー、もう一方は遠隔の測定サーバーに接続している場合、2つの結果を直接比較できません。サーバーのハードウェア、帯域幅、負荷、相互接続経路が異なるためです。ノード比較では測定先を固定し、実際の用途を判断するときに用途に合ったウェブサイト、ダウンロード元、アプリを追加します。

プロトコルを切り替えれば回線問題が必ず直ると思う

プロトコルは伝送方式を変えられますが、物理回線や通信事業者間の接続問題をすべて解決できるわけではありません。同じノード、同じ時間帯で異なるプロトコルが似たように低下するなら、入口または出口の経路を引き続き確認します。UDPベースのプロトコルだけが異常でTCPベースの方式が安定している場合は、現在のネットワークにおけるUDPの扱いが関係している可能性があります。

最終的には、結果を単純な順位ではなく、実行可能な結論にまとめます。ローカルの基準値が不安定なら接続環境を改善します。特定の時間帯に低下するなら、同じ地域の予備ノードを用意します。特定のアプリだけに異常があるなら、ルール分岐、DNS、接続先サイトを確認します。特定のプロトコルが現在のネットワークで繰り返し失敗するなら、より適した伝送方式を選びます。再現可能な測定手順こそ、長期的な使用感を判断する基盤です。