VPN速度の実測比較｜本当の回線性能を見極める方法

VPNの速度を実測比較する際、測定サイトを開いてピーク帯域幅を記録するだけでは、回線全体を判断できません。結果は、利用中のアクセス回線、測定サーバー、出口地域、プロトコルの実装、クライアントの負荷、測定時間帯に左右されます。参考になる測定には、管理できる条件をそろえたうえで、操作への応答、転送の安定性、目的のサービスでの実際の動作を個別に確認する必要があります。

「速い」は単一の指標ではありません。ページの表示速度は往復遅延、DNS解決、接続確立の影響を大きく受けます。音声通話や会議、リアルタイム操作ではジッターとパケットロスが重要です。一方、ダウンロード、クラウド同期、高ビットレート動画では持続スループットが求められます。短時間の測定で高いピーク値が出ても、長時間接続では速度低下を繰り返すことがあります。逆に、ピーク値は標準的でも変動の少ない回線のほうが、視聴や転送は安定する場合があります。

遅延、ジッター、パケットロス、帯域幅を分けて考える

遅延は、端末から目的地までデータが届いて戻るまでの時間を示します。物理的な距離、通信事業者のルーティング、回線トポロジーの影響を受け、通常は帯域幅を増やしても相殺できません。日本の出口を測定する場合、測定サーバーが別の地域にあると、出口からさらに地域をまたぐ経路を測ることになり、端末から日本のノードまでの性能は反映されません。そのため、測定サーバーの場所は実際の利用先とできるだけそろえる必要があります。

ジッターは、連続するデータパケットの遅延がどれだけ変動するかを示します。平均遅延が近い回線でも、ジッターの違いによってリアルタイム利用時の感覚が大きく変わることがあります。リモートデスクトップの応答が速くなったり遅くなったりする、音声が断続的になる、ゲーム操作のテンポが安定しないといった現象は、ジッターが原因かもしれません。平均遅延だけでは問題が隠れるため、最終的な集計値ではなく、連続したサンプルの推移も確認しましょう。

パケットロスは、データパケットが想定どおり到達しない状態です。少量の一時的なロスは、無線干渉、ローカルネットワークの混雑、中継ルートの変化でも起こるため、1回の測定だけでVPNノードが原因だと判断することはできません。より確実なのは、同じネットワークと同じ測定先を使い、未接続時と接続時に繰り返し比較する方法です。基礎回線ですでにロスが発生している場合、プロトコルや出口を変更しても根本的な解決にならないことがあります。

帯域幅の測定では通常、ダウンロードとアップロードの両方向を確認します。ただし、測定ツールに表示される短時間のスループットが、アプリで長時間得られる速度と一致するとは限りません。転送ウィンドウ、同時接続数、サーバー負荷、端末性能が結果に影響します。測定時は全体のグラフを保存し、開始時、安定時、終了前に大きな低下がないかを確認してください。

再現可能なVPN速度テストの手順を作る

比較対象として基礎回線を記録する

まずプロキシまたはVPNを切断し、現在の接続方法、ネットワーク環境、測定先を記録します。ファイル同期、ソフトウェア更新、動画再生など、バックグラウンドで通信を続けるタスクは停止し、測定中はできるだけ無線アクセスポイントを切り替えないでください。基礎回線の測定は理想的な数値を追うためではなく、その時点でローカルネットワークが提供できる上限と安定性を確認するためのものです。

速度を測る前に、端末が省電力状態になっていないことも確認します。一部のモバイル端末ではバックグラウンド通信が制限され、デスクトップ端末でも高負荷、発熱、ネットワークアダプターの設定が暗号化通信のスループットに影響することがあります。同じノードを別の端末で使った結果に大きな差がある場合は、すぐに回線の変動と決めつけず、クライアントのバージョン、OSのネットワークスタック、ハードウェア負荷を確認しましょう。

出口、プロトコル、測定サーバーを固定する

