VPN速度実測の方法：自分で測るツール・時間帯・確認すべき指標

VPN速度実測で重要なのは、最高ダウンロード速度を出すことではなく、速度低下がどの区間で起きているかを見極めることです。国際接続は、国内のアクセス回線、通信事業者の出口、サービス回線、接続先サイト、復路を通ります。どこか一つが変わるだけでも、同じノードの結果は時間帯によって大きく変わります。そのため再現性のある測定には、環境を固定し、直通接続の基準値を残したうえで、混雑時と深夜の結果を分けて記録する必要があります。

測定ページを開き、帯域幅の数値を見ただけで結論を出すと、国内の無線干渉、接続先サーバーの混雑、クライアントの分流設定ミスを回線の問題と誤認しがちです。まず、サービス未接続時の国内ネットワークの状態、接続後に明確に変化した指標、その変化を同じ条件で再現できるかの3点を確認しましょう。

測定前に再現可能な直通接続の基準値を取る

直通接続の基準値とは、プロキシやトンネルを有効にしていない状態で、国内ネットワークから測定対象まで接続したときの結果です。回線による低下を判断するための基準になります。直通接続ですでにジッターが大きい、継続的なパケットロスがある、帯域幅が大きく変動するといった状態なら、国際回線に接続した後は問題がさらに目立つだけです。この場合、ノードを頻繁に変えても国内のアクセス品質は改善しません。

基準値を取る前に、ダウンロード、クラウド同期、システム更新、動画再生などネットワークを使う処理を停止し、ほかの端末が大容量ファイルを継続的に送受信していないことを確認します。無線ネットワークを使う場合は、測定場所、周波数帯、電波環境もそろえます。可能なら有線接続でも確認し、無線干渉と回線の問題を切り分けます。測定中に有線と無線を切り替えると、記録の比較性が失われます。

• ✅ 実行中の大容量ファイル転送とクラウド同期を停止する
• ✅ 同じネットワーク、同じ端末、同じ測定場所に固定する
• ✅ 先に直通接続の状態を記録し、その後で測定対象ノードに接続する
• ✅ 対象地域と測定ツールを固定し、自動選択による経路変更を避ける
• ✅ クライアント、プロトコル、ノード、分流モードを記録する

OSにほかのネットワークツールが残っていないかも確認します。複数のクライアントが同時にシステムプロキシ、仮想ネットワークアダプター、DNSを制御すると、通信が意図しない経路に入る可能性があります。不要なクライアントを終了し、システムプロキシを元に戻してから、測定対象のアプリだけを起動するのが簡単です。ブラウザー拡張機能がブラウザーの通信だけをプロキシ経由にする場合もあり、ウェブ測定とほかのアプリの実際の経路が一致しないことがあります。

測定ツールはウェブ、経路、実際のダウンロードをカバーする

ツールによって観測できる層は異なります。ウェブ測定は遅延やスループットを手早く確認するのに向いていますが、測っているのは端末から選択した測定サーバーまでの経路であり、すべての国際サイトを代表するものではありません。経路調査ツールはジッター、パケットロス、ルートの変化を見つけるのに適しています。実際のファイル転送や普段使うサービスの読み込みは、現実の利用感に近い情報になります。これらを組み合わせて判断するほうが、単一のウェブ測定値に頼るより確実です。

ウェブ速度測定では、測定サーバーの所在地域を手動で固定します。香港ノードを測るのにツールが国内サーバーを自動選択すると、通信経路は国際サイトへのアクセスと大きく異なる可能性があります。2つのノードを比較する場合、測定対象も同じにしてください。対象が変わると、差は測定サーバーの容量、相互接続、地理的位置に起因する可能性があり、測定対象ノードの違いとは限りません。

経路調査では、途中の特定ホップが応答しないことだけを見てはいけません。経路機器によっては調査パケットの優先度を下げながら、実際の通信データは正常に転送します。後続ホップと最終目的地に同じ異常が現れ、さらにウェブ表示やファイル転送にも遅延がある場合に限り、実際のパケットロスを疑う根拠が強くなります。

混雑時と深夜を分けて測定する理由

国際経路の負荷は時間帯によって変わります。混雑時は国内アクセス回線の混雑、通信事業者の出口負荷、サービスノードの負荷が重なりやすく、深夜は低負荷に近い条件になります。両方の結果を並べることで、回線の理想的な能力と繁忙時間帯の安定性を切り分けられます。深夜だけ高い帯域幅が出ても、混雑時も同じ性能が続くとは限りません。逆に混雑時だけ測ると、回線本来の能力を低く見積もる可能性があります。

各時間帯で、まず直通接続を測り、次に同じノードを測定します。ツール、測定サーバー、プロトコルも変えません。1回の測定には一時的な待ち行列、バックグラウンド通信、接続先サーバーの変動が影響するため、連続して複数回行い、結果が集中するかを確認します。最高値だけを残すのは避けてください。ほかと大きく異なる結果には、ノード切り替え、ネットワーク再接続、クライアント更新の有無を注記します。

