VPN速度の実測では、測定ページに表示される下り速度の最大値だけを見てはいけません。閲覧、会議、ファイル転送、ストリーミングの快適さを左右するのは、帯域が安定して続くか、遅延が安定しているか、ジッターやパケットロスを抑えられているか、そして夜間ピークに回線が大きく劣化しないかです。測定前に端末、接続ネットワーク、対象ノード、ツールを固定し、同じ条件でVPN未接続時の基準値と接続後の結果を比較してこそ、意味のある判断ができます。
宣伝ページでは実験環境での最大性能が示されがちですが、実際の通信には家庭のブロードバンド、無線信号、国内の通信事業者、国際経路、接続先サービスが関わります。ある時点で良い結果が出ても、その瞬間に一度通信できたことを示すだけで、別の時間帯や別のWebサイト、長時間の接続まで安定している証明にはなりません。以下では、特定ブランドの測定スクリーンショットに頼らず、繰り返し実行できる確認手順を紹介します。
まずVPN未接続時の基準値を取る
速度測定はノード選びから始めるのではなく、まずローカルネットワークが正常かを確認します。プロキシやトンネルを切断し、実際に使う同じ端末で基準値を測定してください。ネットワーク環境はできるだけ固定し、基準値の測定だけ有線、ノード測定では無線という切り替えは避けます。バックグラウンド同期、システム更新、クラウドストレージへのアップロード、他の端末での大容量転送も帯域を消費するため、先に停止します。
基準値では少なくとも下り、上り、遅延、ジッター、パケットロスを確認します。下りは大容量ファイルや動画データを受信する能力、上りはビデオ会議やファイル送信、リモートバックアップに影響します。遅延はデータの往復にかかる時間、ジッターは連続した往復時間のばらつき、パケットロスは再送やリアルタイムアプリの欠落につながるデータ損失を示します。
| 確認項目 | 主な影響 | よくある誤解 | 測定のポイント |
|---|---|---|---|
| 下り | Webリソース、動画のバッファリング、ファイル取得 | 瞬間的な最大値を持続性能とみなす | 速度の推移が安定して維持されるかを見る |
| 上り | 会議映像、ファイル送信、リモートバックアップ | 下りだけ測って回線速度を判断する | 上り中に遅延が急増しないか確認する |
| 遅延 | 操作への応答、リモートデスクトップ、ページの初回表示 | 距離が近ければ必ず安定すると考える | アイドル時と通信負荷時の変化を比較する |
| ジッター | 音声の連続性、ゲーム操作、会議の安定性 | 平均遅延だけを見て変動を無視する | 連続サンプルが大きく上下していないか確認する |
| パケットロス | リアルタイム音声・映像、長時間接続、データ再送 | 速度測定が完了すれば問題ないと考える | 継続的なリクエストと実際のアプリで確認する |
基準値は最高値だけを覚えておくのではなく、元の記録を残してください。直結時から変動しているなら、VPN接続後に同様の変動が出ても、すぐにノードのせいとは言えません。逆に基準値が安定しているのにトンネル接続後だけ不安定な状態が続くなら、ノードの負荷、入口経路、プロトコル設定、クライアントの動作を詳しく確認します。
速度測定ツールの選び方：スループット、経路、実アプリを分けて測る
1つのツールだけで回線を完全に評価することはできません。ブラウザーの速度測定サイトは下り・上りのスループットと基本的な遅延の確認に向いています。標準の ping は連続した往復時間とパケットロス、traceroute や tracert は経路の変化、dig と nslookup はDNS解決の確認に使えます。実際のダウンロード、動画再生、会議ではアプリケーション層の体感を検証します。
ブラウザーで速度を測る場合、測定サーバーの選択が結果に大きく影響します。出口に近いサーバーを選ぶと、通常はノードの出口性能に近い結果になります。実際のサービスがある地域のサーバーを選べば、対象サービスまでの完全な経路に近づきます。両者は目的が異なります。前者だけでは最終的な体感を過大評価しやすく、後者だけでは対象サービス側の混雑をVPN性能と誤認する可能性があります。
コマンドラインツールも正しく読み解く必要があります。連続したリクエストで途中のルーターが応答しなくても、最終目的地でパケットロスが起きているとは限りません。一部のネットワーク機器は診断パケットの処理優先度を下げながら、通常の通信は転送しています。最終目的地に安定して到達できているかを確認し、経路情報は切り分けの手がかりとして扱います。特定の1ホップの異常だけで結論を出してはいけません。
- ✅ 同じ端末、同じ接続方式、同じクライアント設定を使う。
- ✅ 同じ測定では対象サーバーを固定し、サーバーの変更による比較への影響を避ける。
- ✅ 下り、上り、遅延、ジッター、パケットロスを記録し、最大値だけを残さない。
- ✅ 実際のWeb閲覧、ファイル転送、会議、ストリーミングもテストに含める。
- ❌ 短時間の測定で出た瞬間的な最高値を、回線の長期性能とみなさない。
- ❌ バックグラウンド通信が混雑しているときの結果を、そのままVPNのせいにしない。
日常の時間帯と夜間ピークを必ずカバーする理由
国際回線の性能は時間帯によって変化します。国内通信事業者の出口、国際リンク、中継入口、ノードの出口、対象サービスのいずれでも混雑が起こり得ます。昼間の空いている時間に滑らかな結果が出ても、夜に利用が集中したときの状態を示すとは限りません。測定はネットワークが最も空いている時間を選ぶのではなく、実際に使う時間帯をカバーしてください。
無目的に大量のサンプルを集める必要はありませんが、方法は統一してください。平日の通常利用時間、夜間ピーク、比較的空いている時間帯に同じ手順を実行し、繰り返し確認します。記録では最も良かった1回だけでなく、中央値の傾向、最も悪い体感、速度が頻繁に急落するかを見ます。リアルタイムアプリでは、偶然出た最大値より安定性が重要です。
- 環境を固定：帯域を消費するタスクを停止し、ローカル接続が同じ状態であることを確認する。
- 基準値を記録：VPNを切断し、同じ対象を測定して全指標を保存する。
- ノードに接続：測定対象を変えず、スループットと連続リクエストを測定する。
- 負荷をかける：下りまたは上りの通信中に、遅延が大きく増えないか確認する。
- アプリで検証：実際に使うWebサイト、会議、リモートデスクトップ、動画サービスを開く。
- 時間帯を変える：通常の利用時間と夜間ピークに同じ手順を繰り返す。
- 回線を変える：一度に変更するのはノードまたはプロトコルのどちらか1つにし、複数の条件を同時に変えない。
「夜間ピークの推移を読み解く」とは、完全に水平な線を探すことではなく、劣化のパターンを見つけることです。下りの曲線が徐々に下がり、同時に遅延とジッターが上昇するなら、経路が混雑に近づいている可能性があります。スループットは保たれているのにページが時々止まる場合は、パケットロス、DNS解決、接続の再確立を確認します。特定のサービスだけ遅く、他の対象が正常なら、出口からそのサービスまでの区間に問題がある可能性があります。
最大値より再現性が重要です。同じ条件で繰り返し現れる結果こそノード比較に使えます。再現できない単発の高い値は、偶然のサンプルとして扱うのが適切です。
下りが速いのに止まる：遅延・ジッター・パケットロスの読み方
帯域は回線が一度に運べるデータ量、遅延は1回のやり取りで待つ時間であり、同じ概念ではありません。大容量ファイルのダウンロードは複数の接続で帯域を使い切れるため、遅延がやや大きくても速度が良く見えることがあります。一方、ページの初回表示、リモート端末、ゲーム、会議は頻繁なやり取りに依存するため、遅延とジッターの影響を受けやすくなります。
負荷時の遅延にも注目してください。アイドル時に遅延が安定していても、データ転送中に素早く応答できるとは限りません。アップロードを始めた途端に他のリクエストが明らかに遅くなるなら、ローカルルーター、接続回線、トンネルのキューで待ち行列が発生している可能性があります。この場合、アップロード完了後の速度だけを見ていると、利用中の操作の引っかかりを見落とします。
ジッターは、連続する応答時間が均一でない状態です。音声・動画クライアントはバッファーで一部の変動を吸収できますが、変動が拡大し続けるとバッファーが遅延を増やし、音声の途切れや映像の追いつきが起こります。パケットロスの影響は転送方式にも左右されます。信頼性のある転送では再送によって速度低下や待ち時間が生じ、リアルタイム転送では再送が間に合わず、一時的な映像の欠落や音声の断片化として現れることがあります。
そのため、用途ごとに重視する点を変える必要があります。ダウンロードやストリーミングでは持続スループットと速度曲線の下限、会議では下り・上り、ジッター、パケットロス、リモートデスクトップでは遅延・ジッターと負荷時の応答、Web閲覧ではDNS、接続確立、リソース取得を確認します。すべての用途を代替できる「総合点」はありません。
プロトコルと回線種別で結果が変わる理由
プロトコルにはカプセル化、暗号化、輻輳制御、トランスポート層の違いがありますが、ネットワーク環境を無視して速度を固定的に順位付けすることはできません。Shadowsocks は比較的シンプルな構成で、実際の性能は暗号方式、クライアント実装、サーバー資源に左右されます。VMess と VLESS は異なるトランスポート層と組み合わせてクライアントで使われることが多く、VLESS自体はコンテンツの暗号化を担当しないため、通常はTLSなどの安全なトランスポートと組み合わせます。Trojan はTLSに近い形で通信しますが、ハンドシェイク、証明書設定、基盤ネットワークの影響も受けます。
Hysteria2 と TUIC はUDPやQUICの考え方に基づくトランスポート機構を採用しており、高遅延または一定のパケットロスがある経路では、従来のTCPトンネルとは異なる回復特性を示す場合があります。ただし、ローカルネットワークがUDPを制限していたり、経路上のUDP品質が低かったりすると、安定したTCP方式に及ばないこともあります。プロトコル名だけで速度は保証されません。同じノード、同じ出口、同じ対象で比較してください。
回線種別も重要です。直結は通常、端末が公開ネットワーク上のノードへ直接接続する方式で、経路はシンプルですが、品質は国内通信事業者からノードまでの公衆網ルートに依存します。中継では近い入口に接続してから、通信事業者が用意した中間回線を経て出口へ向かいます。一部の国際経路を改善できる一方、入口と中継区間の管理が必要になります。IEPL 専線は重要な国際区間をより制御しやすい専用回線に置き、公衆網の混雑による変動を抑えることを目指しますが、実際の体感はローカル接続、入口品質、出口、対象サービスにも左右されます。
| 回線またはプロトコルの要素 | 改善が期待できる部分 | 実測が必要な部分 |
|---|---|---|
| 直結回線 | 経路構成が比較的シンプル | 国内通信事業者の公衆網ルートと夜間ピークの変動 |
| 中継回線 | 入口の選択と国際経路をより制御しやすい可能性 | 入口の混雑、中継区間の容量、出口の品質 |
| IEPL 専線 | 重要な国際区間で公衆インターネット経路への依存を軽減 | ローカル接続と出口から対象サービスまでの最終経路 |
| TCP系トランスポート | TCPを安定して利用できるネットワークでは互換性が比較的高い | 高遅延、パケットロス、重複する輻輳制御の影響 |
| UDPベースのトランスポート | 異なる輻輳制御やパケットロス回復方式を利用できる | ローカルネットワークによるUDP制限と実際の経路品質 |
プロトコルを比較するときは、一度に変更するのをプロトコル設定だけにします。ノード、出口地域、測定サーバーを同時に変えると、結果が変化しても原因を特定できません。クライアントのコアバージョンも性能に影響するため、測定時にはプラットフォーム、クライアント、プロトコル種別を記録してください。ただし、異なるプラットフォームの結果を同じ集計に直接混ぜてはいけません。
サブスクリプションのインポート、クライアント差、分割トンネルのルール
サブスクリプションリンクは通常、ノードと設定をクライアントへ更新する入口を提供します。インポート後、クライアントは対応状況に応じて Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC などの設定を解析します。インポートに成功したことは設定を読み取れるという意味に過ぎず、すべてのノードの速度検証が済んだことや、クライアントが自動選択したノードが現在のネットワークに適していることを示すものではありません。
プラットフォームごとに、クライアントのネットワークスタック、権限モデル、システムプロキシ、仮想NICの実装は異なります。デスクトップクライアントにはシステムプロキシと仮想NICモードが用意されている場合があり、前者は主にシステムプロキシに従うアプリを制御し、後者はより多くの通信をカバーできることがあります。モバイルOSではバックグラウンド処理、省電力設定、ネットワーク切り替えの影響も受けます。同じサブスクリプションでプラットフォームごとの差が出たら、まず制御モード、プロトコル対応、ルールが一致しているか確認します。
分割トンネルのルールは、速度測定を特に簡単に歪めます。測定サイトがルールによって直結と判定されているなら、表示されるのはローカルブロードバンドの速度であり、VPNノードの速度ではありません。測定通信がプロキシを経由していても、DNSリクエストがローカルで処理されていれば、地域ごとの名前解決の違いが結果に影響する可能性があります。測定前にクライアントの接続ログやアクティブ接続一覧を確認し、測定ドメインと通信の実際の経路を確かめてください。
DNSリークとは、トンネルまたは指定したリゾルバーで処理されるはずのDNSリクエストが、ローカルネットワークの名前解決経路へ送信されることです。主にプライバシーと名前解決経路の問題であり、対象サービスが現在の出口に適さないアドレスを返す原因にもなります。DNS自体は通常、大容量ファイルの持続スループットを決めませんが、ドメイン解決、ページの初回表示、接続先アドレスの選択に影響します。そのため帯域測定とは分けて確認してください。
- ✅ 測定ドメインが分割トンネルのルール上、実際にテスト対象ノードを経由していることを確認する。
- ✅ クライアントのアクティブ接続またはログで出口の選択を確認する。
- ✅ DNSリクエストが想定どおりトンネルまたは指定の名前解決経路に入っているか確認する。
- ✅ システムプロキシと仮想NICモードを比較するときは、他の条件を固定する。
- ❌ サブスクリプションのインポート成功を、回線の品質検証完了と同じ意味にしない。
- ❌ 分割トンネルを有効にした結果と、全通信を制御した結果をそのまま横並びで比較しない。
結果を実用的な回線選びの判断にまとめる方法
測定後は、下りの最大値だけで順位を付けないでください。より実用的なのは、用途ごとにノード地域、回線種別、プロトコル、測定時間帯、測定対象、下り・上りの傾向、遅延の変動、パケットロス、DNS経路、実アプリでの体感を記録する方法です。条件を明確に記録しておけば、再測定の際に回線自体が変化したのか、ローカル環境が変わったのかを見分けやすくなります。
回線を選ぶときは、まず明らかに不安定な結果を除外し、残ったノードで持続性能を比較します。最大値は目立つものの頻繁に急落する回線は、長時間の動画視聴やファイル転送に向かない可能性があります。一方、最大値は普通でも曲線が安定し、操作時の遅延変化が小さい回線のほうが、実際には快適なことがあります。会議やリモートワークでは、偶発的な高い値より予測しやすさのほうが参考になります。
ノードの問題と対象サービスの問題も分けて考える必要があります。複数の測定対象やアプリが同時に劣化するなら、ノードまたは上流経路を詳しく確認します。特定のWebサイトだけ異常なら、そのサイトの地域別ルーティング、出口との接続、アクセス方針が原因かもしれません。すべてのノードが遅く、直結時の基準値も同時に低下しているなら、まずローカルネットワークを確認し、根本原因を隠すためにプロトコルを頻繁に変えないでください。
信頼できるVPN速度測定の本質は、変数を管理することです。環境を固定し、直結時の基準値を取り、実際の利用時間帯をカバーし、スループット、連続リクエスト、経路、アプリのテストを組み合わせたうえで、ノードまたはプロトコルを1項目ずつ変えます。そうして得られるのは見栄えの良いスクリーンショットではなく、回線選び、トラブルシューティング、再測定に役立つ記録です。