接続したら、まず1本の回線に固定し、クライアントによるノードの自動切り替えを止めます。測定サーバーも固定し、用途に合わせて選びます。日本向けサービスを評価するなら同じ地域の対象を選び、国際的な業務システムを評価するなら実際の設置地域を選択します。比較では一度に1つの変数だけを変えてください。たとえば出口を固定してShadowsocksとTrojanだけを切り替えれば、差がプロトコルによるものか回線によるものかを判断できます。

サブスクリプションURLをクライアントに取り込んだ後も、ノード名から分かるのは通常、地域や回線種別の手がかりにすぎず、実測の代わりにはなりません。サブスクリプションの更新でノードのパラメーターが変わることもあるため、比較前にクライアントが最新状態か確認し、使用したノード、プロトコル、ルール分岐モードを記録します。クライアントが接続ログに対応している場合は、ハンドシェイク失敗、再接続、タイムアウトの情報を保存できます。ただし、ログを共有する前にサブスクリプションURL、認証情報、ノードの認証情報を削除してください。

空いている時間帯と混雑する時間帯を含める

1つの時間帯の結果は、その時点の状態しか示しません。国際経路は、ローカルのアクセス回線、国際出口、目的のサービスの負荷によって変化します。そのため、普段実際に使う時間帯に同じ手順を繰り返してください。空いている時間帯は安定しているのに混雑時だけ変動が続くなら、共有回線の混雑やルート制御が関係している可能性があります。すべての時間帯で異常が出る場合は、プロトコル、端末、ローカルネットワークをさらに確認します。

各回の測定では、基礎回線、VPN接続、遅延とパケットロス、短時間スループット、持続転送、対象アプリの確認という、近い順序を保ちます。順序を固定すると、測定サーバーの一時的な変化による影響を減らせ、ログも比較しやすくなります。最良の1回だけ、または最悪の1回だけを残すのは避け、典型的な状態と異常発生時の状況を記録しましょう。

• 接続ネットワーク、端末、出口地域、測定サーバーを固定する。
• バックグラウンドのダウンロード、システム更新、クラウド同期など、通信を継続的に使う処理を停止する。
• プロトコル、クライアント、ルール分岐モード、測定時間帯を記録する。
• 基礎回線とVPN接続の両方の結果を保存する。
• グラフ全体、再送、切断、復旧の過程を確認する。
• 最後は測定サイトだけで終わらせず、実際の対象サービスで確認する。

直結、中継、IEPL専線を比較する方法

直結回線は、ユーザーのネットワークから海外の入口へ直接接続する方式です。ただし、途中では公衆網の通信事業者ルートを通ります。構成が比較的シンプルで、経路が適切なら追加オーバーヘッドを抑えられますが、国内通信事業者の国際ルーティング品質に左右されやすい特徴があります。同じ出口でも地域や接続ネットワークが変われば経路が大きく異なるため、特定の都市や通信事業者で得た結果をすべてのユーザーに当てはめることはできません。

中継回線は、まず国内または近隣地域の入口に接続し、その後、中継ネットワークを経由して出口へ向かいます。中継の価値は、国際経路を組み直し、品質が不安定な公衆網の一部を避けられる点にあります。一方で、経路と制御の工程が増えるため、理論上の経路が必ずしも短くなるとは限りません。中継が適しているかは、1回の遅延だけでなく、混雑時間帯のジッター、パケットロス、持続スループットで判断しましょう。

IEPL専線は通常、通信事業者の専用線リソースを使って地域間のネットワークを接続する経路を指し、一般的な公衆網の直結や通常の中継とは伝送方式が異なります。重視されるのは経路の制御性や混雑の分離であり、どの場所からどの対象へ接続しても最低遅延を保証するものではありません。専線の入口まではユーザーのローカル接続、出口の先には対象サービスのネットワークが残るため、無線干渉、入口の混雑、対象サーバーの制限も測定結果に反映されます。

プロトコルの違いは測定結果にどう影響するか

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、カプセル化、伝送方式、輻輳制御がそれぞれ異なります。ただし、クライアントの実装、サーバー設定、ネットワーク条件を切り離して、恒久的な速度順位を単純に決めることはできません。プロトコルを比較する際は、同じ出口、同じ測定先、近い時間帯を使い、暗号化方式、トランスポート層、ルール分岐を同時に変更していないことを確認します。

