VPNの速度実測は、ウェブ測定ツールを開いて一度ダウンロード結果を確認するだけでは不十分です。回線速度は、ローカル接続、通信事業者間の接続、出口側の混雑、測定サーバーの場所、プロトコルの実装、端末の負荷に左右されます。異なる回線を比較する際に重要なのは、瞬間的に高く見える数字を追うことではなく、環境と手順を固定して繰り返し、遅延、ジッター、パケットロス、ダウンロード、アップロード、実際のアプリ利用時の挙動を同じ記録に残すことです。
信頼できるテストでは、現在のネットワークで回線が安定しているか、目的のアプリに適しているかという2つの問いに答えます。ウェブ閲覧、リモートワーク、ファイル転送、リアルタイム通話、ゲームでは重視すべき指標が異なります。帯域幅だけでは操作時の遅延を見落とし、遅延だけでは大容量ファイルの転送能力を判断できません。以下の方法は特定のブランドに依存せず、一度の結果を長期的な結論として扱いません。
まず速度測定環境を固定してから回線を比較
比較テストでよくある問題は、測定対象と環境が同時に変わってしまうことです。たとえば、一方は有線ネットワークで測定し、もう一方は混雑した無線ネットワークを使うケースがあります。片方の測定中だけバックグラウンド同期が終了していたり、別の測定中にシステム更新が始まったりすることもあります。最終的な差が回線そのものに由来するとは限りません。
正式に記録する前に、サービスへ接続していない状態のベースラインを測定します。ベースラインはローカルネットワークの品質を証明するためではなく、ボトルネックが接続側ですでに発生しているかを判断するためのものです。直接接続の時点で大きなジッターや継続的なパケットロスがある場合、どの国際回線に接続しても安定した結果を得るのは困難です。ベースラインと回線テストでは、同じ端末、同じ接続方式、同じ測定対象を使う必要があります。
- ✅ 同じ端末、同じネットワーク接続方式、同じ場所に固定する。
- ✅ クラウドストレージの同期、システム更新、動画再生など、帯域幅を継続的に使う処理を停止する。
- ✅ 利用中の通信事業者、接続プロトコル、回線名、測定対象、測定時間帯を記録する。
- ✅ 未接続状態を先に測定し、その後、同じ順番で候補回線を測定する。
- ✅ 各ラウンドの終了後に一度切断し、ルーティングとDNSの状態が復元されたことを確認する。
- ❌ 異なる端末、異なる無線信号強度、異なる測定サーバーの結果を直接比較しない。
ツールの選び方：ウェブ測定とコマンドライン測定の見方
ウェブ速度測定ツールは、ダウンロード、アップロード、遅延を手早く確認するのに適しています。操作が簡単で、普段のブラウザー環境に近い点も利点です。一方、測定ノードは通常プラットフォームが自動選択するため、ブラウザーのタブ、拡張機能、描画負荷、接続の再利用方式が結果に影響することがあります。ウェブツールを使う際は、測定サーバーの場所を手動で確認し、一方の回線だけ近隣サーバー、もう一方だけ遠隔サーバーを測定する状況を避けてください。
コマンドラインツールは、経路の継続的な接続状態を確認するのに適しています。システム標準の接続テストでは往復時間とパケットロスを確認でき、トレースルートではデータパケットが通過するネットワークノードを確認できます。ただし、中間ノードがプローブに応答しないことは、実際の通信が途切れていることを意味しません。通信事業者がプローブパケットを制限したり、経路上の機器がその処理優先度を下げたりする場合があります。そのため、特定のホップが応答しないだけで回線障害と判断することはできません。
固定のテストファイルをダウンロードすると、ウェブ速度測定の結果を補足できます。長時間の転送中に速度が低下する現象を確認しやすい一方、ファイルを置いているサーバー自体が速度制限を行っている可能性もあります。より確実な方法は、実際のアクセス先に近いサーバーを選び、すべての候補回線で測定対象を統一することです。リアルタイム通話やゲームを利用する場合は、実際のアプリでも確認してください。アプリの通信方式、分流ルール、接続先ネットワークは、速度測定サイトとは大きく異なる場合があります。
| 測定方法 | 主な確認項目 | 判断に適した内容 | 生じやすい誤差 |
|---|---|---|---|
| ウェブ速度測定 | ダウンロード、アップロード、応答遅延 | ブラウザー環境での総合スループット | 異なる測定ノードが自動選択される |
| 継続的な接続テスト | 往復時間、ジッター、パケットロス | 操作時の安定性と短時間の変動 | プローブパケットが制限または低優先度で処理される |
| トレースルート | 経路の変化、異常な迂回 | 接続側と遠隔経路の問題を特定する | 中間ノードの無応答を切断と誤認する |
| 固定ファイルの転送 | 継続的なスループット、速度低下 | ダウンロードと大容量ファイルの転送能力 | 配信元の速度制限やキャッシュヒット状況が異なる |
| 実際のアプリでの検証 | 読み込み、通話、リモート操作の体感 | 目的のサービスが実際に利用できるか | アプリが測定対象の回線ではなく直接接続を使っている |
ピーク時と深夜に分けて実測する
ネットワーク経路の負荷は時間帯によって変化します。深夜の結果は通常、低負荷時の状態に近く、混雑が少ないときの回線性能を確認できます。ピーク時は日常的な負荷環境に近く、通信事業者間の接続、共有出口、中継経路の変動が表れやすくなります。低負荷の時間帯だけ測定すると日常の体感を過大評価しやすく、混雑時だけ測定すると一時的な局所障害を回線の長期的な状態と誤認する可能性があります。
各時間帯で同じ手順を使います。まずローカルのベースラインを測定し、次に候補回線へ接続します。遅延、ジッター、パケットロスを先に記録し、その後ダウンロードとアップロードを測定し、最後に実際の対象アプリを開きます。候補回線が多い場合は測定順を入れ替え、特定の回線が常に最初または最後にならないようにします。測定中にローカルのベースラインが急に悪化した場合は、そのラウンドを中断し、比較できないデータを集め続けないでください。
- ベースラインを確立：回線を切断し、ローカルネットワークで継続的なパケットロスや明らかな変動がないことを確認する。
- 対象を固定：同じ測定サーバー、同じファイル配信元、同じアプリ利用シーンを選ぶ。
- 1回線ずつ接続：回線、プロトコル、接続モード、分流が有効かどうかを記録する。
- 繰り返し確認：最良の1回だけを残さず、複数回の結果がどの程度集中しているかを見る。
- 時間帯をまたいで再確認：深夜とピーク時の記録を分け、ピーク値だけでなく安定性の変化を比較する。
速度測定記録の価値は、再現性にあります。他の人が再現できないピーク値のスクリーンショットは、ある端末がある瞬間にその結果を得たことしか示しません。長期的な回線性能を表すものではありません。
遅延、ジッター、パケットロス、帯域幅の読み解き方
遅延は操作への応答を左右し、ダウンロード速度とは異なる
遅延とはデータの往復に必要な時間で、物理的な距離、経路の迂回、接続ネットワーク、処理キューの影響を受けます。ウェブページの初期表示、リモートデスクトップ、端末操作、ゲームの操作入力はいずれも遅延に敏感です。帯域幅の大きい回線でも、経路が長ければ操作への応答が遅くなることがあります。したがって、ダウンロード速度で遅延を判断してはいけません。
ジッターは遅延の安定性を示す
ジッターとは、連続するリクエスト間で生じる遅延の変化です。平均遅延が正常に見えても、一部のリクエストだけ急に遅くなると、音声が途切れたり、ゲーム操作が一瞬止まったりします。リアルタイムアプリでは、たまに低遅延になることより、安定して予測しやすい応答のほうが重要です。記録時は平均値だけを書き留めず、結果の分布も確認してください。
パケットロスは再送と通信速度の低下を引き起こす
パケットロスは、無線干渉、接続側の混雑、ネットワーク間の接続、遠隔サーバーの制限などによって発生します。信頼性のある通信では失われたデータを再送するため、継続的なパケットロスは実効スループットを低下させます。リアルタイム通信では再送を待たない場合があり、映像の乱れや音声の欠落として現れることがあります。一時的なプローブのタイムアウトも、実際の通信状況と合わせて判断する必要があり、文脈を無視して断定してはいけません。
ダウンロードとアップロードは用途に合わせて見る
ダウンロードのスループットはウェブ素材、動画、ファイルの取得に影響し、アップロードのスループットはクラウドバックアップ、ビデオ会議の上り通信、ファイル送信に影響します。速度測定ツールが示すのは、特定サーバーとの測定接続における結果であり、他のウェブサイトで同じ速度が出ることを保証しません。配信元の容量、コンテンツの配信場所、同時接続数、ローカル端末の性能がボトルネックになる場合もあります。
プロトコルと回線タイプで結果が変わる理由
プロトコルのオーバーヘッドは速度測定に影響する要素の一つにすぎず、実際の経路のほうが重要な場合も多くあります。Shadowsocks、VMess、Trojan、VLESSはプロキシクライアントのエコシステムでよく使われますが、性能はトランスポート層の設定、暗号化の実装、クライアントのコア、サーバー負荷によって変わります。Trojanは通常TLS接続上で動作し、VMessとVLESSはさまざまなトランスポート方式と組み合わせられます。プロトコル名だけで、どれが必ず速いかを決めつけることはできません。
Hysteria2とTUICはQUICを基盤とし、複雑なネットワーク環境での通信制御を重視しています。ただし、通信事業者によるUDPトラフィックの扱い、ローカルネットワークのパケットロス、クライアントの実装にも左右されます。あるネットワークで安定した設定が、別の接続環境でも有利とは限りません。プロトコルを比較する際は、サーバーの場所、回線経路、測定対象を統一する必要があります。そうしなければ、複数の変数が重なった結果を測ることになります。
直接接続の回線は通常、利用者のネットワークから遠隔ノードへ直接接続するため経路が単純ですが、ネットワーク間の品質はローカル通信事業者の国際出口に左右されます。中継回線は近い接続拠点に入ってから目的の出口へ転送するため、一部の通信事業者で経路を改善できる一方、中間リンクが増えます。IEPL専用線は接続拠点間の専用伝送リソースを重視し、一般的な公衆ネットワーク中継とは経路方式が異なります。ただし、利用者から入口まで、出口から対象サイトまでの両端も最終的な体感に影響します。
DNS、分流、クライアントの違いを切り分ける
測定ページの表示が速くても、すべてのアプリが同じ回線を使っているとは限りません。分流を有効にすると、測定サイトはプロキシルールに一致しても、実際のアプリは直接接続ルールに一致することがあります。逆のケースもあります。測定前にクライアントの接続ログやセッション一覧を確認し、測定ドメインと対象アプリの通信が実際に候補回線を通っていることを確認してください。
DNSの解決経路も測定対象を変える可能性があります。ローカルDNSでドメインを解決すると、ローカルネットワークに近いサーバーが返される場合があります。回線側のDNSで解決すると、出口に近い結果になることがあります。2つの回線でDNSポリシーが異なれば、実際にアクセスするサーバーも変わる可能性があります。DNS漏洩を確認する目的は、解決リクエストが想定した経路で送信されているかを確かめることであり、特定の解決サービス名だけを見て安全・危険を自動的に判断することではありません。
プラットフォームごとにクライアントの実装にも違いがあります。デスクトップOSでは仮想ネットワークアダプターが通信を引き受ける場合もあれば、システムプロキシだけを設定する場合もあります。モバイルOSでは通常、システムが提供するVPNインターフェースを通じて通信を転送します。ブラウザー拡張機能が影響するのはブラウザー内のリクエストだけで、他のアプリを代表するものではありません。クライアントのグローバルモード、ルールモード、LANバイパス、内蔵DNSの設定も、測定範囲を変えます。
サブスクリプションリンクをクライアントに取り込んだ後、ノード名が同じでもローカル設定が完全に一致するとは限りません。クライアントのコアが異なれば、接続の多重化、DNS処理、ルーティングルールも異なる場合があります。プラットフォームをまたいで比較する際は、プロトコル、サーバー、ポート、トランスポートパラメータ、分流ポリシーが一致していることを確認してから、OS自体の違いを検討してください。
- ✅ 測定ドメインがクライアントの接続記録に表示されているか確認する。
- ✅ 異なる測定ラウンド間でグローバルモードとルールモードを切り替えていないことを確認する。
- ✅ 同じDNSポリシーを使い、解決結果が同じ対象地域に対応していることを確認する。
- ✅ プラットフォームをまたいで測定する場合は、プロトコル、ノード、トランスポート設定、クライアントのコアを照合する。
- ❌ ブラウザー拡張機能の結果を、端末全体の回線性能とみなさない。
- ❌ サブスクリプションや分流ルールを変更した後、古いキャッシュを使ったまま比較しない。
結論を誤らせやすい速度測定のミス
最速の結果だけを残す。ピーク値は回線が一時的にその状態へ到達したことを示しますが、繰り返し使ったときの安定性は表しません。各ラウンドのデータを残し、異常発生時にローカルのベースラインも変化していなかったかを記録するほうが適切です。
サーバー選択をツールに任せる。自動選択されたノードは出口の位置に応じて変わることがあります。回線を切り替えると測定対象も変わるため、結果を直接比較できなくなります。同じサーバーを固定するか、少なくとも同じ地域と同じサービス提供元にそろえてください。
回線がキューに入るまで連続測定する。大容量の測定では接続帯域を使い切り、後続の遅延測定がキュー待ちの状態になります。まずアイドル状態の回線で遅延を記録し、その後にスループットを測定してください。負荷時の応答を確認する場合は、負荷テストとして別に記録します。
端末性能を無視する。暗号化、復号、仮想ネットワークアダプターによる転送、ブラウザーの描画はいずれも処理リソースを消費します。低消費電力の端末や省電力状態の端末では、先に端末側のボトルネックへ達することがあります。その場合、回線を変えても結果が改善するとは限らないため、システムリソースの使用状況も確認してください。
一度の異常をサーバー側の原因と決めつける。ローカルの無線干渉、通信事業者による一時的な経路変更、配信元の速度制限、クライアントルールの誤りも異常の原因になります。まず未接続状態のベースラインを再測定し、次に測定対象と接続方式を変えて確認するほうが、いきなりプロトコルを変更するより問題を特定しやすいことがあります。
再確認できる測定結果のまとめ方
測定後、すべてのデータを単一のランキングにまとめる必要はありません。用途別に、操作系アプリでは応答の安定性、リアルタイム系アプリではジッターとパケットロス、転送系の作業では継続的なダウンロードとアップロードを記録できます。深夜とピーク時は異なる負荷条件を表すため、結論を分けて残してください。
記録には少なくとも、日付、時間帯、ローカルネットワーク、端末、クライアント、プロトコル、回線、分流モード、DNSポリシー、測定対象を記載します。異常があった場合は、ベースラインの状態と再測定結果も添えてください。このような記録は回線選びに役立つだけでなく、テクニカルサポートへ問い合わせる際の環境確認の往復も減らせます。
2つの回線の結果が近い場合は、偶発的なピーク値を追うのではなく、繰り返し測定でより安定し、実際のアプリの経路が明確なほうを優先してください。回線はネットワーク環境によって変化するため、一度の測定ランキングを保存し続けるより、同じ手順で定期的に再確認するほうが参考になります。