プロキシの速度は単一の数値ではありません。レイテンシ（最初のバイトが届くまでの時間）、スループット（バイトが届く速さ）、成功率（利用可能な応答が得られる頻度）から成り、それぞれが時間帯、ターゲット、出口IPによって異なります。 一瞬の単一テストではほとんど何もわかりません。そのため、プロバイダーのマーケティング数値や一回限りのレビューは簡単に作れてしまい、行動に移しにくいのです。これは私たちが独自のランキングで使用している方法です：何を測定するか、どのように、どのくらいの頻度で、そして結果が意味を持つようにどう要約するか。

4つの数値

指標それが示すもの取得方法典型的な良好値
レイテンシ (TTFB)各リクエストがデータ送信開始までに待つ時間curl -w %{time_starttransfer} を小さなリソースに対して実行データセンター: 直接接続比 +10–50 ms; レジデンシャル/モバイル: +80–300 ms
スループット大量データの転送速度固定サイズのダウンロード（1–10 MB）の時間を計測データセンター: 回線速度に近い; レジデンシャル: 5–50 Mbit/s; モバイル: 5–30 Mbit/s
成功率実際の2xx応答が得られる頻度多数のリクエストの結果をカウント中立ターゲットで >98%; 保護されたターゲットでは低いのはターゲット側の要因
稼働時間プロキシが到達可能である頻度数日間にわたる定期的な接続プローブデータセンター/ISPで >99.5%; ローテーションプールは個々の障害を隠す

単一の「速度」数値を示すレポートは、通常、データセンタープロキシの大容量ダウンロードを閑散時間帯に測定したスループットであり、最も好都合な組み合わせです。

コマンドの前の原則

  1. 絶対値ではなく差分を測定する。 常に同じリクエストを直接とプロキシ経由で連続して実行し、その差を報告します。そうしないと、あなた自身の接続の変動がプロキシの変動に混ざってしまいます。
  2. 常に同じターゲットを使用する。 レート制限のない、小さくて高速で安定したエンドポイント（主要CDNの静的ファイルや自前のサーバー）を使用します。スクレイピング対象のサイトをベンチマークに使わないでください。そのサイトのアンチボット応答は別の測定です。
  3. 多数のサンプルを時間をかけて取得する。 1回の実行で少なくとも20リクエスト、1日の中で数時間、1週間にわたって実行します。プロキシは共有インフラであり、負荷はプロバイダーと出口IPの地域のビジネス時間に追従します。
  4. 平均ではなくパーセンタイルで報告する。 30秒のタイムアウトが1回あるだけで平均は壊れます。中央値（p50）は典型的な体験を示し、p95は悪い日の体験を示します。どちらも平均より重要です。
  5. ウォームアップする。 各実行の最初のリクエストは破棄します。DNSとTLSセッションのセットアップにより、他のリクエストより遅くなります。
  6. 一度に1つの変数だけを変更する。 プロバイダーAのデータセンターとプロバイダーBのレジデンシャルを比較するのは、タイプの比較であり、プロバイダーの比較ではありません。

curlによるレイテンシ測定

# 直接
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# プロキシ経由
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

プロキシ経由の場合、time_connectはプロキシに到達するまでの時間です。宛先への接続とTLSはトンネル内で行われ、time_appconnect/time_starttransferに含まれます。比較すべき数値はttfbです。プロキシ経由から直接を引いた値がプロキシの追加レイテンシです。ループで実行するには：

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

スループット測定

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

接続セットアップが全体の小さな割合になる程度の十分な大きさ（5–10 MB）で、かつ多数の実行でGB単位のレジデンシャル許容量を消費しない程度の小ささのファイルを使用します。ローテーションプールでは、スループットは出口ホストの接続によって変動するため、分布を確認するのに十分なサンプルを取得し、GB単位のプランではスループットがコスト消費速度も決定することを忘れないでください。

成功率の測定

各リクエストは次のいずれかで終了します：期待されるサイズのボディを伴う2xx、ターゲットからの4xx/5xx、プロキシエラー（407、接続拒否、タイムアウト）、または200ステータスを伴うチャレンジページ（CAPTCHA/インタースティシャル）。最後のものは単純なカウンターが見逃しがちなので、ステータスコードだけでなくボディも確認してください。Pythonでの例：

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

プロキシの障害（407、接続エラー、プロキシへのタイムアウト）とターゲットの障害（403、429、チャレンジ）を分けてください。前者はプロバイダーの問題であり、後者はそのターゲットに対するIPの評判に関わるもので、別のテストに属します。詳細はアンチボットシステムがリクエストをスコアリングする仕組みを参照してください。

稼働時間の測定

