VPN速度を実測比較｜実際の通信速度を自分で測る方法

VPNの速度を実測するときに大切なのは、最高速度のスクリーンショットを撮ることではありません。普段使うWebサイトがすぐ表示されるか、ダウンロードが安定して続くか、夜間の混雑時に何度も止まらないかを確かめましょう。まず通常のネットワークを測り、測定先を固定して回線を比較したうえで、実際の用途でも確認します。結果は、そのときの端末・ネットワーク・接続先の組み合わせを示すものです。

速度測定の指標：ダウンロードの最高値だけではわからないこと

速度測定ページのダウンロード速度は、測定中にサーバーからデータを受信する能力を示します。大きなファイルの転送状況を見るには役立ちますが、Webページの表示が遅い、動画のシーク後に待たされる、リモート接続が途切れるといった問題を単独では説明できません。ページの表示には通常、名前解決や接続の確立、サーバーからの応答待ちも必要です。どこか一つでも遅れれば、実際の使い心地は測定値ほどよくないことがあります。

指標の意味と判断の目安（共通の合格ラインはありません）
指標	主に確認できること	数値だけでは判断できないこと
ダウンロードスループット	データを継続して受信する能力。ダウンロードや動画の読み込みに影響します	最高値が高くても、すべてのWebサイトが速いとは限りません
アップロードスループット	ファイル送信、データ同期、ビデオ会議での上り通信	ダウンロードが速くても、アップロードも十分とは限りません
往復遅延（RTT）	リクエストを送って応答が返るまでの待ち時間	測定サーバーへの遅延が、サービスのWebサイトへの遅延と同じとは限りません
ジッター	時間経過に伴う遅延の変動幅	平均遅延が低くても、操作が常にスムーズとは限りません
パケットロスと再送	データの欠落や再送、タイムアウトの有無	測定用パケットに応答がないからといって、通信データが失われたとは限りません

アイドル時と負荷時の遅延も区別しましょう。回線が空いているときは応答が正常でも、ダウンロードを始めると操作が明らかに遅くなる場合は、アクセス回線のキューイングやルーターのバッファ、帯域の使い切りが原因かもしれません。ダウンロードの最高値ばかり追うと、作業の妨げになる待ち時間を見落としがちです。

基準値を測る：端末とアクセス回線の影響を先に確認

まずプロキシに接続していない状態で、直接アクセスできる安定した測定先を試します。基準値を測る目的は、手元のネットワークに問題がないか確認することです。直接接続とプロキシ接続で同じ結果を求めるものではありません。地域によってサーバーまでの経路は異なるため、近くの速度測定サイトの結果を海外アクセスの理論上の上限とみなすことはできません。

端末と接続方法をそろえる。比較中は同じ端末、同じ接続場所を使います。可能なら有線接続にし、Wi-Fiを使う場合は場所を変えず、移動しながら測定しないようにします。
ほかの通信を止める。クラウドストレージの同期、OSの更新、ダウンロード、ほかの端末での大容量通信がないか確認します。複数の速度測定ページを同時に動かすと、互いに帯域を奪い合います。
測定時の環境を記録する。OS、クライアントのバージョン、接続ネットワーク、測定時刻、電源の状態を記録します。端末の発熱、省電力設定、バックグラウンドの処理も結果に影響することがあります。
基準値を繰り返し確認する。時間を空けて測り、結果が再現するか確認します。プロキシ未接続でも頻繁に変動する場合は、接続先の回線を評価する前に、まずローカル環境の問題を解消しましょう。

iOSとAndroidでは、システムの権限や省電力設定がクライアントの動作に影響することがあります。デスクトップでは、ほかのプロキシソフトや仮想ネットワークアダプター、ファイアウォールも確認してください。測定のためにセキュリティ機能をすべて一時停止するのは避け、ソフトウェアの競合やルーティング設定を確認しましょう。トラブルの切り分けが新たなリスクにならないように注意が必要です。

測定経路を確認：速度測定の通信がどこを通るか

SpeedtestやFastなどの定番ツールは参考になりますが、接続するサーバーや同時接続の方法、バックエンドのネットワークはそれぞれ異なります。自動で測定先を選ぶ設定では、出口の変化に応じてサーバーが変わり、測定対象がそろわないことがあります。回線を比較するときは、なるべく同じツールと測定先を使い、サーバー名と地域も記録しましょう。測定先を固定できない場合は、その旨を記録に残します。

システムプロキシを設定しても、すべてのプログラムの通信がプロキシ経由になるとは限りません。ブラウザーはプロキシ設定に従う一方、コマンドラインツールやゲーム、単体で動作するアプリは直接接続することがあります。TUNモードは通常、仮想ネットワークインターフェースを使って、より多くの通信を取り込みます。ただし、対象範囲はルーティング、除外リスト、クライアントの実装によって異なります。測定前にクライアントの接続ログを確認し、測定対象のドメインが想定した回線を使っているか確かめてください。

まずIPアドレス確認でブラウザーの接続元を確認し、次にクライアントで速度測定のリクエストに適用されたルールを確認します。接続元の地域が変わっても、それで確認できるのはその測定リクエストの経路だけです。端末上のすべてのアプリが同じ経路を使っている証明にはなりません。測定後は普段使う振り分けルールに戻して、よく使うアプリでも再確認しましょう。そうしないと、一時的な設定での結果しかわかりません。

プロトコル名は速度ランキングではありません。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ実装や適したネットワーク環境が異なり、クライアント側の対応設定も必要です。プロトコルを比較する際に地域とサーバーも同時に変えると、差がプロトコル、回線、接続先のどれによるものか判断できません。

時間帯を変えて実測：通信の安定性を記録