Shadowsocksは構成が比較的シンプルで、対応クライアントも多く、基本的なプロキシ経路の性能を確認する際によく使われます。VMessとVLESSは複雑な伝送設定に対応するクライアントでよく見られます。VLESS自体は簡潔な認証と伝送の組み合わせを重視しますが、実際のオーバーヘッドは外側のトランスポートとセキュリティ設定に左右されます。Trojanは通常TLS形式で通信を運び、接続確立や証明書設定が初回アクセスに影響します。ただし、安定した転送性能は全経路によって決まります。

Hysteria2とTUICは、QUICベースの伝送設計により、高遅延やパケットロスのあるネットワーク環境に対応します。不安定な経路では、より積極的なスループットを維持できる場合がありますが、UDPの到達性、クライアントパラメーター、ネットワーク機器の処理能力にも強く依存します。接続ネットワークがUDPを制限していると、ハンドシェイク失敗、頻繁なフォールバック、異常な速度として現れることがあります。その場合は、ノードの帯域幅不足と決めつける前に、伝送が正常に確立しているかを確認してください。

プロトコルの測定では、「測定ツールで帯域を使い切れる」ことと「日常のアプリと相性がよい」ことを分けて考える必要があります。あるプロトコルが多接続の測定で優れていても、ブラウザーの単一接続ダウンロード、会議アプリ、ストリーミングの分割リクエストで同じ結果になるとは限りません。より妥当な結論には、ピーク値、持続性、エラーの有無、対象アプリでの体感を含めます。

クライアント、サブスクリプションの取り込み、プラットフォームの違い

WindowsとmacOSのクライアントは通常、システムプロキシ、仮想ネットワークアダプター、ルール分岐などのモードを利用できますが、具体的な実装は完全に同じではありません。システムプロキシはプロキシ設定に従うアプリに主に影響し、仮想ネットワークアダプターのモードはより多くのシステム通信を制御できます。2台の端末で異なるモードを使っている場合、同じサブスクリプションを取り込み、同じノードを選んでも、測定経路が異なる可能性があります。

モバイルプラットフォームでは、OSのバックグラウンド制御やVPNインターフェースの制限を受けます。アプリの切り替え、画面ロック、省電力設定によって接続が一時停止または再確立されることがあります。モバイル端末で測定する際はアプリを前面に保ち、ネットワーク種別が安定している状態で実行してください。モバイル通信への切り替えや無線ローミングによる再接続を、プロトコル自体の不安定さと取り違えないようにしましょう。

サブスクリプションURLを取り込むときは、サービス提供元が対応しているクライアントを使い、URLの入手元を確認します。URLをコピーしたら、クライアントのサブスクリプション管理画面で追加・更新し、明確なノードを選んで測定します。サブスクリプションURLを公開測定サイト、スクリーンショット、質問投稿に貼り付けないでください。アクセス用の認証情報が含まれている可能性があります。更新後にノード一覧が変わらない場合は、キャッシュ、更新時刻、クライアントの対応フォーマットを確認します。

クライアントによって、DNS、ルーティングルール、UDP転送の初期設定が異なる場合があります。クライアントを移行する際は、ノード名だけでなく各項目を確認してください。特にHysteria2やTUICのようにUDPに依存するプロトコルでは、クライアントが対応する転送を有効にしているか、OSのファイアウォールが通信を許可しているかが結果に影響します。

DNSリークとルール分岐が測定を乱す理由

DNSクエリはドメイン名をアドレスに変換します。VPN接続後もドメインの問い合わせが元のネットワークのリゾルバーで処理されると、DNSリークが発生する可能性があります。これはプライバシーと経路の一貫性に関わるだけでなく、速度測定にも影響します。コンテンツ配信サービスは問い合わせ元に応じて異なる地域のサーバーを返すことがあるため、同じドメインでも設定によって接続先が変わります。すると回線の差に見えても、実際には別のサーバーを比較している可能性があります。

