VPNの速度測定は条件をそろえる

VPNの速度を比較するには、まず未接続時のネットワークを記録し、端末・クライアント・測定先・時間帯をそろえます。遅延、パケットロス、ダウンロード速度と実際のアプリの動作を確認しましょう。測定結果のスクリーンショット1枚だけでは、その時点の経路しか分からず、長期的な速度の優劣は判断できません。

まず、解決したい問題を明確にします。ウェブページの表示が遅いのか、動画が何度も止まるのか、ファイルのダウンロードが不安定なのかで、重視すべき指標は異なります。ウェブの操作ではリクエストの往復時間や接続確立、継続的なダウンロードでは転送速度、ライブ配信では途切れにくさが重要です。最大の数値を追うのではなく、用途に合わせて測定しましょう。

できるだけ同じ端末、同じ接続方法で比較します。可能なら有線接続を使い、Wi-Fiの場合は端末の位置と周波数帯を変えないようにします。クラウドストレージの同期、システム更新、大容量ファイルの転送を一時停止し、同じネットワーク内で大きなダウンロードが並行していないことも確認してください。そうしないと、変化の原因が無線干渉や家庭内の帯域競合なのか、判別できないことがあります。

  • ✅ 利用中の通信事業者、接続方法、端末、クライアントのバージョンを記録する。
  • ✅ 測定サーバーまたはダウンロード元を固定し、対象地域を記録する。
  • ✅ 選択した回線、クライアントのモード、実際の出口地域を記録する。
  • ✅ 未接続時の基準値を残し、異常があればローカルネットワークを再測定する。
  • ❌ 端末・サーバー・測定時間が異なるスクリーンショットを、そのまま順位付けしない。

速度測定ツールと指標の選び方

ブラウザーの速度測定サイトでは、ダウンロード・アップロードの転送速度や、アイドル時・負荷時の遅延を確認できます。ただし、自動選択されるサーバーは出口によって変わる場合があります。回線を比較するときは測定先を手動で固定しましょう。サーバーを固定できないツールを使う場合は、サーバー名と地域を記録し、異なる経路の結果を同じ条件として扱わないようにします。

クライアント内蔵のノードテストは、最終的な評価より候補の絞り込みに向いています。接続確立を測るもの、特定のウェブサイトへの応答を測るもの、ノードのポートだけを測るものなどがあるため、「遅延」の定義を確認してください。クライアントに表示される応答時間が、ゲームや動画、実際のウェブサイトとの往復時間と一致するとは限りません。

ツールごとの用途を把握し、測定対象と方法を明記しましょう
ツール・測定方法 主な測定項目 分かること 結果を見る際の注意点
ブラウザーの速度測定サイト ダウンロード・アップロード速度、アイドル時・負荷時の遅延 この経路の転送速度は用途に足りるか? 測定サーバー、複数接続の方式、ブラウザーの影響を受ける
システムの ping ICMP の往復時間、応答の欠落 応答する宛先までの通信に揺らぎがあるか? 通常のプロキシは ICMP を経由させない場合があり、宛先側で応答を制限・拒否することもある
固定ファイルのダウンロード 継続中のダウンロード速度、中断と再開 実際の長時間接続で安定した転送を維持できるか? 配信元の速度制限、キャッシュ、ストレージ、接続方法の影響を受ける
ブラウザーの開発者ツール 名前解決、接続、最初のバイトまでの時間、リクエスト所要時間 ウェブページの表示が遅いのはどの段階か? キャッシュ、接続の再利用、サイト側のバックエンドで結果が変わる
実際に使う動画・アプリ 読み込み、バッファリング、再接続、操作への応答 目的の用途で問題なく快適に使えるか? アカウントの地域設定、コンテンツの配信方針、アプリ自体の状態も影響する

遅延・パケットロス・速度の見方

遅延が小さくても、ダウンロードが速いとは限らない

遅延は通常、データの往復にかかる時間を表します。距離やルーティング、通信の混雑などが影響します。ジッターは遅延の変動の大きさです。平均値が同程度でも、変動が大きい回線では操作の応答が不安定になることがあります。記録では中央値だけでなく遅い測定値も確認し、最速の結果だけを残さないようにしましょう。