測定日は重要です。国際ルートはメンテナンス、障害による迂回、通信事業者の方針によって変わることがあります。ある日の異常を長期的な性能と判断することも、1回の快適な結果を継続的な観察の代わりにすることもできません。役立つ記録には、どのネットワーク、どの時間帯、どのノード、どのプロトコルで得た結果かを明記します。

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

遅延は応答を待つ時間であり、ダウンロード速度とは異なる

遅延は通常、データが往復するのにかかる時間を示します。ウェブのクリック、リモートデスクトップ、オンライン会議、インタラクティブなアプリは遅延の影響を受けやすく、大容量ファイルのダウンロードは継続的な帯域幅に左右されます。国際回線では物理的な距離や経路の迂回により、遅延が国内接続より高くなるのが自然です。同じ対象に対する異なる回線の結果を比較し、国際ノードと国内サーバーを同じ基準で評価しないようにします。

遅延の急増は、経路の迂回、ノード負荷、無線再送、国内回線の上り帯域の占有などが原因かもしれません。直通接続と接続後の両方で上昇するなら、まず国内ネットワークを確認します。特定ノードだけが上昇する場合は、同じ地域の別回線や異なるプロトコルと比較します。

ジッターは遅延の安定性を示す

ジッターとは、時間の経過に伴う遅延の変動幅です。平均遅延が正常に見えても、応答が速くなったり遅くなったりすると、音声、ビデオ会議、リアルタイム操作で停止や途切れが起きることがあります。ジッターは待ち行列、無線干渉、回線混雑、パケット再送と関係することが多いため、測定では平均値だけでなく、連続した結果の分布を確認します。

パケットロスは最終目的地と合わせて判断する

パケットロスが起きると再送が発生し、速度が低下して待ち時間が増えます。継続的なパケットロスは、単に遅延が高い場合より安定性に大きく影響します。ただし、途中の経路機器が調査要求に応答しないことは、実際の通信データが破棄されたことを意味しません。最終目的地でも同時にロスが起きているかを確認し、ウェブ表示、実際のダウンロード、リアルタイム接続に異常があるかと合わせて判断します。

帯域幅は継続性と上下方向を確認する

ダウンロード帯域幅はファイル取得や動画のバッファリングに影響し、アップロード帯域幅はクラウドバックアップ、ファイル送信、リアルタイム会議に影響します。短時間だけ速度が跳ね上がってすぐに低下する場合、瞬間的な容量はあるものの、継続的な転送能力が限られている可能性があります。速度の立ち上がりが遅い場合は、輻輳制御、遠隔サーバー、高遅延経路が原因かもしれません。ピーク値だけを記録すると、この過程を見落とします。

国内ブロードバンドの公称速度を、国際回線が必ず達成すべき値と考えないことも重要です。暗号化、カプセル化、距離、ノードの出口、接続先サーバーによってオーバーヘッドが発生します。比較するなら、接続前後の相対的な変化、混雑時の安定性、実際のアプリが必要とする性能を見るほうが有意義です。

プロトコルと回線タイプが結果に与える影響

一般的なサブスクリプションサービスでは、Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどが提供されることがあります。カプセル化方式、トランスポート層の選択、輻輳制御が異なるため、同じネットワークでも結果は変わります。プロトコル名だけで速度を判断することはできません。クライアントの実装、サーバー設定、経路上のパケットロス、通信事業者による通信処理も結果に影響します。

Shadowsocksは比較的シンプルな構成で、汎用プロキシに使われます。VMessとVLESSは柔軟なトランスポート設定に対応するクライアントでよく使われ、実際の性能は下位トランスポートと設定に左右されます。Trojanは通常TLSを利用して通信します。Hysteria2とTUICはQUICの考え方を基盤としており、ジッターやパケットロスのあるネットワークでは従来のTCP経路と異なる復旧特性を示す場合がありますが、UDPの到達性、クライアント実装、ネットワーク方針の影響も受けます。プロトコル名だけを変え、ノードやトランスポート設定まで同時に変わっている状態で比較してはいけません。

回線タイプも分けて記録します。直通ノードは国内の通信事業者から接続先サーバーへ直接向かうため構成がシンプルですが、混雑時は公衆ネットワークのルート変動の影響を受けやすい場合があります。中継回線は入口ノードを経由してサービス事業者のネットワークから出口へ向かいます。入口と出口の組み合わせを調整しやすい一方、中継区間そのものが経路を増やします。IEPL専線は管理された国際伝送区間を用いる点が特徴で、通常の公衆ネットワーク直通や中継とは経路の構成が異なります。実際の利用感は、国内アクセス、入口の品質、出口容量、接続先との相互接続に左右されます。