普段使う時間帯と夜間の混雑時に測定し、日を変えて再確認します。各回で端末、ツール、測定先、設定をそろえ、回線ごとの測定順も入れ替えます。特定の回線だけいつも空いている時間に測ることを避けられます。測定の合間にはネットワークが落ち着く時間を設け、通信を連続して重ねないようにしましょう。

最高値だけでなく、開始直後、速度が安定している間、終了前の変化も記録します。一時的に速度が跳ね上がった後に下がる場合と、最初から最後まで安定している場合では、使い心地が異なります。複数回の結果から標準的な速度と変動幅を比較できます。ツールに中央値が表示される場合は参考になりますが、失敗やタイムアウト、異常値も記録に残し、見栄えのよい結果だけを選ばないでください。

✅ 環境：測定時刻、接続ネットワーク、端末、クライアントのバージョン、動作モード
✅ 経路：ノード名、接続元の地域、測定先、適用された振り分けルール
✅ 結果：ダウンロード、アップロード、アイドル時と負荷時の遅延、ツールが対応する場合はジッターやパケットロス
✅ 使用感：Webページの表示待ち、動画のバッファリング、ファイル転送の中断、実際のタスクの完了状況
❌ サーバー、端末、測定時刻が異なるスクリーンショットを、そのまま速度ランキングとして並べない。

速度測定では通信量を消費し、スループットの高い測定ほど消費量も大きくなります。VPNBonusの月額プランの通信量は利用開始日を基準に毎月リセットされます。追加の通信量パックは使い切るまで利用でき、有効期限はありません。測定前に残量を確認し、目的を絞った少数の比較で問題を特定しましょう。帯域を何度も使い切る測定が、通信量消費の大半を占めないようにしてください。

遅延とパケットロス：測定結果を正しく読み取る

pingはICMP応答の確認によく使われますが、通常はブラウザーのHTTPプロキシやSOCKSプロキシの設定に従いません。トンネルを通るかどうかは、ルーティングとクライアントのモードによって決まります。ブラウザーはプロキシ経由でも、測定コマンドは直接接続している場合、両者の結果をまとめて解釈することはできません。測定先によってはICMPを制限したり無視したりするため、タイムアウトしてもWebサイトにアクセスできないとは限りません。

同様に、tracerouteやtracertで途中のホップから応答がなくても、ルーターが測定への応答を低い優先度にしているだけかもしれません。後続のホップや最終接続先に問題がないなら、そのノードが実際の通信を破棄していると判断するのは早計です。最終接続先で継続的な異常があるか、実際のアプリでも同時に遅延や再試行が起きているかを確認しましょう。

クライアントに表示される「遅延」も、測定方法の確認が必要です。ノードへの接続確立にかかる時間を測る場合もあれば、ノード経由で指定URLにアクセスする場合もあり、サービスへのリクエスト全体の所要時間とは限りません。比較では測定方法をそろえましょう。意味を確認できない場合は、最終的な判断ではなく候補を絞る参考値として扱います。

実際の用途で確認：Web、動画、ファイル転送

Webサイトとオンラインツール

普段使うページを選び、初回表示とその後の操作をそれぞれ確認します。初回のリクエストでは、名前解決や接続の確立、コンテンツの読み込みが発生する一方、再訪時にはキャッシュが使われることがあります。初回の表示速度を比較する場合はキャッシュの条件をそろえましょう。普段の作業環境を確認したい場合は、ログインや検索、フォーム送信など一連の操作を記録し、トップページが開くかどうかだけで判断しないでください。

動画再生と継続的なダウンロード

動画は同じコンテンツと画質にそろえ、再生開始までの待ち時間、シーク後の復帰、再生中の安定性を確認します。自動画質調整は画質を下げて帯域不足を目立たなくすることがあります。ファイルのダウンロードでは同じ配布元を使い、速度が安定して続くか確認しましょう。ブラウザー表示のMB/sと速度測定ツールのMbpsは単位が異なるため、数値をそのまま比較できません。

DNSと振り分け設定の不具合

一部のWebサイトだけ遅い場合は、名前解決の経路、ルールの適用状況、接続先サービスの状態を確認します。DNSリークの確認では、名前解決リクエストが想定した経路を通っているかを見ます。リゾルバーの所在地だけでは、プライバシー上のリスクや設定の正しさを完全には判断できません。クライアントのDNS設定と接続ログを合わせて確認し、想定外のローカル名前解決がないか調べましょう。ブラウザーのセキュアDNSとシステムの名前解決で、異なる経路が使われる場合もあります。

原因を切り分ける：遅さを対処できる問題に分解する

基準値も遅い場合は、アクセス回線、Wi-Fiの干渉、端末上の処理を確認します。基準値は正常なのにすべてのノードが遅い場合は、クライアントのモード、端末の負荷、共通して通るネットワーク経路を調べましょう。特定の地域や接続先だけ遅い場合は、同じ地域の別の出口や接続先サービスの状態を優先して比較します。原因を判断できるよう、変更する条件は一度に一つにします。

直接接続、中継、IEPL専用線は、それぞれ異なる経路構成を指すもので、決まった速度のランクではありません。中継で経路が改善する場合もあれば、迂回によって長くなる場合もあります。IEPLは通常、国際専用イーサネット回線を指しますが、回線のラベルだけでは通信全体が専用線を通るとは限りません。共有負荷や出口の混雑も否定できないため、同じ方法で接続先までの使い心地を確かめてください。

さらに詳しく調べる場合はトラブルシューティングガイドをご覧いただくか、ヘルプページから状況をお知らせください。測定した時間帯やネットワーク環境、ノード名、個人情報を伏せたエラー情報があると、「速度が遅い」という説明だけの場合より原因を特定しやすくなります。スクリーンショットを送る前に、アカウント情報とサブスクリプションの認証情報を隠してください。