“どれくらい速いか” は、レジデンシャルプロキシについて最初に問うべき質問ではありません。200ミリ秒で応答してもブロックされることが半分あるプロキシは使い物になりませんし、多少遅くても毎回本物のページを返すプロキシこそが求めるものです。プロバイダーを信頼する前に、あるいはスクレイパーの性能が低い理由を調べる前に、客観的に測定すべき3つの指標があります。成功率、レイテンシの分布、そして位置の正確性です。このガイドでは、それぞれについてそのままコピーして使えるテストを示し、同じくらい重要な、数字を読み違えないための読み方も解説します。
以下はすべてShifterのレジデンシャルゲートウェイ(単一のエンドポイント p.shifter.io:443、ターゲティングはユーザー名にエンコード)に対して実行しますが、テスト自体はプロバイダーに依存しません。ホストと認証情報を差し替えれば、どこでも動作します。例はPythonで書かれており、クライアントのセットアップはPythonでのレジデンシャルプロキシPythonの使い方に準じています。
本当に重要な3つの指標
生の速度は人々がこだわりがちな指標ですが、単体で見ると最も役に立ちません。レジデンシャルIPは実際の消費者デバイスを経由するため、データセンターに比べて多少遅くなるのは当然のことであり、欠陥ではありません。実際にプロキシが自分の用途に適しているかどうかを決めるのは以下の要素です。
- 成功率 - 送信したリクエストのうち、何件が(ブロックやCAPTCHA、エラーではなく)本物のページを返したか。この数字が、データパイプラインが完全かどうかを決めます。
- レイテンシの分布 - 平均値ではなく、ばらつきです。p95とテール部分が、遅いリクエストがどれだけ悪化するかを示し、これがスケール時に問題になる部分です。
- 位置の正確性 - 国や都市をターゲティングした時、出口IPは実際にそこに解決されるか。ジオターゲティングを使うユースケースでは、位置が間違っているデータは静かに間違ったデータになります。
この3つすべてを測定してください。単一の数字、特に平均速度は、重要な問題を隠してしまいます。
セットアップ
認証情報は環境変数に保管し、ターゲティングされたプロキシURLを組み立てるヘルパーを1つ定義します。
import os, time, statistics, requests
USER = os.environ["SHIFTER_USER"]
PASS = os.environ["SHIFTER_PASS"]
GATEWAY = "p.shifter.io:443"
def proxy(country="us", city=None, sid=None, ttl=600):
parts = [USER, "country", country]
if city: parts += ["city", city]
if sid: parts += ["sid", sid, "ttl", str(ttl)]
url = f"http://{'-'.join(parts)}:{PASS}@{GATEWAY}"
return {"http": url, "https": url}まず、実際にプロキシを経由しているかどうかを確認してください。「プロキシが遅い」という報告の驚くほど多くは、実はローカルマシンから一度も出ていないトラフィックだったりします。
r = requests.get("https://api.ipify.org?format=json", proxies=proxy("us"), timeout=30)
print(r.json()) # レジデンシャルIPであるべきで、自分自身のIPではないはずテスト1: 位置の正確性
国(必要なら都市も)をターゲティングし、geo-IPエンドポイントに出口IPがどこにあるかを尋ね、多数のサンプルで一致率を測定します。プール全体をサンプリングするために(sidを指定せず)リクエストごとにローテーションさせてください。単一のIPだけを見ることのないようにします。
def test_geo(country="us", n=50):
hits = 0
for _ in range(n):
try:
r = requests.get("http://ip-api.com/json", proxies=proxy(country), timeout=30)
data = r.json()
if data.get("countryCode", "").lower() == country.lower():
hits += 1
except requests.RequestException:
pass
print(f"{country}: {hits}/{n} = {hits/n:.0%} country-accurate")
test_geo("us")
test_geo("de")読み方。 国レベルの正確性は非常に高いはずです(90%台後半をイメージしてください)。都市レベルの正確性は本質的に曖昧です。geo-IPデータベースは、あるIPがどの都市に属するかについて見解が一致しないことがあるため、「不一致」はプロキシが間違った場所に送っているのではなく、データベース同士の見解の相違である可能性があります。誤った結論を避けるための2つの注意点として、可能であればターゲットサイトが使っているのと同じgeo-IPソースに対して都市レベルの正確性をテストすること、そして単一のルックアッププロバイダーを絶対の正解として信用しないことが挙げられます。
テスト2: 分布として測定するレイテンシ
多数のサンプルにわたってリクエストの合計時間を測定し、平均値ではなくパーセンタイルを報告してください。平均は、スケール時に問題となる遅いテール部分をまさに平滑化してしまいます。
def test_latency(country="us", n=50, url="https://api.ipify.org"):
times = []
for _ in range(n):
start = time.perf_counter()
try:
requests.get(url, proxies=proxy(country), timeout=30).raise_for_status()
times.append((time.perf_counter() - start) * 1000) # ms
except requests.RequestException:
pass
times.sort()
p = lambda q: times[min(len(times)-1, int(q*len(times)))]
print(f"n={len(times)} p50={p(0.5):.0f}ms p95={p(0.95):.0f}ms max={times[-1]:.0f}ms")
test_latency("us")読み方。 p50とp95を比較してください。ばらつきが小さい(p95がp50に近い)場合は予測可能な性能を意味し、p95がp50の何倍にもなる場合は、並行して動くワーカーを止めてしまう重いテールがあることを意味します。プロキシ自体のオーバーヘッドとターゲット側の遅さを切り分けるには、同じテストを(IPエコーのような)高速で中立的なエンドポイントと、実際のターゲットの両方に対して実行してください。差分がおおよそターゲット自体のレイテンシです。そして、レジデンシャルのp50とデータセンターのp50を同じ製品であるかのように比較しないでください。レジデンシャルは設計上、実デバイスを経由するホップを追加します(レジデンシャルプロキシとデータセンタープロキシの比較を参照)。
テスト3: 最も重要な成功率
実際のターゲットに対してリクエストを実行し(成功はターゲットごとに固有です)、それぞれの結果を分類します。ここでの落とし穴はHTTPステータスを信用することです。200 OKであっても、200で返されるCAPTCHAや「確認してください」ページのようなソフトブロックである可能性があります。そのため、コードだけでなくコンテンツを検証してください。
def looks_like_real_page(html):
# 自分のターゲットに合わせて調整すること: 期待するマークアップの有無、ブロックマーカーの有無。
block_markers = ("captcha", "are you a robot", "access denied", "unusual traffic")
low = html.lower()
return len(html) > 1000 and not any(m in low for m in block_markers)
def test_success(url, country="us", n=100):
ok, soft_block, errors = 0, 0, 0
for _ in range(n):
try:
r = requests.get(url, proxies=proxy(country), timeout=30)
if r.status_code == 200 and looks_like_real_page(r.text):
ok += 1
else:
soft_block += 1 # 200なのにブロック、403/429/503 など
except requests.RequestException:
errors += 1 # タイムアウト、接続失敗
print(f"success={ok/n:.0%} blocked={soft_block/n:.0%} errors={errors/n:.0%}")
test_success("https://your-target.example/page", country="us")読み方。 成功率はスクレイピングにおける最重要指標であり、使えるデータを返したリクエストの割合です。失敗をブロックされた(ターゲットに拒否された)とエラー(ネットワーク/タイムアウト)に分けてください。それぞれ対処法が異なるためです。継続的なブロックはIPの品質やリクエストの挙動を示唆し(スクレイパーがブロックされる理由)、エラーはタイムアウトや過度に厳しいジオフィルターを示唆します。リクエストごとのローテーションとリトライループは実質的な成功率を引き上げるため、それが本番での運用方法であれば、生の値(1回のみ)とリトライありの両方を測定してください。
まとめ
最小限のハーネスは3つすべてを実行し、1つのレポートを出力します。
if __name__ == "__main__":
for cc in ("us", "de", "gb"):
print(f"\n== {cc.upper()} ==")
test_geo(cc, n=50)
test_latency(cc, n=50)
test_success("https://your-target.example/page", country=cc, n=100)以下の順番で読んでください。まず成功率(そもそもデータが返ってきているか)、次にレイテンシのテール(並行処理に耐えられるか)、最後にジオの正確性(それは正しいデータか)。p50で勝っていても成功率で負けているプロバイダーは、スクレイピングには不向きな選択です。
誤解を招く数字を生む、よくある落とし穴
- 平均レイテンシを報告する。 パーセンタイルを使ってください。並行処理のジョブを壊すのはテール部分です。
- ステータス200を信用する。 ソフトブロックはCAPTCHAページとともに200を返します。コンテンツを検証してください。
- サンプル数が少なすぎる。 5件のリクエストでは何もわかりません。分布とテールを見るために十分な数(50から100以上)を使ってください。
- ジオの正解データが誤っている。 異なるgeo-IPデータベースは見解が一致せず、特に都市レベルでその傾向が顕著です。ターゲットが使っているソースに対してテストし、都市レベルの正確性は本質的に国レベルより曖昧であるものとして扱ってください。
- レジデンシャルとデータセンターを生の速度で比較する。 これらは別々の製品です。レジデンシャルは、防御されたターゲットに対する実ユーザーの信頼性と高い成功率のために、多少のレイテンシを犠牲にしています(スクレイピングにどちらのプロキシが良いか)。
- プロキシを経由しているかを確認していない。 何かをベンチマークする前に、出口IPが変わったことを確認してください。
責任を持って実施することについての注意
自分がアクセスを許可されているエンドポイント、速度とジオの測定には公開のIPエコーサービス、成功率の測定には自分が権限を持つターゲットに対してベンチマークを行ってください。サンプル数は妥当な範囲に保ち、測定のためにサイトに過度な負荷をかけないこと、そしてレート制限を守ってください。Shifterで許可される内容についての正式な情報源は、利用規約です。
よくある質問
レジデンシャルプロキシにとって良い成功率とは? それは完全にターゲット次第です。しっかり防御されたサイトは、オープンなサイトよりも多くブロックします。重要なのは、自分のターゲットに対して測定し、同じターゲットでプロバイダーを比較することです。失敗をブロックとエラーに分けることで、何を直すべきかがわかります。
なぜ自分のレジデンシャルプロキシはデータセンタープロキシより遅いのか? 実際の消費者デバイスを経由するため、そのホップが設計上レイテンシを追加するからです。これは、データセンターIPをブロックするサイトにおける実ユーザーの信頼性と高い成功率と引き換えのトレードオフです。レジデンシャルは、データセンターとの生のp50比較ではなく、成功率とレイテンシの分布で判断してください。
都市レベルの位置の正確性はどうテストすればよいか? 都市をターゲティングし、理想的にはターゲットが使っているのと同じgeo-IPソースに対して出口IPを確認してください。geo-IPデータベースは都市の境界について見解が一致しないため、国レベルの正確性は非常に高く、都市レベルの正確性はより曖昧になると想定してください。都市レベルのターゲティングが重要になる場合を参照してください。
なぜ200のレスポンスが失敗としてカウントされることがあるのか? サイトが200ステータスとともにソフトブロック、CAPTCHAや「あなたが人間であることを確認してください」ページを返すことがあるためです。ステータスコードだけを確認していると、ブロックを成功として記録してしまいます。コンテンツが本物のページの見た目と一致しているかを検証してください。
ローテーティングとスティッキー、どちらのセッションでテストすべきか?
作業内容によって両方です。ローテーティング(sidなし)はプールをサンプリングし、幅広いスクレイピングに向いています。スティッキー(スティッキーとローテーティングの比較)は、複数ステップのフローをテストします。実際に本番で使うモードを測定してください。
結論
レジデンシャルプロキシを適切にテストするということは、それを単一の速度の数字に縮小することを拒否することを意味します。コンテンツ検証を伴う成功率を実際のターゲットに対して測定し、レイテンシはp95のテールに目を向けた分布として測定し、位置の正確性は妥当なgeo-IPの正解データを使って測定すれば、マーケティングの数字から推測するのではなく、プロバイダーが実際に自分の用途に合っているかどうかがわかります。この3つすべてを左右するのはプールの品質なので、IPレピュテーションを理解しておくと、結果を解釈する助けになります。
プロバイダーをベンチマークしている場合でも、自分の成功率をデバッグしている場合でも、これらのテストをレジデンシャルゲートウェイと自分の選んだターゲットに対して実行してください。価格ページには、自分にとって重要な市場やサイトに対して試すためのGBあたりのプランがあります。