レジデンシャルプロキシは私たちが販売しているものなので、それが不要な場合について書くのは奇妙に思えるかもしれません。しかし、あらゆる作業のためにプロキシを購入するチームは過剰な支出をしており、あらゆる失敗をプロキシのせいにするチームは何週間も無駄にしています。どのサイトがレジデンシャルIPを必要とし、どのサイトが何も必要とせず、どのサイトがまったく別のものを必要とするかを知ることは、ウェブデータ収集における最も安上がりな最適化です。
これを具体的に示すため、小規模なテストを実施しました。2026年10月9日、データセンターIPアドレスを持つクラウドサーバーから30の公開ページをそれぞれ3回ずつリクエストし、次に米国の出口を持つShifterのレジデンシャルプロキシを通じて同じことを行いました。どちらの実行も同じシンプルなPython HTTPクライアントを使用しました。30ページ中16ページは、データセンターIPから毎回成功しました。3ページはレジデンシャルの出口を通してのみ成功しました。残りの11ページはどちらの方法でも失敗しましたが、これはレジデンシャルIPでは解決しない理由によるものです。
テスト内容
対象には6種類のサイトが含まれていました。公開APIとオープンデータ、リファレンスおよびドキュメントサイト、ニュースのホームページ、eコマースの検索ページ、旅行の検索ページ、そしてソーシャル、求人、検索ページ群です。各リクエストは同じデスクトップブラウザのUser-Agentを使用し、ステータスコードだけでなく実際のコンテンツが取得できたかを確認しました。応答は、検索結果カードのような、実際のコンテンツにのみ現れるマーカーを含んでいる場合にのみ成功とカウントしました。したがって、よくあるステータス200を返すブロックページは失敗としてカウントされます。
マーカーは、最終実行前に両方のネットワークから保存した応答を調べることで選定し、実際のコンテンツなのかログインウォールや空のJavaScriptシェルなのか判別できなかった5つの候補ページは除外しました。
| カテゴリ | サイト | データセンターIP | レジデンシャルの出口 | 判定 |
|---|---|---|---|---|
| 公開APIとオープンデータ | en.wikipedia.org | 3 of 3 | 3 of 3 | プロキシ不要 |
| 公開APIとオープンデータ | api.github.com | 3 of 3 | 3 of 3 | プロキシ不要 |
| 公開APIとオープンデータ | data.sec.gov | 3 of 3 | 3 of 3 | プロキシ不要 |
| 公開APIとオープンデータ | api.worldbank.org | 3 of 3 | 3 of 3 | プロキシ不要 |
| 公開APIとオープンデータ | ecb.europa.eu | 3 of 3 | 3 of 3 | プロキシ不要 |
| リファレンスとドキュメント | docs.python.org | 3 of 3 | 3 of 3 | プロキシ不要 |
| リファレンスとドキュメント | developer.mozilla.org | 3 of 3 | 3 of 3 | プロキシ不要 |
| リファレンスとドキュメント | rfc-editor.org | 3 of 3 | 3 of 3 | プロキシ不要 |
| リファレンスとドキュメント | en.wikipedia.org | 3 of 3 | 3 of 3 | プロキシ不要 |
| リファレンスとドキュメント | arxiv.org | 3 of 3 | 3 of 3 | プロキシ不要 |
| リファレンスとドキュメント | stackoverflow.com | 0 of 3 | 0 of 3 | どちらもブロック |
| ニュース | bbc.com | 3 of 3 | 3 of 3 | プロキシ不要 |
| ニュース | reuters.com | 0 of 3 | 0 of 3 | どちらもブロック |
| ニュース | nytimes.com | 0 of 3 | 0 of 3 | どちらもブロック |
| ニュース | theguardian.com | 3 of 3 | 3 of 3 | プロキシ不要 |
| ニュース | edition.cnn.com | 3 of 3 | 3 of 3 | プロキシ不要 |
| ニュース | bloomberg.com | 0 of 3 | 0 of 3 | どちらもブロック |
| eコマース検索 | amazon.com | 3 of 3 | 2 of 3 | プロキシ不要 |
| eコマース検索 | walmart.com | 0 of 3 | 3 of 3 | レジデンシャルIPが必要 |
| eコマース検索 | ebay.com | 0 of 3 | 0 of 3 | どちらもブロック |
| eコマース検索 | bestbuy.com | 0 of 3 | 0 of 3 | どちらもタイムアウト |
| eコマース検索 | etsy.com | 0 of 3 | 0 of 3 | どちらもブロック |
| 旅行 | booking.com | 0 of 3 | 2 of 3 | レジデンシャルIPが必要 |
| 旅行 | expedia.com | 0 of 3 | 0 of 3 | どちらもブロック |
| 旅行 | airbnb.com | 3 of 3 | 2 of 3 | プロキシ不要 |
| 旅行 | tripadvisor.com | 0 of 3 | 0 of 3 | どちらもブロック |
| 旅行 | kayak.com | 0 of 3 | 3 of 3 | レジデンシャルIPが必要 |
| ソーシャル、求人、検索 | linkedin.com | 3 of 3 | 3 of 3 | プロキシ不要 |
| ソーシャル、求人、検索 | indeed.com | 0 of 3 | 0 of 3 | どちらもブロック |
| ソーシャル、求人、検索 | google.com | 0 of 3 | 0 of 3 | ブラウザが必要 |
「どちらもブロック」とは、単純なHTTPクライアントが両方のネットワークからブロックされたことを意味します。実際のブラウザやブラウザチェックを処理するスクレイピングAPIであれば、これらのサイトでも成功する可能性は十分にあります。このテストでは試していません。
結果が示すこと
公開API、オープンデータ、ドキュメントにはプロキシは不要です。 試したすべてのAPIとリファレンスページは、1つを除いて、毎回データセンターIPから成功しました。これらのサービスはプログラムによって使われることを前提に構築されています。求められるのは、わかりやすいUser-Agent、適切なリクエストレート、そして一部ではAPIキーです。プロキシはコストを追加するだけで、他には何ももたらしません。
多くの大規模サイトはデータセンターIPをまったくブロックしません。 6つのニュースホームページのうち3つ、Amazonの検索、Airbnbの検索、LinkedInの企業ページは、クラウドサーバーに3回中3回実際のコンテンツを提供しました。このようなサイトからの少量の収集であれば、プロキシなしで始めるのは妥当です。ただし、サイトの利用規約とレート制限の範囲内であることが条件です。
IPの評判によってブロックするサイトもあり、そこでこそレジデンシャルの出口が重要になります。 Walmart、Kayak、Booking.comは毎回データセンターIPを拒否し、レジデンシャルの出口を通してコンテンツを提供しました。これらのサイトはリクエストがどのネットワークから来たかをスコアリングしており、クラウドサーバーのアドレスは低いスコアになります。これはレジデンシャルプロキシが存在する理由そのものの事例です。
IPではなくクライアントをブロックするサイトもあります。 eBay、Etsy、Expedia、Tripadvisor、Indeed、Stack Overflow、そして3つのニュースサイトは、単純なPythonクライアントを両方のネットワークからブロックしました。これらは、どこから来たかを見る前に、クライアントがどのように接続し振る舞うか、たとえばTLSフィンガープリント、HTTPヘッダー、JavaScriptを実行するかどうかをチェックします。レジデンシャルIPは、自らをスクリプトだと示してしまうクライアントの問題を解決しません。TLSとHTTP/2フィンガープリンティングに関する当社のガイドで、これらのチェックの仕組みを解説しています。
ネットワークに関係なくブラウザが必要なページもあります。 Google検索は、両方のネットワークに対してJavaScriptを要求するページを返し、HTMLには結果がありませんでした。このようなページでは、ヘッドレスブラウザを使うか、データを直接返すAPIを使うかという選択になります。
サイトが何を必要としているかを見分ける方法
ほとんどのターゲットは、何かを購入する前に、午後の時間で次のグループに分類できます。以下の関数は、テストで使用したチェックです。ページを取得し、実際のコンテンツを得られたのか、ブロック、エラー、空のシェルなのかを判定します。
import re
import requests
BLOCK = re.compile(r"captcha|access denied|are you a robot|just a moment|unusual traffic|"
r"verify you are human|request blocked|pardon our interruption|enable javascript and cookies",
re.IGNORECASE)
HEADERS = {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36",
"Accept-Language": "en-US,en;q=0.9",
}
def check(url, marker, proxies=None):
"""Did this request get the real content, or a block, an error or an empty shell?"""
try:
response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=30)
except requests.RequestException as error:
return {"url": url, "result": "error", "detail": type(error).__name__}
body = response.text
if response.status_code != 200:
result = "blocked" if response.status_code in (202, 401, 403, 429, 503) else "error"
elif BLOCK.search(body[:20000]) and marker.lower() not in body.lower():
result = "blocked"
elif marker.lower() not in body.lower():
result = "no content"
else:
result = "ok"
return {"url": url, "result": result, "status": response.status_code, "bytes": len(response.content)}目的のコンテンツにのみ現れるマーカー、例えば結果カードのクラス名やJSON応答内のフィールド名を選んでください。ページタイトルの単語は使わないでください。ブロックページやログインウォールも同じ単語を繰り返すことがよくあります。そして、各ターゲットの数ページに対してこれを実行します。
from check import check
print(check("https://api.github.com/repos/python/cpython", '"full_name"'))
print(check("https://www.ebay.com/sch/i.html?_nkw=laptop", "srp-results")){'url': 'https://api.github.com/repos/python/cpython', 'result': 'ok', 'status': 200, 'bytes': 6617}
{'url': 'https://www.ebay.com/sch/i.html?_nkw=laptop', 'result': 'blocked', 'status': 403, 'bytes': 1832}実際にスクレイパーが動く場所(本番環境がそこなら、ノートパソコンではなくクラウドサーバー)から、1日のうちに数回実行してください。結果は次のような判断に対応します。
| クラウドサーバーから見える結果 | 通常意味すること | 使うべきもの |
|---|---|---|
| 一貫して実際のコンテンツ | そのサイトはこの程度の量ではデータセンタートラフィックをブロックしていない | プロキシ不要、または規模拡大のためのデータセンターIP |
| ブロックやチャレンジが発生し、家庭用回線からは実際のコンテンツが得られる | そのサイトはIPの評判でブロックしている | レジデンシャルプロキシ |
| どのネットワークからもブロックされる | そのサイトはクライアントをチェックしている | 実際のブラウザ、または通常は背後にレジデンシャルIPを使うスクレイピングAPI |
| データのない空のシェル | コンテンツはJavaScriptでレンダリングされている | ヘッドレスブラウザ、またはページが呼び出しているAPI |
| ログインウォール | コンテンツは公開されていない | 許可なく収集しないこと |
2つの補足事項があります。
- 量によって答えが変わります。 クラウドサーバーからの10件のリクエストを無視するサイトでも、1万件はブロックするかもしれません。一度だけでなく、実際に運用する予定のレートで再テストしてください。
- 場所によって答えが変わります。 サイトは国によって異なるコンテンツを提供し、異なるルールを適用します。ドイツから見たデータが必要なら、ドイツからテストしてください。
その中間の選択肢
選択肢は、プロキシなしかレジデンシャルプロキシかの二択だけではありません。
- データセンターIPは安価で高速であり、ブロックしないサイトには十分です。ISPプロキシとデータセンタープロキシの比較記事で、それで十分な場合について解説しています。
- ISPプロキシは、一般消費者向けインターネットプロバイダーに登録された静的なアドレスです。長時間のセッションや自分のアカウントへのログインに適しており、数日間同じIPを使いたい場合に向いています。ShifterのISPプロキシは無制限のトラフィックが付いているため、それらを受け入れるサイトでの重く安定したワークロードにも適しています。
- スクレイピングAPIは、ブラウザ、リトライ、IPの選択をすべて代行し、ギガバイトごとではなく成功したページごとに課金します。クライアントをチェックするサイトには、ブラウザ層を自分で構築・維持する必要がないため、しばしば最も安価な選択肢になります。JavaScriptの多いサイトのスクレイピングに関する当社のガイドをご覧ください。
- レジデンシャルプロキシは、サイトがリクエストの発信元ネットワークを判定している場合、つまり同じクライアントが家庭用回線からは成功しクラウドサーバーからは失敗する場合に、適切なツールです。
よくある質問
ウェブスクレイピングにプロキシは必要ですか?
常に必要というわけではありません。今回のテストでは、30の公開ページのうち16ページが、すべての公開APIとほとんどのドキュメントサイトを含め、プロキシなしのクラウドサーバーに対して実際のコンテンツを提供しました。まずはスクレイパーが実際に動作する場所からターゲットをテストしてください。
レジデンシャルプロキシが必要なのはどんなときですか?
サイトがデータセンターIPからのリクエストをブロックする一方で、同じクライアントに対して家庭用回線からは応答する場合です。今回のテストでは、30サイト中3サイト(Walmart、Kayak、Booking.com)がそのような挙動を示しました。
レジデンシャルプロキシを使ってもまだブロックされるのはなぜですか?
多くの場合、サイトがIPではなくクライアントをチェックしているためです。多くのサイトは、TLSフィンガープリント、ヘッダー、JavaScriptの欠如からスクリプトだと識別されるHTTPクライアントをブロックします。今回のテストでは、30ページ中11ページが、単純なPythonクライアントを使った場合、両方のネットワークから失敗しました。解決策は別のIPではなく、実際のブラウザやスクレイピングAPIです。
スクレイピングにはデータセンタープロキシで十分ですか?
公開API、ドキュメント、多くのニュースサイト、一部の大規模小売業者については、中程度のボリュームであれば十分です。IPの評判をスコアリングするサイトには不十分です。思い込みではなく、各ターゲットをテストしてください。
まとめ
レジデンシャルプロキシは、1つの特定の問題、すなわちサイトがリクエストの発信元ネットワークで判定を行うという問題を解決します。クライアントをチェックするサイトには役立たず、公開APIやクラウドトラフィックをブロックしないサイトには不要です。スクレイパーが実際に動作する場所から各ターゲットをテストし、これらのグループのいずれかに分類し、結果が変わる場合にのみレジデンシャルトラフィックの料金を払ってください。責任あるデータ収集の残りの部分については、ウェブスクレイピングのベストプラクティスをご覧ください。