帯域を使い切ると、ルーターや経路上の機器にデータが滞留し、遅延が大きくなることがあります。そのため、アイドル時は速くても、ダウンロード中に反応が鈍くなるのは矛盾ではありません。測定ツールに負荷時の遅延が表示される場合は、アイドル時の遅延と合わせて確認しましょう。また、未接続時にも測定し、混雑がローカル回線ですでに発生していないかを判断します。

パケットロスは測定方法と合わせて判断する

システムの ping で応答が欠落しても、アプリの通信でパケットロスが発生しているとは限りません。機器によっては業務データを優先して転送しつつ、ICMP 応答を制限することがあります。通常のシステムプロキシは ping を経由させないことが多く、TUN モードで処理されるかどうかもクライアントの実装次第です。測定対象の経路を通っていると確認できて初めて、結果を比較する意味があります。

ダウンロード速度は、ローカル回線、プロキシの入口、国際経路、出口、接続先サーバーなど、経路全体の影響を受けます。測定ツールの単位にも注意してください。メガビット毎秒とメガバイト毎秒は異なる単位です。複数接続による測定では単一接続のボトルネックが見えにくくなるため、ブラウザーやアプリでの実際のダウンロード速度の代わりにはなりません。

時間帯を分けて再現性のある測定を行う

夜間の混雑は、利用者のいる地域の夜だけでなく、回線の入口・出口の地域や接続先サービスの混雑時間帯にも左右されます。現地時間とタイムゾーンを記録し、普段サービスを使う時間帯に測定したうえで、比較用に空いている時間帯の結果も残しましょう。ネットワークが空いているときだけ測って、混雑時間帯も同じ性能だと判断しないでください。

  1. 基準値を記録する。プロキシ接続を切り、ローカルの速度測定と、通常アクセスできる比較用サイトの結果を記録します。未接続ではアクセスできない対象を基準値に無理に含めると、アクセス制限を帯域の差と誤認するおそれがあります。
  2. 経路を確認する。測定する回線に接続し、クライアントの接続ログを確認したうえで、IPアドレス確認で出口を確認します。出口の変化から分かるのは、その確認リクエストの経路が変わったことだけです。測定先への通信にもプロキシのルールが適用されているか確認してください。
  3. ツールを固定する。同じ測定サーバー、同じファイル配信元、または同じウェブページを使います。複数の測定を同時に実行せず、キャッシュやログイン状態もできるだけそろえます。
  4. 交互に測定する。候補の回線を交互に使って測り、先に一方をすべて測ってから、時間を空けてもう一方を測る方法は避けます。複数回確認し、典型的な結果や明らかな異常を記録しましょう。数値のよい結果だけを選んではいけません。
  5. 実際の用途で確認する。普段使うアプリを開き、読み込み、バッファリング、再接続の状況を記録します。速度測定は問題ないのにアプリで不具合が出る場合は、ルール、アカウントの地域設定、接続先サービスの状態も確認しましょう。
  6. 異常を再確認する。ローカルの基準値に戻り、測定先または候補の回線を変えて確認します。結果の変化をもとに原因を絞り込み、すぐにすべての問題をサービス事業者の責任と決めつけないようにしましょう。

以下の項目をローカルのメモにコピーし、測定ごとに記入できます。記録するのはサブスクリプション名だけにし、サブスクリプションURL全体は貼り付けないでください。スクリーンショットを共有する際は、トークンやアカウント情報、その他の認証情報も隠しましょう。

測定日、現地時刻、タイムゾーン:
利用中の通信事業者、接続方法:
端末、クライアント、バージョン:
回線名、プロトコル、出口地域:
プロキシモード、適用ルール:
ツール、測定サーバーまたはファイル配信元:
アイドル時の遅延、負荷時の遅延、ジッター:
応答の欠落、測定方法:
ダウンロード・アップロード速度、表示単位:
ウェブページの読み込み、動画のバッファリング、再接続:
未接続時の基準値、異常の再確認結果:

回線の種類とクライアントの設定

直結、中継、IEPLはそれぞれ異なる階層の仕組みです。直結は一般に、クライアントがサービスの入口へ直接接続する方式です。中継では転送経路が追加され、入口やルーティングの調整に使われます。IEPLは専用線を利用した伝送方式ですが、広告上の表記だけでは端末から接続先サイトまでの全区間が専用線とは分かりません。特に、ローカル回線や出口から接続先までの経路は別途確認が必要です。

