VPN速度実測の前にテスト条件をそろえる
VPN速度を比較するときは、ダウンロードの最高値だけで判断できません。端末やネットワーク、測定先サーバー、クライアントの設定をそろえてから、遅延・ジッター・パケットロス・継続的なダウンロード速度を比べましょう。最後に普段使うサイトでも確認すると、自分に合った回線を判断しやすくなります。
速度測定の結果には、Wi-Fiなどのローカルネットワーク、通信事業者の接続、プロキシ回線、出口ネットワーク、測定先サーバーなど、複数の区間が影響します。どこか一か所が混雑するだけでも数値は変わります。速度が低下していても、その時点の経路全体の状態を示すものであり、サーバー側の帯域不足とは限りません。
測定前にクラウド同期やシステム更新、ほかのダウンロードを一時停止し、できるだけ同じ接続方法を使います。有線接続が可能なら基準値を測定し、Wi-Fiしか使えない場合は端末の位置とアクセスポイントを固定しましょう。自宅のWi-Fiで測った結果と外出先のネットワークで測った結果を、そのまま回線の順位づけに使うのは避けてください。
まず、未接続の状態でも正常にアクセスできる測定先を確認してから、回線に接続して再測定します。未接続時に測定先へアクセスできない場合は、別のアクセス可能な測定先でローカルネットワークを確認しましょう。アクセスできないことを速度ゼロとして扱わないでください。
速度測定ツールで分かること
総合的な速度測定、接続診断、実際の用途での確認は分けて行うのがおすすめです。複数のツールは相互に補完できますが、測定サーバーの場所や接続数、測定方法が異なるため、別々のツールの数値をそのまま並べて順位づけすることはできません。
| ツール・方法 | 確認できること | 使用時の注意点 |
|---|---|---|
| Speedtest | ダウンロード・アップロード速度と遅延 | 可能であれば測定サーバーを手動で固定し、アプリまたはウェブページのバージョンも記録する |
| FAST.com | Netflixの測定インフラまでの通信状況 | すべてのウェブサイトの速度や、コンテンツの地域制限の状態までは判断できない |
| ping | 測定先の応答時間、変動、ICMPパケットロス | 通常、ウェブ通信だけをプロキシ経由にするシステムプロキシは通らない。測定先が応答を制限している場合もある |
| ブラウザーの開発者ツール | ページリクエストの接続、応答待ち、リソースのダウンロード状況 | キャッシュ、接続の再利用、拡張機能、サイト側サーバーの影響を受ける |
| 動画視聴、オンライン会議、ファイル転送など実際の利用 | バッファリング、通話の途切れ、継続的な転送速度 | コンテンツと画質を固定し、配信サービス側の制限を回線の問題と誤認しない |
サーバーの自動選択は便利ですが、出口を切り替えると測定ツールが別の地域のサーバーを選ぶことがあります。その場合、異なる経路を比較することになります。最初に選ばれたサーバーの名前と地域を記録しておきましょう。固定できない場合はその旨を記録し、結果の比較には慎重さが必要です。
指標をそろえるために、出所の分からないツールをインストールする必要はありません。クライアントは信頼できる配布元から入手しましょう。オンライン速度測定では実際に通信量が発生し、連続測定は特にプランの通信量を消費しやすいため、測定の前後に管理画面で使用量を確認してください。
遅延・ジッター・パケットロス・帯域幅の見方
遅延：操作への応答に関わる指標
遅延は通常、データが測定先との間を往復するのにかかる時間を指します。ウェブ接続やリモートデスクトップ、リアルタイム通話に関係しますが、ページが完全に表示されるまでの時間ではありません。ページ上のスクリプト実行や画像の読み込み、サイトからの応答にも時間がかかるため、遅延が小さくてもすべてのページが速く開くとは限りません。
アイドル時の遅延とダウンロード中の遅延は分けて確認しましょう。ダウンロードを始めた途端に操作の反応が明らかに遅くなる場合、キューの混雑やローカル側のアップロード帯域の占有が関係している可能性があります。アイドル時の遅延だけでは、実際の利用中に起きる遅さを見落とすことがあります。
ジッターとパケットロス：通信の安定性を確認
ジッターは時間の経過に伴う遅延の変動を示しますが、計算方法はツールによって異なる場合があります。継続的に比較する際は、同じツールを使いましょう。平均遅延が近い回線でも、一方で急に遅くなることが頻繁にあれば、会議やリモート操作の使い心地は大きく異なる可能性があります。
パケットロスは、一部の測定データや通信データが想定どおりに届かなかったことを示します。ただし、ルーターがICMP応答の優先度を下げていることもあり、中継ノードが応答しなくても実際の通信データがそこで失われたとは限りません。最終的な測定先や実際のアプリ、複数回の測定結果とあわせて判断し、1回のpingだけで結論を出さないでください。
ダウンロードとアップロード：継続的な速度を確認
ダウンロード速度は大容量ファイルの取得や動画のバッファリングに、アップロード速度は会議映像の送信、ファイルの提出、バックアップに影響します。ツールの単位がMbpsかMB/sかを確認してください。単位が異なるため、数値をそのまま比較できません。また、一時的な最高速度と継続的な転送速度は別です。最初だけ速く、その後長時間低下する場合、最高速度を維持できているとは言えません。
時間帯別の比較手順と記録方法
朝・昼・夜に測定する目的は、数値を増やすことではなく、普段使う時間帯による違いを確認することです。実際にネットワークを使う時間帯を含め、できるだけ条件をそろえて繰り返し測定しましょう。ある日の偶然の最高値を、長期的な実力とみなさないでください。
- 利用環境を記録する。端末、OS、クライアントのバージョン、接続ネットワーク、有線・無線の別、ほかの端末で通信が行われていたかを記録します。
- 通信経路を確認する。回線名、プロキシモード、測定先を記録します。測定リクエストが選択した回線を通っているか確認してから測定を始めましょう。
- 決めた順序で測定する。まずアイドル時の応答を確認し、次にダウンロードとアップロードを測定してから、普段使うウェブサイトやアプリを開きます。複数の速度測定を同時に実行して帯域を奪い合わないようにしましょう。
- 時間帯を変えて再測定する。朝・昼・夜とも同じ測定先と設定を使います。回線を切り替えた後は接続が安定するまで待ってから、次の測定を始めてください。
- 異常も記録に残す。最高値だけでなく、切断や再接続、動画のバッファリング、ページの読み込み失敗も記録します。異常が起きたときは、バックグラウンドの処理やネットワークの変化も書き留めてください。
記録には一般的な表計算ソフトを使えます。日時、ネットワーク、回線、測定先、モード、遅延、ジッター、パケットロス、ダウンロード、アップロード、実際の使用感を記録しましょう。ツールで測定できない項目は「未測定」とし、別のテスト結果で埋めないでください。たまたま起きた異常は削除して見栄えのよい結果だけを残すより、再確認したほうが参考になります。
比較では、まず通常時の傾向を確認し、次に変動の幅を見ます。普段使う時間帯に安定している回線は、最高速度が目立たなくても使いやすい可能性があります。結果のばらつきが大きい場合は、回線の混雑を疑う前に、ローカル環境や測定先が変わっていないか確認しましょう。
ルール分岐とDNSを確認し、測定経路を見誤らない
システムプロキシ、ルールモード、TUNモードはそれぞれ異なります。システムプロキシは通常、その設定を利用するアプリにのみ影響します。ルールモードはドメインやアドレスなどの条件に応じて通信経路を選び、TUNモードは仮想ネットワークインターフェースで対象の通信を処理しますが、ルーティングや除外ルールの影響も受けます。
そのため、ブラウザーがプロキシを経由していても、端末上のpingまで同じ経路を通るとは限りません。クライアントの接続ログやルールの適用記録を確認し、測定に使うドメインが想定した出口を使っているか確かめましょう。プラットフォームによってネットワーク拡張機能やアプリの動作も異なるため、異なるOSの結果は個別に記録し、回線の品質だけが原因だと決めつけないでください。
DNSの名前解決によってドメインに対応するアドレスが決まり、コンテンツ配信ネットワークの接続先選択にも影響する場合があります。ブラウザーのセキュアDNS、システムのリゾルバー、クライアントのDNS設定が同時に使われることもあります。DNSリクエストを指定した経路に通す設定なのに、実際は別の経路から送信されている場合は、回線を何度も切り替えるのではなく設定を確認しましょう。
- ✅ クライアントの接続ログで、測定リクエストに適用されたルールと出口を確認する。
- ✅ サイト内のネットワークチェックで出口情報を確認し、クライアントのログとあわせて経路を判断する。
- ✅ ブラウザーのセキュアDNSとクライアントの名前解決ポリシーが競合していないか確認する。
- ❌ 出口IPが変わったことだけを根拠に、すべてのアプリやDNSが想定どおりの経路を通っていると判断しない。
DNSチェックページで確認できるのは、通常、リゾルバーに関する情報です。見慣れない地域や異なる事業者が表示されても、それだけで情報漏えいとは限りません。想定している設定やクライアントのログ、複数回の測定結果とあわせて判断しましょう。
専用線・中継・直結・プロトコルが測定結果に与える影響
直結は通常、クライアントから海外のサーバーへ直接接続する方式を指します。中継では、まず接続用または転送用のノードを経由します。IEPL専用線は回線の伝送方式を示すもので、クライアントのプロトコルではありません。こうした名称から分かるのは経路設計の概要です。利用環境から入口まで、出口から測定先までの実測値に代わるものではなく、すべての接続先で同じ速度が出ることを示すものでもありません。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルや実装方式です。通信方式、暗号化の設定、クライアントの対応状況、サーバー側の設定などによって動作は変わります。プロトコル名だけから速度の順位を推測したり、特定のプロトコルが常に速いと判断したりすることはできません。
複数の設定が提供されている場合は、まずクライアントが明確に対応している設定を使い、ほかの条件をそろえて比較しましょう。サブスクリプションURLは設定を取得するための入口であり、速度を証明するものではありません。アクセス用の認証情報が含まれる場合もあるため、公開する測定レポートや不慣れなオンライン変換ページに貼り付けないでください。
異なるプロトコルを比較する場合は、クライアントと通信設定もあわせて記録します。そうしないと、差が生じた原因が回線そのものではなく、クライアントの実装や端末の処理能力、ローカルネットワークの通信方式への対応状況にある可能性を見落とします。
速度測定は速いのに実際のアクセスが遅いときの確認方法
まず、問題がどこまで広がっているか確認します。どの測定先も遅い場合は、ローカルネットワークやバックグラウンドの通信、クライアントのモード、使用中の回線を優先して確認しましょう。特定のウェブサイトだけが遅い場合は、サイトの稼働状況や名前解決の結果、地域に応じた接続先の選択、アプリ独自の制限を確認します。速度測定サーバーで良い結果が出ても、そのサーバーまでの経路が良好だということしか分かりません。
動画を確認するときはコンテンツと画質を固定し、バッファリングや再生の途切れを見ます。速度測定では十分な帯域が出ているのに動画を再生できない場合は、アカウントやコンテンツの地域制限、出口に対する配信プラットフォームの判定が関係している可能性があります。ダウンロードの最高速度を追い求めても解決しないことがあります。会議では実際に通話し、音声の途切れや映像の停止、アップロード帯域の使用状況を確認しましょう。
ウェブページの表示は遅いのにファイルのダウンロードは正常な場合、ブラウザーの開発者ツールでDNS解決、接続、応答待ち、リソースのダウンロードにかかる時間を切り分けられます。キャッシュや接続の再利用で結果が変わるため、比較する際は条件をそろえてください。問い合わせを送る場合は日時、回線、測定先、モードを添え、スクリーンショットにサブスクリプションURLやアカウント情報が写らないように隠しましょう。