DNSを確認する際は、問い合わせが想定した解決経路で処理されているか、接続前後で解決結果がどう変わったかを確認します。検査ページを1つ開くだけでは十分に説明できません。ブラウザーのセキュアDNS、OSのキャッシュ、クライアント内蔵DNSが関与することがあるためです。切り分けではDNSキャッシュを削除し、ブラウザー個別のDNS機能を一時的に無効にしてから、クライアントのルールがDNSを制御しているか確認します。

ルール分岐は、どの通信をプロキシ経由にし、どれを直結にするかを決めます。測定サイトが直結と判定されると、基礎回線に近い結果になり、回線が異常に速いという錯覚を生みます。ページ本体はプロキシ経由でも測定リソースが直結なら、結果はさらに分かりにくくなります。測定前にクライアントの接続ログやルールの適用情報を確認し、測定ドメイン、測定サーバー、関連リソースが同じ経路を通っているか確認してください。

グローバルモードはルールによる干渉を切り分けるのに適していますが、日常的に長期間使う必要があるという意味ではありません。基準測定が終わったら実際のルール分岐設定に戻し、対象アプリを検証します。グローバルモードでは正常でルールモードでは異常なら、ノードを何度も変えるのではなく、ドメイン分類、アドレスルール、DNS解決、アプリのバイパス設定を確認しましょう。

結果を読み解き、ボトルネックを特定する

接続後に遅延が全体的に増えたものの変動が安定しているなら、まず出口までの距離と経路長を考えます。平均遅延があまり変わらないのに尖った値が頻発するなら、無線干渉、混雑、中継入口の状態を確認します。短時間のダウンロードは速いのに持続転送で徐々に低下する場合は、サーバー側の速度制限、接続先の制約、端末の発熱による性能低下、回線混雑などが考えられます。

アップロードは正常なのにダウンロードだけ異常、またはその逆の場合も、単純に「ノードが遅い」とは判断できません。上下の通信が異なるキューを通ることがあり、アクセス回線が非対称な制御を採用している場合もあります。同じ地域の別の測定サーバーに変え、基礎回線と比較し、特定のアプリだけで問題が起きるかを確認しましょう。1つのWebサイトだけ遅いなら、そのサイトの出口側接続、コンテンツ配信ノード、アカウント設定が関係している可能性が高くなります。

回線を切り替えた直後の初回アクセスには、DNSキャッシュ、TLSセッション、アプリの接続プールも影響します。古い接続が結果に混ざらないよう、対象アプリに新しい接続を確立させ、出口アドレスが変わったことを確認してください。ブラウザーを更新するだけでは既存の接続が閉じない場合があるため、アプリの検証では同じページを連続更新するのではなく、新しいセッションを確認します。

信頼できる速度測定の記録には、使用した端末とクライアント、接続先の地域、プロトコルとルール分岐モード、対象サーバーの場所、基礎回線の状態、異常を同じ条件で再現できるかを記載します。

測定値から実際の利用シーンへ

測定ツールは基準を作るのに役立ちますが、実際の業務利用の確認に代わるものではありません。動画視聴では再生開始、画質の切り替え、バッファリング、長時間再生を観察します。リモートワークではログイン、ファイル同期、会議、リモートデスクトップの継続性を確認します。ダウンロードでは開始直後だけでなく、転送全体を記録します。用途ごとに必要な結論は異なるため、すべての指標で最高値を求める必要はありません。

回線を選ぶときは、まず出口地域で絞り込み、次に回線トポロジーとプロトコルを比較します。対象サービスが日本にあるなら、日本の出口と、そのサービスとの接続性がよい近隣出口を優先して測定します。複数地域へのアクセスが必要な場合は、対象ごとに結果を作り、1本の回線で全体の体験を代表させないようにします。ルール分岐を使えば、サービスごとに適した出口を選び、不要な迂回を減らせます。

最終レポートには、測定条件、代表的な結果、異常の内容、実際のアプリでの結論を残します。一時的な異常なら発生時間帯を記録して再測定し、継続する異常なら測定サーバー、プロトコル、回線、接続ネットワークの順に変更します。一度に1つの変数だけを調整することで、問題の範囲を段階的に絞り込めます。