VPN速度の実測比較：速度測定に使うツールと時間帯

測定条件を固定してから速度測定し、回線を比較する

通信は、端末からローカルネットワーク、通信事業者、プロキシの入口、地域間の伝送経路を通り、接続先サーバーに届きます。どこかが混雑すれば測定結果は低下します。速度測定サイトの帯域幅は、そのときの条件で得られたエンドツーエンドの結果であり、事業者が回線に表示する容量でも、すべてのサイトで出る速度でもありません。

まずプロキシを使わずにローカルネットワークの基準値を記録し、Wi-Fiの電波、回線、バックグラウンドの処理がボトルネックになっていないか確認します。特定の海外接続先に直接アクセスできない場合、同じ接続先で基準値を測る必要はありません。アクセス可能な国内の測定先でネットワークの状態を確認できますが、接続先が異なる結果をそのまま「プロキシによる速度低下」と解釈しないでください。

• ✅ 端末、接続ネットワーク、クライアントのバージョンをそろえます。可能であれば有線接続を使い、Wi-Fi環境の変化を抑えましょう。
• ✅ クラウドストレージの同期、システム更新、大容量通信を伴うほかの処理を一時停止し、ほかの端末とネットワークを共有しているか記録します。
• ✅ 測定サーバー、測定モード、プロキシのルールを固定し、測定のたびにツールが接続先を自動変更しないようにします。
• ✅ クライアントの接続ログで、測定用ドメインに適用されたルール、実際の出口、選択した回線を確認します。
• ✅ 失敗、タイムアウト、中断も記録し、最速の結果だけをスクリーンショットに残さないようにします。

回線を比較するときは、選択するノード以外の条件をできるだけ変えないようにします。プロトコルや端末、測定先も同時に変更すると、結果が大きく改善しても原因を特定しにくくなります。ノードの自動選択やフェイルオーバー機能によって、測定中に出口が切り替わることがあります。ポリシーグループ名だけでなく、実際に使われた回線を記録しましょう。

ツールの選び方：スループット、遅延、実際の使用感

ツールによって測定できる内容は異なります。ブラウザーの速度測定は帯域幅の簡易確認に、継続的な計測は応答の変動確認に、実際のダウンロードは日常的な利用状況の確認に向いています。測定サイト固有の回線性能を一般的な結果と誤認しないよう、種類の異なるツールを組み合わせましょう。

速度測定サイトは、帯域幅を使い切るために複数の接続を同時に使うことがあります。一方、実際のファイルダウンロードは単一接続の性能に左右される場合があります。そのため「速度測定は速いのにダウンロードは遅い」という結果だけで、測定の不正を意味するとは限りません。接続方式や配信元の違いが原因のこともあります。それぞれ別に記録し、ひとつの成績にまとめないようにしましょう。

朝・昼・夜に実測：普段使う時間帯を重視

朝・昼・夜に測定するのは、時間帯によるネットワーク負荷の違いを確認するためです。特定の時間が常に代表的な結果になるわけではありません。夜間の混雑は家庭内のブロードバンド回線だけでなく、通信事業者間の接続、サービスの入口、国際出口で発生することもあります。空いている時間帯に速度が出ても、その結果だけで夜間の利用状況を判断することはできません。

1. 普段使う回線と測定先を決め、測定時刻、ローカルネットワークの接続方法、プロキシのモードを記録します。
2. 朝・昼・夜に同じ手順で繰り返し測定します。測定中はほかの速度測定ツールを同時に動かさないようにしましょう。
3. 同じ時間帯に回線を順番に切り替えて測定し、次回は順番を入れ替えます。一時的な負荷変動による順序の偏りを抑えられます。
4. 日をまたいで記録を続け、異常値が出たら再測定します。異常値を削除して平均的な結果だけを報告しないでください。
5. 最後に実際の用途で確認します。動画再生、ウェブページの読み込み、ファイルのダウンロードが同じように安定するかを試しましょう。

測定回数が増えたら、最大値だけでなく中央値、結果のばらつき、失敗状況も確認しましょう。成功した測定と失敗した測定の総数も記録します。接続に失敗することが多い回線でも、少数の成功結果だけを残すと、実際より速く見えることがあります。

最初から複雑なスクリプトを作る必要はありません。日付と時間帯、ネットワーク環境、回線、プロトコル、測定先、帯域幅、遅延、中断の有無、実際の利用感を表計算ソフトに記録すれば十分です。速度測定では多くのデータ通信が発生することがあります。通信量に余裕がない場合は、帯域幅を使い切る測定を繰り返すより、普段使う時間帯と候補の回線を優先して確認しましょう。

指標の見方：帯域幅が速くても応答が安定するとは限らない

ダウンロード帯域幅とアップロード帯域幅

ダウンロード帯域幅は大容量ファイルの取得や動画の読み込みに、アップロード帯域幅はファイル送信、クラウドバックアップ、会議での上り通信に関係します。速度測定サイトでは Mbps、ダウンロードソフトでは MB/s と表示されることがあります。前者はビット、後者はバイト単位のため、数値をそのまま比較できません。実際の利用では、プロトコルのオーバーヘッドやサーバー側の設定も影響します。

アイドル時の遅延・負荷時の遅延・ジッター

