VPN 速度測定実測比較：自分で実際の速度を測る方法

VPN速度の比較で大切なのは、見栄えのよいダウンロード速度を探すことではなく、自分の環境で実際の通信速度を測ることです。端末や接続方法、測定先、クライアントのモードをそろえて回線を比較し、普段使うアプリでも確かめることで、参考になる結果が得られます。

この記事で紹介するのは測定方法であり、ShunVPNの速度実績ではありません。利用者の回線環境や測定時刻、接続先サーバーが分からなければ、単独の数値だけで使用感は判断できません。ウェブ閲覧、リモートワーク、動画視聴では必要な通信品質も異なるため、単一のランキングで選ぶことはできません。

結果を見る前に、速度測定の指標を区別する

通信速度は一般にダウンロードのスループットを指しますが、ウェブページの読み込み前には、DNS名前解決や接続の確立、暗号化のネゴシエーションも行われます。ダウンロードが速くてもページの応答が速いとは限らず、遅延が小さくても大容量データの転送が安定するとは限りません。用途を決めてから、確認すべき指標を選びましょう。

単位にも注意が必要です。速度測定サイトではMbps、ダウンロードソフトではMB/sがよく使われます。前者はビットレート、後者はバイトレートを示すため、数値をそのまま比較できません。アプリに表示されるダウンロード速度は、プロトコルのオーバーヘッドやキャッシュ、サーバー側の速度制限にも左右されます。

自宅の回線を測り、外部要因を切り分ける

クラウドストレージの同期やOSの更新、ほかの端末での大容量通信をいったん停止します。同じ端末を使い、有線・無線の接続方法もそろえましょう。無線LANを使う場合は測定中に移動せず、場所を固定します。端末の発熱や省電力モード、クライアントのバックグラウンド制限も記録してください。

プロキシを経由しない状態で、国内から正常にアクセスできる測定先を選び、接続回線に問題がないか確認します。この結果は自宅の回線側のボトルネックを見分けるためのもので、国際回線との公平な比較ではありません。国内の測定先と海外の測定先では経路が異なるため、差分をすべてVPNによる速度低下とみなすことはできません。

国内向けの測定結果も大きく変動する場合は、ノードを比較する前にルーターや無線LANの電波、プロバイダーへの接続を確認しましょう。そうしないと、回線を切り替えた後に結果が改善しても、バックグラウンドのダウンロードが終わっただけかもしれず、回線の優劣は判断できません。

測定ツールを選び、通信が対象回線を通っているか確認する

ブラウザーで使えるSpeedtestやFastなどのツールは、スループットの確認に便利ですが、測定先や接続方法が異なる場合があります。自動サーバー選択では、現在の接続出口に近いサーバーが選ばれる傾向があります。ノードの切り替えと同時に測定サーバーも変わると、回線とサーバーの両方の違いが結果に反映されるため、そのまま順位を付けることはできません。

可能であれば、同じ測定サーバーを手動で指定し、サーバー名と地域を記録しましょう。測定先を固定すると比較しやすくなりますが、サーバーの負荷が常に一定とは限らないため、測定を繰り返す必要があります。自動選択での結果も残せますが、固定した測定先の結果とは分けて記録してください。

クライアントに表示される「遅延」が何を測っているかも確認しましょう。プロキシの入口までの接続時間の場合もあれば、プロキシ経由で指定したウェブサイトにアクセスする時間の場合もあります。クライアントごとに測定先や方法、タイムアウトの設定が異なるため、一覧の数値をクライアント間でそのまま比較できるとは限りません。

システムプロキシ・トンネルモード・コマンドラインの違い

システムプロキシの影響を受けるのは、その設定に従うアプリだけです。すべてのプロセスの通信が自動的にプロキシ経由になるわけではありません。TUN系のモードは通常、仮想ネットワークインターフェースを使って対象の通信を取り込みますが、ルーティングや除外リスト、プラットフォームの権限に左右されます。測定前にクライアントの接続ログを確認し、測定先のドメインが対象ノードに振り分けられているか確かめましょう。