プロトコルを比較するときはノードと回線タイプを固定し、プロトコルまたは対応する設定だけを変えます。ノードを比較するときはクライアント、プロトコル、測定対象を固定します。クライアント、プロトコル、ノード、測定サーバーを一度に変えると、結果が違ってもどの変更が原因か判断できません。

クライアント、サブスクリプションのインポート、OSの違いも確認する

サブスクリプションリンクには通常、ノード一覧とプロトコル設定が含まれます。インポート後、クライアントは対応機能に応じてノードを解析しますが、トランスポート設定、仮想ネットワークアダプター、システムプロキシ、DNS、分流ルールの実装はクライアントごとに完全には同じではありません。同じサブスクリプションでも、Windows、macOS、Android、Linuxで差が出る場合、ノードが変わったとは限らず、クライアントの動作モードが原因の可能性もあります。

システムプロキシモードは通常、プロキシ設定に従うアプリだけを制御します。仮想ネットワークアダプターモードはより多くの通信を対象にできますが、ルーティングとDNS設定が複雑になります。ブラウザーの測定は正常なのにほかのアプリが通信できない場合、そのアプリがシステムプロキシを迂回していないか確認します。逆に、仮想ネットワークアダプターを有効にしてすべての通信が遅くなった場合は、ルート競合、二重制御、不要な全体転送がないか確認します。

1. サブスクリプションを更新し、測定対象ノードが現在の一覧に残っていることを確認する。
2. クライアント名、動作モード、選択したプロトコルを記録する。
3. ノードの自動選択を無効にし、今回の測定対象を固定する。
4. 分流ルールによって測定対象が回線を迂回していないことを確認する。
5. 先に直通接続を測定し、その後ノードに接続して同じ項目を繰り返す。
6. 結果に異常があれば、同じ地域のノードまたは対応するプロトコルに切り替えて比較する。

クライアントに「接続済み」と表示されても、トンネルやプロキシのセッションが確立したことを示すだけで、すべての通信がその回線を通るとは限りません。出口アドレスを確認してウェブ通信の経路を確かめ、DNS測定と実際のアプリでも検証します。出口アドレスが変わらない場合は、速度を判断する前にシステムプロキシ、仮想ネットワークアダプターの権限、分流ルールの適用状況を確認します。

DNSリークと分流ミスは速度測定の結論をゆがめる

DNSはドメイン名をアドレスに変換します。回線接続後も名前解決を国内ネットワークが処理していると、DNSリークが起きる可能性があります。これはプライバシーだけでなく、異なる地域のコンテンツノードに解決されて測定結果が変わる原因にもなります。2台の端末が同じドメインにアクセスしても異なる接続先へ解決されれば、実際の経路は同じではなく、帯域幅や遅延を直接比較できません。

分流ルールは、どのリクエストを回線経由にし、どれを直通にするかを決めます。ルールモードでは、測定サイトのページはプロキシ経由でも、測定サーバーのドメインやアプリの接続は直通と判定される場合があります。逆に、ページは直通で測定データだけが回線経由になることもあります。この場合、ページに表示されたノード情報と実際のデータ経路が一致しません。確認時は一時的にグローバルモードと比較できますが、検証後は日常利用に適したルールへ戻し、測定時のモードを明記します。

DNS設定は初回表示の速度にも影響しますが、接続確立後の継続的なダウンロード上限を直接決めるものではありません。初回の名前解決だけが長く、その後の転送が正常ならDNSを優先して確認します。長時間の転送が継続的に遅い場合は、帯域幅、パケットロス、プロトコル、接続先サーバーの制限を確認します。

結果を比較可能な記録にまとめる

記録は複雑でなくても構いませんが、項目はそろえる必要があります。少なくとも、日付、時間帯、国内ネットワーク、接続方式、クライアント、ノード地域、回線タイプ、プロトコル、分流モード、測定対象、各結果を含めます。測定中のネットワーク再接続、ノード切り替え、バックグラウンド通信、接続先サーバーの応答異常などは、別途メモします。

記録を分析するときは、まず同じ時間帯の直通接続と接続後の結果を比較し、次に同じノードの混雑時と深夜の変化を確認し、最後に異なるノードやプロトコルを比べます。この順序なら変数の混在を抑えられます。帯域幅が高くてもジッターが大きいノードはファイル転送向きで、リアルタイム操作には不向きかもしれません。ピーク値が普通でも安定していれば、日常の閲覧や会議では快適な場合があります。

回線を選ぶとき、すべての指標を一つの総合点にまとめる必要はありません。ウェブ閲覧では応答と安定性、長時間のダウンロードでは継続的なスループット、会議やリモート操作では遅延、ジッター、パケットロスが重要です。主な用途を先に決め、記録から対応する指標を選ぶほうが、ダウンロードのピーク値だけを比べるより意味のある結論になります。