VPNの速度は、速度テストのページに表示されるダウンロード帯域幅だけでは判断できません。結果には、ローカル回線、Wi-Fi、測定サーバー、出口回線、プロトコルのオーバーヘッド、その時点の混雑状況が同時に影響します。事前にローカルの基準値を測らず、テスト環境も固定していなければ、「このノードのほうが速い」という判断は、異なる条件の数値を並べただけになりがちです。
より信頼できる方法は、テストを基準値、接続状態、回線品質、実際のアプリ利用時の体感に分け、普段ネットワークを使う時間帯に繰り返し記録することです。見栄えのよいスクリーンショットではなく、遅い原因がローカルか遠隔側か、帯域不足・高遅延・パケットロス・ジッターのどれなのかを確認できる記録になります。
まずローカルネットワークの基準値を測る
VPNのテストを始める前に、クライアントを切断し、直接接続時の状態を記録します。目的はローカル回線の速さを示すことではなく、現在の接続環境における上限を把握することです。直接接続ですでにパケットロスが発生している場合、どの国際回線につないでも安定した結果は得にくくなります。
テストでは、端末・接続方法・場所をできるだけ固定します。ノートパソコンを部屋ごとにWi-Fiで使うと、壁やチャンネルの混雑、省電力設定の影響を受けることがあります。有線接続は、切り分け用の基準環境として通常より適しています。普段Wi-Fiを使う場合も測定はできますが、場所と周波数帯をそろえ、システム更新、クラウド同期、その他の帯域を継続的に使う処理は一時停止してください。
- ✅ 同じ端末、同じ接続方法、同じ速度テストサービスを使う。
- ✅ バックグラウンドのダウンロード、クラウド同期、ライブ配信、その他の継続的な通信を停止する。
- ✅ 直接接続時とVPN接続時を分けて記録し、2つの結果を混在させない。
- ✅ 普段利用する時間帯にテストし、ネットワークが最も空いている時間だけを選ばない。
- ❌ 端末と回線を同時に変え、1回の数値だけで結論を出さない。
速度テストサービスも統一する必要があります。サービスごとに利用するサーバー、経路、同時接続の方式が異なるため、結果をそのまま比較することはできません。ブラウザの速度テストはダウンロード、アップロード、遅延を手早く確認するのに向いています。一方、システムのネットワークツールは、パケットロス、経路の変化、DNS名前解決を継続的に調べるのに適しています。両方の結果を組み合わせることで、障害箇所を特定しやすくなります。
帯域幅・遅延・パケットロスはそれぞれ何を示すか
帯域幅は、一定時間内に転送できるデータ量を示し、大容量ファイルのダウンロード、高画質動画、まとめて行う同期の能力を判断するのに適しています。遅延はデータの往復にかかる時間で、ウェブページの初回応答、リモートデスクトップ操作、インタラクティブなアプリに直接影響します。パケットロスは転送中のデータが正常に届かなかった状態を示し、ジッターは連続するパケットの遅延がどれだけ安定しているかを表します。
これらの指標は互いに代用できません。ダウンロード帯域幅が十分な回線でも、遅延の変動が大きければ、ウェブページの表示がときどき止まることがあります。平均遅延が低くても、長時間の会議中に断続的なパケットロスが起きれば、音声が途切れたり画面共有がぼやけたりします。ピーク帯域幅だけを見ていると、実際の使い勝手を左右する問題を見落としやすくなります。
| 指標 | 主に示すもの | 関係の深い利用シーン | 確認方法 |
|---|---|---|---|
| ダウンロード帯域幅 | 遠隔側からローカルへ継続的にデータを転送する能力 | ファイルのダウンロード、動画のバッファリング、システム更新 | 直接接続と接続後の回線で安定して出る範囲を比較し、ピーク値だけを切り取らない |
| アップロード帯域幅 | ローカルから遠隔側へデータを送信する能力 | ビデオ会議、ファイルのアップロード、リモートバックアップ | 継続的なアップロード中に大きな変動や中断がないか確認する |
| 往復遅延 | リクエストを送り、応答を受け取るまでの待ち時間 | ウェブ操作、ゲーム、リモートターミナル | 連続してサンプリングし、対象サーバーの所在地も考慮する |
| パケットロス | データパケットが正常に届かない状態 | 音声通話、会議、リアルタイム共同作業 | プローブを継続的に送信し、断続的な欠落がないか確認する |
| ジッター | 隣接するデータパケット間で遅延が変化する度合い | 音声通話、ライブ配信、リモートデスクトップ | 遅延が一定の範囲に収まっているか確認し、平均値だけを見ない |
平均値だけでは問題が隠れることもあります。連続テストで大半のリクエストが速くても、一部だけ突然長く待たされると、平均遅延は正常に見える一方で、ページがときどき固まるように感じられます。記録には元の出力を残すか、少なくとも変動状況を書き留め、最終的な集計値だけを転記しないようにしましょう。
「ダウンロード速度が高い」ことと「回線が安定している」ことは同じ結論ではありません。前者はスループットに寄った指標であり、後者はパケットロス、ジッター、接続断、時間帯による一貫性も含めて判断します。
再現性のあるVPN速度テストの手順
以下の手順は、異なる回線、プロトコル、クライアント設定を比較する際に使えます。特定のツールを使うことよりも、毎回同じ順序と条件で測ることが重要です。記録は表計算シートやテキストファイルに保存し、日付、時間帯、接続方法、ノードの地域、プロトコル、ルーティングモード、結果の概要を記載します。
- 直接接続時の基準値を記録する。VPNを切断し、ダウンロード、アップロード、継続的な遅延、DNS名前解決が正常か確認します。この時点で明らかなパケットロスがあるなら、まずローカルネットワークを確認してください。
- 測定対象の回線に接続する。クライアントが接続済みと表示されていることを確認し、出口IPが変わったか調べます。クライアントの状態表示だけに頼らないでください。接続が確立していても、すべてのアプリ通信が想定どおりトンネルを通るとは限りません。
- DNSを確認する。ドメイン名前解決のリクエストが想定した経路を使っているか確認します。出口が切り替わっていてもDNSがローカルネットワークで直接処理されていると、速度テストサイトの選択、地域判定、実際のアクセス結果に影響することがあります。
- 同じ帯域幅テストを実行する。速度テストサービスと対象サーバーをそろえ、継続時の挙動を観察します。測定中にウィンドウを切り替えて、別のダウンロードを開始しないでください。
- 遅延を継続的に測定する。回線の入口、普段使う対象サービス、または安定した公開対象をそれぞれ確認します。入口が安定しているのに対象側が不安定なら、後続の経路に問題がある可能性があります。入口自体が変動している場合は、まず接続ノードを変更してください。
- 実際のアプリで確認する。普段使うウェブページを開き、動画を再生し、短時間の会議やリモートターミナル接続を試します。ツールのテストは正常なのにアプリで問題が出る場合は、ルーティング、DNS、ブラウザのプロキシ、アプリ固有のネットワーク設定を引き続き確認します。
- 時間帯を変えて繰り返す。勤務時間帯と夜間では混雑状況が異なることがあります。時間帯をまたいで結果の傾向が一致して初めて、その回線を長期利用の候補にできます。
測定記録
接続方法：有線または無線
ローカルネットワーク：直接接続時の基準値を確認済み
ノードの地域：クライアントで実際に選択した内容を記入
回線タイプ：直接接続 / 中継 / IEPL
プロトコル：クライアントの現在の設定を記入
ルーティングモード：グローバル / ルール
DNS経路：確認結果を記入
確認項目
ダウンロードとアップロード：安定した範囲、急な低下の有無
継続的な遅延：集中しているか、急増があるか
パケットロス：継続的または断続的に発生しているか
実際のアプリ：ウェブ、会議、リモート接続での状態
備考：バックグラウンド処理、ネットワーク切り替え、エラー表示プロトコルと回線タイプが結果に与える影響
測定結果はノードの所在地だけで決まらず、プロトコルの実装、転送方式、回線経路にも左右されます。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはカプセル化や転送戦略が異なりますが、ネットワーク環境を無視して速さを単純に順位付けすることはできません。クライアントの実装、暗号化処理、輻輳制御、通信事業者の回線、サーバー負荷が最終的な結果を変えます。
安定してパケットロスの少ないネットワークでは、一般的な転送方式を使うプロトコルのほうが安定した結果になりやすい傾向があります。変動やパケットロスが目立つ回線では、Hysteria2やTUICのようにQUICの考え方を取り入れたプロトコルが、異なる復旧特性を示すことがあります。ただし、あらゆるネットワークで速いとは限りません。UDPの扱いが弱いネットワークや厳しい制限がある環境では、別のプロトコルに変えたほうが安定する場合もあります。
回線経路も重要です。直接接続では、端末がローカルの通信事業者網を通って遠隔側の入口へ直接到達します。経路は単純ですが、地域をまたぐ通信は公衆ネットワークのルーティングに左右されやすくなります。中継では、近い中継ノードに接続してから出口へ転送するため、入口の品質を改善したり、好ましくない公衆経路を避けたりする目的で使われます。その一方で、調整と転送の区間が1つ増えます。
IEPL専線と通常の公衆ネットワークによる直接接続の主な違いは、転送経路と運用方法にあります。専線区間によって公衆ネットワークのルーティングに伴う不確実性を一部減らせますが、端末から入口まで、また出口から対象サイトまでは別のネットワークを通る可能性があります。したがって、「専線」だからといってすべての対象で遅延が同じになるわけではなく、実際のウェブサイトを対象としたテストの代わりにもなりません。
| タイプ | 経路の特徴 | テストの重点 | 切り分けに適した問題 |
|---|---|---|---|
| 直接接続 | ローカルネットワークから遠隔側の入口へ直接向かう | 地域間のルーティング、夜間の変動、入口でのパケットロス | ローカル通信事業者からノードまでの公衆経路が安定しているか |
| 中継 | まず中継に入り、そこから出口へ転送する | 中継入口の品質、転送の安定性、出口での状態 | 直接経路が不適切なとき、中継によって継続性が改善するか |
| IEPL | 経路の一部に専線を使用 | 入口への接続、専線区間、対象サイトまでの末端経路 | 公衆ネットワークの変動が置き換えられた経路部分に集中しているか |
DNSとルーティングルールが速度テストに干渉する理由
「VPNが遅い」と感じても、トンネルのスループット不足ではなく、DNS名前解決やルーティングルールがリクエストを不適切な方向へ送っている場合があります。ドメインの名前解決は、リクエスト元に応じて異なる地域のサービスノードを返すことがあります。DNSリクエストがローカルネットワークを通り、ウェブ通信だけが遠隔側の出口から出ると、コンテンツ配信ネットワークが出口に合わないノードを選び、経路の遠回り、初回表示の待ち時間、動画の再生開始の遅さにつながることがあります。
DNSリークの確認は、名前解決リクエストが想定した経路から外れていないかを確かめるために行います。単なるプライバシー上の確認ではなく、地域判定や接続先にも影響します。テストでは出口IPとDNSの結果を同時に確認してください。出口IPだけでは、名前解決もクライアントの設定どおり処理されているか分かりません。
ルーティングルールは、どのリクエストをプロキシ回線へ送り、どれを直接接続のままにするかを決めます。グローバルモードはルールのマッチング問題を切り分けるのに適していますが、日常的な長期利用に必ずしも向いているとは限りません。ルールモードでは、ローカルサービスを直接接続し、指定した対象だけを国際回線へ送れます。ただし、ルールの期限切れ、ドメインの未一致、アプリ独自のネットワークスタックにより、同じページのリソースが異なる経路を通ることがあります。
- ✅ 出口IPが切り替わり、選択した出口と地域が一致している。
- ✅ DNSリクエストが想定した経路を使い、誤ったローカルの名前解決経路で処理されていない。
- ✅ 速度テストサイトと静的リソースが同じルーティングルールで処理されている。
- ✅ ブラウザ拡張機能、システムプロキシ、クライアントモードが互いに設定を上書きしていない。
- ❌ グローバルモードで測定した結果を、そのままルールモードに当てはめない。
グローバルモードでは正常でルールモードでは異常が出る場合、まずドメインルール、IPルール、リモートルールセットの更新日時、クライアントログを確認します。ウェブの速度テストは正常なのに特定のアプリが常に直接接続される場合は、そのプラットフォームのクライアントがアプリ単位のプロキシに対応しているか、アプリがシステムプロキシを迂回して直接接続していないかを確認してください。
プラットフォーム別クライアントによる測定差
デスクトップ版は通常、より詳細なルーティング、システムプロキシ、仮想ネットワークアダプター、ログ情報を確認でき、細かな切り分けに適しています。モバイル端末は、バックグラウンド制御、電池管理、ネットワーク切り替えの影響を受けやすく、Wi-Fiからモバイルネットワークへ切り替えると既存の接続が再確立され、テスト条件も変わることがあります。
WindowsとmacOSのクライアントには、システムプロキシモードと仮想ネットワークアダプターモードの両方が用意されている場合があります。システムプロキシは主にシステム設定に従うアプリへ影響し、仮想ネットワークアダプターはより広範な通信を取り込めます。トンネルに入るアプリの範囲が異なるため、2つのモードで結果が変わることがあります。Linux環境では、コマンドラインクライアント、システムルーティング、デスクトップのネットワーク管理ツールを組み合わせて設定することが多く、デフォルトルートとDNSが実際に更新されたかを確認する必要があります。
AndroidとiOSは通常、システムVPNインターフェースを通じて通信を転送しますが、アプリごとのルーティング、バックグラウンド維持、システム制限は完全には同じではありません。モバイル端末で測定する前に現在のネットワークを固定し、途中で接続方法を切り替えないでください。省電力状態になるとバックグラウンドの検査が停止されることもあるため、連続テストではアプリを前面に表示しておくのが安全です。
サブスクリプションURLは、ノード設定をクライアントへ提供するだけで、すべてのクライアントが同じ初期パラメータを使うことを保証するものではありません。サブスクリプションを読み込んだら、現在のノード、プロトコル、転送オプション、DNSモード、ルーティング方針を確認してください。リモートルール、仮想ネットワークアダプター、UDP転送への対応はクライアントごとに異なるため、同じサブスクリプション元だからといって経路や動作が完全に一致すると考えてはいけません。
よくある速度テストの誤りと確認の順番
1回測っただけでノードを順位付けする
公衆ネットワークの経路とローカルの接続状態は時間帯によって変わります。1回の結果が示すのは、その時点の状態だけです。普段使う時間帯に繰り返し測定し、結果の安定性を確認するほうが合理的です。回線性能として、最も高かった1回だけを選ばないようにしましょう。
距離だけを見て、実際の経路を見ない
地理的に近いからといって、ネットワーク経路が短いとは限りません。データは異なる通信事業者や交換拠点を経由することがあり、近い出口でも遠回りになる場合があります。ノードの地域は候補を絞る条件として使い、最終的には継続的な遅延、経路、アプリの使用感で確認してください。
速度テストのサーバーをすべてのウェブサイトとみなす
速度テストサービスは通常、良好なネットワーク接続を持ち、適したサーバーを自動選択します。普段使うウェブサイトは異なるネットワークにあり、コンテンツ配信の方式も異なることがあります。速度テストページの結果がよくても、その測定対象までの経路が良好だと分かるだけで、実際のサービスでの確認に代わるものではありません。
端末性能とクライアントの状態を無視する
プロトコルの暗号化、仮想ネットワークアダプター、データ転送には端末の処理能力が必要です。端末が高負荷状態、発熱による性能低下、省電力モードになっていると、測定結果に影響することがあります。クライアントログに再接続、名前解決の失敗、ルート更新が継続的に記録されている場合も、回線を比較する前に異常を解消してください。
速度が遅いからといって、プロトコルを次々に変える
切り分けは、経路に沿って近いところから遠いところへ進めます。まずローカルの基準値を確認し、次に入口の品質、DNS、ルーティングを確認してから回線を比較し、最後にプロトコルのパラメータを調べます。条件をそろえずに設定を連続して変えると、各回の結果を比較できなくなります。
- まず直接接続のネットワークが安定しているか確認する。
- 次に出口IP、DNS、ルーティングが想定どおりか確認する。
- 続いて、同じプロトコルで異なる回線を比較する。
- 回線を決めてから、プロトコルとクライアントモードを比較する。
- 最後に普段使うアプリで、実際の使用感が改善したか確認する。