通常のpingはICMPを使い、HTTPやSOCKSのシステムプロキシを経由しないことが多いため、直接接続の経路を測定している可能性があります。トンネルモードでも、クライアントがICMPを処理するか確認が必要です。測定先がICMP応答を拒否または制限している場合、応答がタイムアウトしても、実際の通信でパケットロスが発生しているとは限りません。

コマンドラインツールがシステムプロキシに従うかどうかは、OSやツールによって異なります。Windows、macOS、モバイル端末でも通信を取り込む範囲に違いがあります。クライアントに「接続済み」と表示されるだけで、すべての測定がプロキシを経由していると判断せず、接続ログと測定リクエストの出口情報を照合してください。

決まった手順で実測比較する

一度に変更する主な条件は一つに絞りましょう。ノードを比較する際は、端末やクライアント、プロトコル、測定先を同時に変えないでください。クライアントのモードを比較する場合は、同じノードとルール設定を使います。固定できない条件は、結論から省くのではなく記録に明記しましょう。

1. 測定環境を記録。利用中のプロバイダー、端末のOS、クライアントのバージョン、接続方法、測定時間帯、実行中のバックグラウンドタスクを書き留めます。
2. 設定を固定。対象ノードと測定サーバーを決め、プロキシモード、ルールモード、使用プロトコルを記録します。測定中に切り替わらないよう、自動選択をオフにします。
3. 通信経路を確認。クライアントの接続ログを見て、測定リクエストが指定ノードを通り、直接接続や別のポリシーグループに振り分けられていないことを確かめます。
4. 測定を実行。まずアイドル時の遅延を確認してから、ダウンロードとアップロードを測定します。複数のツールで同時に帯域を使い切ると互いに影響するため、避けてください。
5. 繰り返して記録。各回の結果と失敗状況を残し、中央値や変動幅を比較します。最速だったときのスクリーンショットだけを保存するのは避けましょう。
6. 回線を切り替えて再測定。測定先と環境を変えず、候補の回線を交互に測定します。測定順や一時的な混雑による偏りを抑えられます。
7. 実際のアプリで確認。普段の作業を行い、ページの待ち時間や会議中の途切れ、接続の切断と復旧を記録します。

日中の比較的空いている時間帯と、普段利用する夜間の両方で測定するのがおすすめです。あらゆる時間帯を測るのではなく、実際に使う時間をカバーすることが大切です。日をまたいで測定する場合は、おおむね同じ時間帯に行い、特別な事情があれば記録しましょう。空いている時間の最高値だけで、日常の状態を判断するのは避けてください。

測定記録からボトルネックを探り、すぐに回線の順位を決めない

記録には最低限、測定日時、ノード、測定サーバー、クライアントモード、ダウンロード、アップロード、遅延、異常時のメモを含めましょう。集計値だけでなく、各回の結果も残してください。一時的な失敗や自動再接続、測定の未完了も使用感の一部です。記録から黙って除外しないようにしましょう。

アイドル時の遅延は安定しているのに、アップロードやダウンロード中に遅延が大きくなる場合、キューの増加や帯域の使い切りが関係している可能性があります。これは一般にバッファブロートと呼ばれます。自宅のルーターやアクセス回線、経路上の別の箇所で起きることがあり、一度の測定だけでは場所を特定できません。まず同時に行う通信を減らして、変化を確認しましょう。

特定の測定サーバーだけ結果が悪く、ほかの接続先や実際のアプリが正常なら、サーバー側の負荷や接続経路、速度制限を考慮しましょう。すべてのノードで結果が悪い一方、国内向けの測定が正常なら、国際回線の出口やクライアント設定、通信を取り込む経路をさらに確認する必要があります。特定のプロトコルが原因だとすぐに決めつけるのは避けましょう。