稼働時間は暦時間に対する成功率です。軽量なプローブ（上記のレイテンシコマンド、または単純なCONNECT）を5–15分ごとに少なくとも1週間スケジュールし、結果をタイムスタンプ付きでログに記録し、成功したプローブの割合を計算します。2つの注意点：

  • ローテーションプールは障害を隠します。 1つの出口が死んでも別の出口が得られます。稼働時間を持つのはゲートウェイ自体です。ゲートウェイをプローブし、スティッキーセッションを要求したときに割り当てられたIPがどのくらい頻繁に変わるかを別途追跡してください。予期しない変更はソフト障害です。
  • 静的IP（データセンター、ISP）は通常「99.9%」と主張されます。 99.9%は月あたり43分のダウンタイム、99.5%は3.6時間です。どちらも1週間の15分間隔のプローブで簡単に区別できます。

実行のスケジュール

最小限だが意味のあるスケジュール：レイテンシ+成功率（20–50リクエスト）を出口IPのローカルタイムで03:00、09:00、14:00、20:00に、7日間毎日実行。スループットは各実行で1回。接続プローブは15分ごとに実行。これでプロキシあたり1日あたり数百KB（レイテンシ用）と数十MB（スループット用）になります。GB単位のプランでも小さなファイルを使えば手頃です。常時稼働のマシン（小さなVPSが理想的）でcronを使って実行し、リクエストごとにCSVの1行を書き出します。私たちの公開ランキング（例：速度ランキングや信頼性ランキング）は、まさにこのような1週間のシリーズから構築されており、単発の午後からではありません。

結果の読み方

  • p50レイテンシがタイプの標準に近く、p95がp50の約3倍以内：健全です。p95がp50の何倍もある場合は断続的な輻輳を示し、プロバイダーがピーク時に過剰加入している可能性があります。
  • 中立ターゲットでの成功率が約97%未満で、プロキシ側のエラーが原因の場合：インフラの問題であり、あなたの問題ではありません。
  • 日中が夜間より大幅に悪い：共有キャパシティです。専用オプションを問い合わせるか、スケジュールで許容するかです。
  • 同じプロバイダーでデータセンターは良いがレジデンシャルは悪い：正常です。別製品です。レジデンシャルはレジデンシャルと比較してください。
  • 稼働時間が主張より低い：サポートに提示できるログが手に入ります。これは苦情よりも価値があります。

最後に、タイプを考慮してください。レジデンシャルおよびモバイルプロキシは構造的に遅いです。トラフィックは実際に家庭の回線や携帯電話の塔を経由するためです。速度を目的にこれらを購入するのはカテゴリエラーです。プロキシタイプの比較を参照してください。自分のクラスとタスクの実際の要件に照らして測定してください。また、プロキシ経由の接続はHTTP/2を使用し、HTTP/3ではないため、直接ベースラインがQUIC対応サイトの場合、同じもの同士を比較してください（詳細）。

よくある質問

プロキシの速度をテストするには？

同じ小さなリソースを直接とプロキシ経由で、1日のさまざまな時間に多数回リクエストし、最初のバイトまでの時間（レイテンシ）を比較し、別途固定サイズのダウンロードの時間（スループット）を測定します。平均ではなく中央値と95パーセンタイルを報告してください。

プロキシのレイテンシの良好値は？

直接接続と比較して：データセンタープロキシは数十ミリ秒追加します。レジデンシャルとモバイルは、コンシューマー接続を経由するため、おおよそ80–300 ms追加します。各タイプをその標準に照らして判断してください。

プロキシの稼働時間を確認するには？

スケジュール（5–15分ごと）で少なくとも1週間プローブし、各結果をログに記録し、成功したプローブの割合を計算します。ローテーションプールの場合はゲートウェイを、静的IPの場合はIP自体をプローブします。

結果がプロバイダーの主張と異なるのはなぜ？

主張は通常、最良のケースです：データセンター製品、閑散時間、大容量ダウンロード、単一サンプル。あなたの測定にはピーク時間、受け取る特定の出口IP、パーセンタイルが含まれます。あなたの数値があなたの体験を予測するものです。

スクレイピング対象のサイトに対してベンチマークすべきですか？

速度のためにはすべきではありません。そのサイトのアンチボット層は、IPの評判を測定するチャレンジやブロックを追加し、プロキシのパフォーマンスを測定しません。速度には中立な静的リソースを使用し、評判テストは別途実行してください。

必要なサンプル数は？

安定した中央値を得るには1回の実行で少なくとも20サンプル、時間帯や曜日の効果を見るには1日数回、1週間にわたって実行します。稼働時間は1週間が必要です。