宣伝数字をそのまま信じられない理由
同じ端末・同じ回線でも、時間帯を変えて測るだけで数字が倍近く変わることがあります。測定結果は少なくとも5つの変数に左右されます。自宅回線の実際の出口、測定する時間帯の混雑具合、スピードテストサーバーの設置場所、プロキシプロトコルと暗号化によるオーバーヘッド、そしてクライアントのルーティングルールが測定トラフィックを本当にプロキシ経由にしているかどうかです。
宣伝ページの数字は、たいてい最も条件の良い一回から取られています。近くの測定ノード、空いている時間帯、マルチスレッドで束ねたピーク値です。それが答えているのは「この経路が理想的な条件でどれだけ出るか」であって、「夜9時に動画を開いても止まらないか」ではありません。自分で測る価値は、実際の利用条件を固定して、時間帯や回線ごとの違いを観察できる点にあります。
測定の前に環境を整えます。OSのアップデート、クラウドストレージの同期、他の端末の動画やダウンロードを止めてください。同じネットワーク上で1台でも大容量通信をしていると、測定値は低く出ますし、どれだけ低く出るかは見積もれません。
測定ツールの選び方：3層に分けて組み合わせる
すべての疑問に一度に答えてくれるツールはありません。「まず基準を取る、次に問題の箇所を特定する、最後に実際の利用シーンに戻る」という順で3層に分ければ、日常的な判断にはほぼ十分です。
第1層：Webスピードテストで、まず素早く基準を取る
Speedtest by Ookla、Fast.com、Cloudflare Speedtest はこのカテゴリです。開けば下り・上り・遅延が出ます。使い方で押さえる点は1つだけ。測定サーバーを手動で選び、比較のたびに同じサーバーを使うことです。自動推薦はネットワーク状況に応じてサーバーを変えるため、前後の数字を比べられなくなります。
第2層：コマンドラインツールで、問題がどの区間にあるかを特定する
ping と mtr は遅延・ジッター・ホップごとのパケットロスを担当し、iperf3 は生のスループットと長時間の安定性を担当します。curl の -w オプションを使えば、DNS 解決・TCP 接続・TLS ハンドシェイク・最初のバイトまでの4段階の所要時間を個別に出力できます。「Webページが遅い」ときに、どの段階で遅いのかが一目でわかります。
# 遅延とジッター：20回連続で ping し、最大値と最小値の差に注目
ping -c 20 example.com
# ホップごとのパケットロス：問題が自宅回線・国際出口・相手側のどこにあるかを特定
mtr -rwzbc 50 example.com
# 段階ごとの所要時間：名前解決・接続・ハンドシェイク・最初のバイトにどれだけかかったか
curl -o /dev/null -s -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s\n" https://example.com第3層：実際の利用シーンでの測定
よく使う大容量ファイルの配布元から一度ダウンロードする、あるいは動画をしばらく再生してバッファリング回数を記録します。この方法に見栄えのする数字はありませんが、日常の体感に最も近いものです。動画が止まるかどうかの判断では、マルチスレッドの合計値よりもシングルスレッドの結果のほうが参考になります。
マルチスレッド測定は複数の接続の速度を合計するため、表示される数字は通常、単一アプリが実際に使える帯域より大きくなります。Webページ、動画ストリーミング、単一のダウンロードはほとんどがシングルスレッドか限られた数の接続なので、2つの数字は分けて見て、分けて記録してください。
| ツール | 主に測るもの | 向いている場面 | 注意点 |
|---|---|---|---|
| Speedtest（Ookla） | 下り・上り・遅延 | 手早い基準取り、回線切り替え前後の比較 | 同じ測定サーバーを手動で固定する |
| Fast.com | 下りの帯域と遅延 | ストリーミング方向の帯域を見る | 上りは測れない。ジッターとパケットロスは別途測定 |
| Cloudflare Speedtest | 帯域・遅延・ジッター | 手早くジッターを見る | ノードは相手側のネットワーク次第で、自分では選べない |
| ping / mtr | 遅延・ジッター・ホップごとのパケットロス | 経路のどの区間で問題が出ているかを特定 | 宛先アドレスが必要。ICMP はレート制限されることがある |
| iperf3 | 生のスループット・長時間の安定性 | 自前ノード・継続的なトラフィック流し | 両端の用意が必要で、ハードルは高め |
| curl -w | 名前解決・接続・ハンドシェイク・最初のバイトの所要時間 | 「Webページが遅い」原因がどの段階か調べる | コマンドライン出力。各段階の意味を理解している必要がある |
時間帯の組み方：昼間と夜のピークの比較
少なくとも2つの時間帯を取ります。1つは自宅回線が空いている時間帯（平日の午前または午後）、もう1つは夜のピーク（20:00〜23:00）です。同じノード、同じツールで、各時間帯を1分以上の間隔を空けて3回連続で測り、ピーク値ではなく中央値を取ります。週末の夜のピークは平日より混み合うのが普通なので、より正確に見たい場合は週末の比較をもう1セット追加してください。
国をまたぐアクセスでは、相手側のタイムゾーンも考慮に入れます。こちらが深夜でも、相手側は業務のピークということがあります。回線タイプの差が最もはっきり出るのがこの場面です。直結回線と中継回線は公衆インターネットの国際出口を通るため、夜のピークの変動が大きくなります。IEPL 専用線は独立したチャネルを通り、公衆インターネット出口の混雑を受けないので、昼間とピークの数字が近くなるのが一般的です。この比較こそ、1回の測定結果よりも回線品質をよく示します。
スピードテストサイトのサーバーは、多くが CDN のエッジに接続されています。測定用ドメインが直結ルールにマッチしていると、測っているのは自宅回線から CDN までの速度で、プロキシ回線とは関係がありません。測定前にルーティングルールを確認するか、一時的にグローバルモードに切り替えてください。
3つの指標：遅延・ジッター・パケットロスの読み方
帯域の数字が最も目立ちますが、体感を決めているのは多くの場合、残りの3つです。3つはつなげて見る必要があり、1つの数字だけでは何も言えません。
遅延（RTT）：絶対値ではなく差を見る
単位はミリ秒です。国をまたぐアクセスは遅延が本質的に大きくなるため、比較のポイントは2つの差になります。直結の基準値との差（プロキシと回線が持ち込むオーバーヘッド）、そして夜のピークと昼間の差（経路が混雑しているか）です。同じ回線で夜のピークに遅延がはっきり増え、ジッターも同時に上がるなら、共有出口を通っているとほぼ判断できます。
ジッター：リアルタイム音声・映像の生死を分けるライン
ジッターは隣り合う2回の遅延の差で、経路が安定しているかどうかを表します。音声通話、ビデオ会議、対戦型ゲームが最も敏感で、平均遅延がどれだけ低くても、ジッターが大きければ途切れやカクつきが起きます。コマンドラインで20回連続 ping し、平均値を見るより最大値と最小値の差を見るほうがはるかに役立ちます。
パケットロス：最も見落とされやすく、影響は最も直接的
数パーセントのパケットロスでも TCP は何度も再送を繰り返し、体感としてはページが回り続け、プログレスバーが動かない状態になります。QUIC ベースのプロトコル（Hysteria2、TUIC）は TCP ベースのプロトコル（Shadowsocks、VMess、Trojan、VLESS）よりロスのある経路に強い代わりに、帯域の消費が大きく、UDP 転送の品質が求められます。
DNS 解決も見落としやすいポイントです。クライアントの DNS リクエストがプロキシ経由になっていないと、ローカルのリゾルバが遠回りの入口を返すことがあり、接続確立が遅い、最初のバイトが遅いという形で現れます。一方、帯域のテストでは問題が見えません。curl で各段階の所要時間を出力し、time_namelookup が明らかに大きければそれがサインです。
| 指標 | 単位 | 測り方 | 数値が大きくなると何が起きるか |
|---|---|---|---|
| 遅延 RTT | ミリ秒 | ping、mtr、スピードテストサイト | 経路が長くなるか混雑し、操作の反応が遅くなる |
| ジッター jitter | ミリ秒 | 連続 ping の最大値と最小値の差 | リアルタイム音声・映像の途切れ、カクつき |
| パケットロス loss | パーセント | mtr のホップ別統計、ping 統計 | 再送が増え、ダウンロードとWebページが明らかに遅くなる |
| 下り／上り帯域 | Mbps | Speedtest、iperf3、大容量ファイルのダウンロード | 大容量ファイルと動画の解像度の上限を決める |
| DNS 解決の所要時間 | ミリ秒 | curl -w の time_namelookup | 解決が遠回りし、最初の表示と接続確立が遅くなる |
再現できる測定手順
以下の順番で変数を1つずつ固定していきます。一度通せば30分ほどで、得られた結果はそのまま横並びで比較できます。
- 変数を固定する。同じ端末、同じ測定サーバー、同じ回線、同じプロトコル。どれか1つでも変わったら、比較はやり直しです。
- まず環境を整える。バックグラウンドのダウンロード、OSのアップデート、クラウド同期を止めます。可能なら Wi-Fi ではなく有線 LAN を使い、Wi-Fi を使う場合は同じ場所に固定します。
- 直結の基準を測る。プロキシを切り、下り・上り・遅延・ジッター・パケットロスを記録します。基準のない数字には比較対象がありません。
- 回線の性能を測る。プロキシを有効にし、測定用ドメインがプロキシ経由になっていることを確認して（グローバルモード、または測定用ドメインをプロキシルールに追加）、1分以上の間隔を空けて3回連続で測り、中央値を取ります。
- 時間帯を変えて繰り返す。昼間を1セット、夜のピークを1セット、それぞれ記録し、2セットの差がどれくらいかを重点的に見ます。
- 回線を変えて比較する。同じ地域の直結・中継・IEPL 専用線をそれぞれ1セットずつ測ります。変えるのは回線だけで、他の条件はすべて動かしません。
- 記録して残す。日付・時間帯・回線・プロトコル・下り・上り・RTT・ジッター・パケットロスの9列で表にまとめ、1週間後に傾向を見ます。
この手順で最も省略されやすいのが3番目と7番目です。基準がなければ、プロキシと回線がどれだけのオーバーヘッドを持ち込んでいるかは判断できません。傾向を記録しなければ、1回の結果だけで結論を出すことになります。
結果の読み方：よくある誤った判断
数字が出たあと、それをどう読むかも同じくらい重要です。以下のような判断の仕方は、結果の比較可能性を失わせたり、別の層の問題を混ぜてしまったりします。
- ❌ 1回のピーク値を安定値とみなす：未明に測った高い値は、夜のピークでも維持できることを意味しません。
- ❌ ルーティングルールを確認せずに結論を出す：測定用ドメインが直結を通っていれば、2組の数字はそもそも同じ経路を測っていません。
- ❌ 下りだけ測って上りを測らない：ビデオ会議、クラウドストレージへのアップロード、リモートデスクトップは上りの帯域を使います。
- ❌ 測定サーバーの遅延をWebページの表示速度と同一視する：名前解決、ハンドシェイク、最初のバイトと各段階が積み重なるので、帯域がどれだけ高くても取り戻せません。
- ✅ 変数を固定し、3回繰り返して中央値を取り、そこから夜のピークが昼間に対してどれだけ落ちるかを見る。これが唯一、横並びで比較できる読み方です。
- ✅ 1週間の傾向を記録する：回線品質は分布であって、1回の成績ではありません。
測定が答えるのは「どこが一番速いか」ではなく、「自分のネットワークの中で一番遅いのはどの区間か」です。変数の固定、時間帯の比較、繰り返し測定の3つを押さえれば、宣伝の数字を信じる価値があるか、この回線が夜のピークに耐えられるかは、自分で答えを出せます。
1回測ってみて、ボトルネックが自宅回線や測定サーバーではなく、夜のピークの国際出口に安定して現れるなら、それは回線タイプの問題です。公衆インターネット出口の混雑を受けない回線に切り替えるほうが、同じ数字を何度も測り直すより意味があります。VPNEQ は100+ の国と地域、210+ の回線を用意し、地域ごとにグループ化して複数回線を冗長化しています。Windows、macOS、iOS、Android、Linux に対応し、同時接続台数は無制限。比較表に加える参照回線として使えます。