Shadowsocks、VMess、Trojan、VLESSなどのプロトコル名だけで速度の順位は決まりません。Hysteria2やTUICはQUICベースの通信を利用するため、ネットワーク環境によって結果が異なる場合があります。また、ローカルネットワークのUDP制限の影響を受けることもあります。実際の速度は実装や設定値、通信経路、サーバーのリソースにも左右されます。

回線の種類とDNSが測定結果に与える影響

直接接続は通常、利用者の接続回線から海外の入口へ直接つなぐ方式です。中継では途中のノードを経由します。IEPL専線は特定の専用伝送区間を指すもので、端末から接続先のウェブサイトまでの全区間が専線とは限りません。入口以降の外部接続や接続先サーバー、自宅のアクセス回線がボトルネックになることもあります。

そのため、ノード名に「専線」とあっても実測の代わりにはならず、地理的に近いノードが必ず最速とも限りません。同じアプリを同じ時間帯に使い、安定して通信できるかを比較しましょう。この記事ではノードごとの回線情報を確認できないため、ShunVPNの個別回線に種類を付記していません。まずサーバーページを確認し、クライアントに表示される実際の情報と照らし合わせてください。

DNSは主にドメイン名の名前解決や、一部のCDN接続先の選択に影響します。名前解決が遅いとページの読み込み開始が遅れることがありますが、接続後のダウンロードスループットが必ず低下するわけではありません。DNSを切り替えて結果が変わった場合も、別のサーバーに名前解決された可能性があります。回線全体が速くなったと単純に解釈しないようにしましょう。

DNSリークとは、名前解決のリクエストが想定した経路を通っていない状態です。確認する際は、クライアントのDNS設定や接続ログ、名前解決の出口情報を照合しましょう。確認ページに見慣れた地域名が表示されるかどうかだけでは判断できません。ブラウザーのセキュアDNS、OSの名前解決、クライアントのルールが影響し合うことがあるため、設定を変更する前に元の状態を保存してください。

速度テストの数値だけでなく、実際の作業で確かめる

ウェブ閲覧では、初回表示とページ内のリソース読み込み、再訪問時の違いを確認しましょう。キャッシュが効いた後にすぐ表示されても、初回アクセスが同じ速さとは限りません。動画視聴では、再生開始までの時間やシーク後の再開、再生中の安定性を確認します。配信サービスは接続出口やアカウント、コンテンツの配信条件に応じて配信先を選ぶため、速度測定の結果だけから特定のコンテンツにアクセスできるとは判断できません。

リモートワークではアップロードや会議の安定性、ファイル同期をあわせて確認しましょう。AIコーディングツールでは、接続の確立とサーバー側の生成待ち時間、ストリーミング応答が途切れないかを分けて考えます。回答の表示開始が遅くても、サーバー側の処理待ちが原因で、通信スループットが不足しているとは限りません。時折出る高いダウンロード速度より、接続が安定して続くことが大切です。

• ✅ 同じ端末・接続方法・測定先を使い、ルールモードを明記する。
• ✅ 失敗や再接続も記録し、普段使う時間帯の継続的な結果で判断する。
• ✅ 速度測定の後は実際の作業で確認し、ネットワークの待ち時間とサーバー側の処理を区別する。
• ❌ ノード一覧の遅延、ブラウザーの速度測定、直接接続のpingを同じ指標として扱わない。
• ❌ 一度の最高値で長期的な性能を判断したり、特定サービスへのアクセスを保証したりしない。

設定に迷ったら、まずクイックスタートに沿って接続し、使い方ガイドでルール設定や接続の問題を確認してください。サポートへ問い合わせる際は、測定時間帯、接続回線、ノード名、個人情報を除いたエラーログを伝えれば十分です。サブスクリプションURLやアカウント情報、接続設定全体は公開しないでください。