中継は必ず遅く、専用線は必ず速いとは言えません。転送区間が増えることで混雑した経路を避けられる場合もあり、専用線でも入口の容量や共有リソース、出口の影響を受けることがあります。比較するときはサービス提供元が示す回線種別を記録し、最終的には同じ条件での実測結果を基準にしてください。回線の地域が近くても、経路が短いとは限りません。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはそれぞれ異なるプロキシプロトコルまたは方式であり、速度の等級ではありません。転送設定、クライアントの実装、ネットワークによるUDPの扱い、端末の性能などで結果は変わります。プロトコルを比較する際は、ほかの条件をできるだけそろえましょう。地域や出口が異なる回線の結果を、プロトコルだけの差として判断することはできません。

WindowsやmacOS向けのクライアントには、システムプロキシやTUNなどのモードが用意されていることがよくあります。iOSやAndroidでは通常、OSのVPNインターフェースを通じて指定した通信を処理しますが、対象範囲はクライアントの設定によって異なります。同じサブスクリプションを別のクライアントに読み込んでも、ルール、DNS、プロトコルの対応状況が異なる場合があります。ログイン後にサブスクリプションを取得し、クライアントの説明に従って読み込み・更新してください。VPNIWのクライアントはアカウントのプラン状況に応じて提供されるため、出所不明の公開インストーラーを探す必要はありません。

ルーティングルールとDNSの影響を確認する

ルールモードでは、速度測定サイトは直接接続され、対象のアプリだけがプロキシを通ることがあります。この場合、「VPN速度」として測った数値は実際にはローカル回線の速度です。クライアントの接続ログを見て、測定ドメインとリクエストに適用されたルールを確認してください。検証のため一時的にグローバルモードに切り替えた場合は、測定後に元の設定へ戻し、モードを変更したことも記録します。

DNSはドメイン名の名前解決を行い、コンテンツ配信ネットワークが選ぶサーバーにも影響することがあります。名前解決に時間がかかると、最初のページ表示は遅くなりますが、その後の継続的なダウンロード速度は下がらない場合があります。比較時はDNSの設定をそろえましょう。ブラウザーのセキュアDNS、システムの名前解決、クライアントのDNS処理が重なることもあるため、実際の経路はクライアントの説明を確認してください。

DNSリークとは、保護された経路を通るはずのDNSクエリが、別のDNSサービスへ送信される状態を指すのが一般的です。検査ページに表示されるDNSサーバー名は手がかりにすぎず、地域や名称だけでリークと断定することはできません。ルーティングルール、ブラウザーの設定、接続ログを合わせて確認してください。IPv6にも注意が必要です。IPv4とは異なる経路が選ばれ、出口の確認結果とアプリの使用感が一致しない場合があります。

測定結果を回線選びに活用する

結果を整理するときは、まず測定目的と時間帯ごとに分類し、中央値、変動、失敗の状況を比較します。ピーク速度が高くても頻繁に途切れる回線は、動画の連続再生に向かない場合があります。一方、ピーク速度が低めでも必要なアプリを安定して使える回線のほうが、日常利用には適していることがあります。単発のピーク値より、実際の用途で快適に使えるかを重視しましょう。

すべての回線と未接続時の基準値が遅い場合は、まずローカル回線を確認します。特定の測定先だけに問題があるなら、接続先サービスとそこまでの経路を調べます。特定の回線だけで異常が繰り返される場合は、回線の切り替えを検討し、測定時刻、回線名、クライアントのバージョン、個人情報を隠した記録をサポートに伝えましょう。「速度が遅い」とだけ伝えるより、原因を特定しやすくなります。

測定では通信量の使い方も考慮しましょう。VPNIWの月額プランは利用開始日を基準に毎月リセットされ、追加のデータパックは使い切るまで期限なく利用できます。継続的な速度測定も同じアカウントの通信量を消費します。また、台数無制限でも同時に通信すれば帯域を取り合うことがあります。利用可能な容量はプランページで確認し、接続の問題はトラブルシューティングガイドで引き続き確認できます。