通信していないときの応答が速くても、ダウンロード中も快適とは限りません。帯域幅を使い切った際に負荷時の遅延が大きくなると、ウェブ操作、音声通話、リモート操作が滞ることがあります。ジッターは時間経過に伴う遅延の変動を表しますが、計算方法はツールによって異なる場合があります。ツール間で比較する前に定義を確認し、安定性の判断には同じツールで継続して記録するのが適しています。

パケットロス・タイムアウト・再送

パケットロスが続くと再送が発生し、実効スループットが低下することがあります。ただし、測定パケットに応答がない場合、接続先がその種類のリクエストを制限または無視している可能性もあります。業務通信も同じように失われているとは限りません。継続的な測定で異常があり、実際のデータ転送も停止する場合は、問題を示す根拠がより強くなります。一度のタイムアウトは確認が必要な現象として記録し、すぐに特定の区間が原因だと決めつけないでください。

通信の振り分けと DNS：プロキシ経由で測定できているか確認

よくある誤差のひとつは、測定サイトへの通信が直接接続になっている一方、目的のアプリはプロキシ経由になっているケースです。ルールモードでは、ドメインやアドレス、アプリに応じて通信経路が振り分けられます。また、ブラウザーの速度測定と独立したダウンロードソフトでは、システムプロキシの設定が異なることがあります。クライアントの接続ログで測定リクエストを確認し、ネットワーク接続チェックで出口情報も照合しましょう。クライアントが接続済みと表示しているだけでは判断できません。

切り分けでは、クライアントの機能を理解したうえで、一時的に共通の出口を使う設定にして比較し、その後、普段のルールに戻す方法があります。ただし、「グローバルモード」ですべてのプログラムがプロキシ経由になるとは限りません。特にコマンドラインツールは経路の確認が必要です。TUN モードの適用範囲も、ルーティング、権限、設定によって異なります。測定環境を変更した場合は、記録に明記してください。

DNS の名前解決は、初回アクセスの所要時間やコンテンツ配信ノードの選択に影響します。DNS クエリの経路と実際の通信の出口が異なる場合は確認が必要ですが、リゾルバーの所在地だけで情報漏えいと判断することはできません。クライアントの DNS 設定、クエリの経路、測定結果を組み合わせて判断しましょう。同様に、出口 IP アドレスが変わっただけでは、DNS の経路が想定どおりである証拠にはなりません。

速度測定サイトは正常なのに特定のウェブサイトだけ遅い場合は、まず適用されたルール、DNS の結果、接続エラーを確認してから、出口を固定して再測定します。一度に多くのルールを変更すると、どの変更で改善したのか判断しにくくなります。サブスクリプションリンクにはアクセス情報が含まれる場合があるため、調査用のスクリーンショットや記録ではリンクとアカウント情報を隠してください。

回線とプロトコル：名称だけでは性能はわからない

直接接続、中継、IEPL 専線は、通信経路の構成方法を表します。直接接続は一般に、クライアントが海外のサーバーへ直接接続する方式です。中継では入口を経由して転送し、IEPL 専線は専用の伝送区間を使います。専線であっても、家庭内ネットワーク、サービスの入口、接続先サイトがボトルネックになることがあります。回線の種類だけでエンドツーエンドの性能が保証されるわけではありません。

Shadowsocks、VMess、Trojan、VLESS はそれぞれ異なるプロキシプロトコルです。Hysteria2 と TUIC は QUIC ベースの伝送方式を使用します。実際の性能は、クライアントの実装や設定、端末の負荷、ネットワーク側の UDP 処理、サーバーの環境によって変わります。プロトコル名だけで「最速」とは判断できず、同じプロトコルを使う回線同士でも大きな差が出ることがあります。

複数のプラットフォームを比較する際は、通信の取り込み方法も考慮しましょう。デスクトップではシステムプロキシや TUN、モバイルでは OS が提供するネットワーク拡張機能を使うことがあります。同じサブスクリプションを別のクライアントに読み込んでも、ルール、DNS、プロトコルの対応状況が一致するとは限りません。回線を比較する場合は、プラットフォームとクライアントを固定しましょう。インストールや設定の読み込みについては、使い方ガイドを参照してください。

結論をまとめる：測定条件も失敗結果も残す

信頼できる結論は、「この端末、このネットワーク、この時間帯では、特定の回線がこの用途に適していた」のようにまとめます。特定のサービスが常に最速だと断定するのは避けましょう。測定範囲を記録し、失敗した結果も残したうえで、未検証の地域、プラットフォーム、アプリを明記します。後日状況が変わったとき、比較の基準になります。

すべての回線が同時に遅くなった場合は、まずローカルネットワークと共通の接続先を確認します。特定の回線だけに問題があるなら、その入口と出口を調べましょう。特定のアプリだけが遅い場合は、ルーティング、名前解決、サーバー側の制限を確認します。影響範囲に沿って段階的に原因を絞るほうが、ノードを頻繁に切り替えるより再現性のある答えを得やすくなります。

普段の用途に合うメイン回線と予備回線を選び、よく使う時間帯に定期的に確認しましょう。速度測定は回線選びやトラブル調査のための手段であり、利用体験そのものではありません。実際の用途で安定して使え、失敗の原因も説明できているなら、スクリーンショットの最高速度を追い続ける必要はありません。