レジデンシャルプロキシが不要なとき: 30ページを検証

Residential proxies(レジデンシャルプロキシ)は私たちが販売しているものなので、どんな時に不要かについて書くのは奇妙に思えるかもしれません。しかし、あらゆる作業にプロキシを購入するチームは支出がかさみ、あらゆる失敗をプロキシのせいにするチームは何週間も無駄にします。どのサイトがレジデンシャルIPを必要とし、どのサイトが何も必要とせず、どのサイトがまったく別のものを必要とするかを知ることは、Web データ収集における最も安価な最適化です。

これを具体的に示すため、小規模なテストを行いました。2026年10月9日に、クラウドサーバーのデータセンターIPアドレスから30の公開ページをそれぞれ3回ずつリクエストし、次に米国出口のShifterレジデンシャルプロキシ経由で同じことを行いました。両方の実行で同じシンプルなPython HTTPクライアントを使用しました。30ページのうち16ページはデータセンターIPから毎回成功しました。3ページはレジデンシャル出口経由でのみ成功しました。残りの11ページは両方の方法で失敗しましたが、これはレジデンシャルIPでは解決できない理由によるものです。

私たちのテスト:30ページ、データセンターIP対レジデンシャルプロキシ

対象は6種類のサイトをカバーしました:公開APIとオープンデータ、リファレンスおよびドキュメントサイト、ニュースのホームページ、eコマースの検索ページ、旅行検索ページ、そしてソーシャル、求人、検索ページの集合です。各リクエストは同じデスクトップブラウザのUser-Agentを使用し、ステータスコードだけでなく実際のコンテンツが取得できたかを確認しました。レスポンスは、検索結果カードのような実際のコンテンツにのみ現れるマーカーを含んでいる場合にのみ成功とカウントされました。よくあるステータス200を返すブロックページは、したがって失敗としてカウントされました。

最終実行の前に両方のネットワークから保存したレスポンスを検査してマーカーを選び、実際のコンテンツとログイン画面や空のJavaScriptシェルを見分けられなかった5つの候補ページは除外しました。

カテゴリ	サイト	データセンターIP	レジデンシャル出口	判定
公開APIとオープンデータ	en.wikipedia.org	3回中3回	3回中3回	プロキシ不要
公開APIとオープンデータ	api.github.com	3回中3回	3回中3回	プロキシ不要
公開APIとオープンデータ	data.sec.gov	3回中3回	3回中3回	プロキシ不要
公開APIとオープンデータ	api.worldbank.org	3回中3回	3回中3回	プロキシ不要
公開APIとオープンデータ	ecb.europa.eu	3回中3回	3回中3回	プロキシ不要
リファレンスとドキュメント	docs.python.org	3回中3回	3回中3回	プロキシ不要
リファレンスとドキュメント	developer.mozilla.org	3回中3回	3回中3回	プロキシ不要
リファレンスとドキュメント	rfc-editor.org	3回中3回	3回中3回	プロキシ不要
リファレンスとドキュメント	en.wikipedia.org	3回中3回	3回中3回	プロキシ不要
リファレンスとドキュメント	arxiv.org	3回中3回	3回中3回	プロキシ不要
リファレンスとドキュメント	stackoverflow.com	0回中3回	0回中3回	どちらもブロック
ニュース	bbc.com	3回中3回	3回中3回	プロキシ不要
ニュース	reuters.com	0回中3回	0回中3回	どちらもブロック
ニュース	nytimes.com	0回中3回	0回中3回	どちらもブロック
ニュース	theguardian.com	3回中3回	3回中3回	プロキシ不要
ニュース	edition.cnn.com	3回中3回	3回中3回	プロキシ不要
ニュース	bloomberg.com	0回中3回	0回中3回	どちらもブロック
eコマース検索	amazon.com	3回中3回	2回中3回	プロキシ不要
eコマース検索	walmart.com	0回中3回	3回中3回	レジデンシャルIPが必要
eコマース検索	ebay.com	0回中3回	0回中3回	どちらもブロック
eコマース検索	bestbuy.com	0回中3回	0回中3回	どちらもタイムアウト
eコマース検索	etsy.com	0回中3回	0回中3回	どちらもブロック
旅行	booking.com	0回中3回	2回中3回	レジデンシャルIPが必要
旅行	expedia.com	0回中3回	0回中3回	どちらもブロック
旅行	airbnb.com	3回中3回	2回中3回	プロキシ不要
旅行	tripadvisor.com	0回中3回	0回中3回	どちらもブロック
旅行	kayak.com	0回中3回	3回中3回	レジデンシャルIPが必要
ソーシャル、求人、検索	linkedin.com	3回中3回	3回中3回	プロキシ不要
ソーシャル、求人、検索	indeed.com	0回中3回	0回中3回	どちらもブロック
ソーシャル、求人、検索	google.com	0回中3回	0回中3回	ブラウザが必要

「どちらもブロック」とは、単純なHTTPクライアントが両方のネットワークからブロックされたことを意味します。実際のブラウザやブラウザチェックを処理するスクレイピングAPIであれば、これらのサイトでも成功する可能性は十分にあります。このテストではそれを試していません。

カテゴリ別に結果をまとめると次のようになります:

カテゴリ	ページ数	プロキシ不要	レジデンシャルIPが必要	両方で失敗
公開APIとオープンデータ	5	5	0	0
リファレンスとドキュメント	6	5	0	1
ニュース	6	3	0	3
eコマース検索	5	1	1	3
旅行	5	1	2	2
ソーシャル、求人、検索	3	1	0	2
合計	30	16	3	11

30ページテストが示すこと

**公開API、オープンデータ、ドキュメントはプロキシを必要としません。**試した全てのAPIとリファレンスページは、1つを除いて、データセンターIPから毎回実際のコンテンツを提供しました。これらのサービスはプログラムによる利用を前提に作られています。求められているのは、説明的なUser-Agent、適切なリクエスト頻度、そして一部では APIキーです。プロキシはコストを追加するだけで、他には何ももたらしません。

**多くの大規模サイトはデータセンターIPを全くブロックしません。**6つのニュースのホームページのうち3つ、Amazon検索、Airbnb検索、そしてLinkedInの企業ページは、クラウドサーバーに3回中3回とも実際のコンテンツを提供しました。こうしたサイトからの低ボリュームな収集であれば、サイトの利用規約とレート制限を守る限り、プロキシなしで始めるのは妥当です。

AmazonとAirbnbはそれぞれ、データセンターIPから3回中3回成功し、レジデンシャル出口経由では3回中2回成功しました。1サイトあたり3回の試行では、1回の失敗は通常の変動の範囲内であり、レジデンシャルIPがそこで劣っている証拠にはなりません。各レジデンシャルリクエストは異なる家庭の接続から送信され、固定のクラウドサーバーとは異なり、個々の出口が遅かったり、同じサイトに最近見られていたりすることがあります。教訓は、判断する前に何度もテストすることで、下記のチェックはそれを容易にします。

**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を決してブロックしないこともありますが、それでも正しい場所のレジデンシャル出口なしでは、誤ったデータを収集することになります。

中間的な選択肢

選択肢は、プロキシなしかレジデンシャルプロキシかだけではありません。

• データセンターIPは安価で高速であり、ブロックしないサイトには適しています。ISPプロキシとデータセンタープロキシの比較で、それらで十分な場合を扱っています。
• ISPプロキシは、コンシューマー向けインターネットプロバイダーに登録されたアドレスで、長期間にわたって維持されます。長時間のセッションや自分のアカウントへのログインに適しています。ShifterのISPプロキシは、請求期間全体を通じて選択した都市とISP（ASN）に留まり、無制限のトラフィックが付属しているため、こうしたサイトを受け入れる重い定常的なワークロードにも適しています。
• スクレイピングAPIは、ブラウザ、リトライ、IPの選択をあなたの代わりに処理し、ギガバイト単位ではなく成功したページ単位で課金します。クライアントをチェックするサイトにとっては、ブラウザ層を自分で構築・維持する必要がないため、しばしば最も安価な選択肢になります。JavaScriptの多いサイトのスクレイピングについてのガイドをご覧ください。
• レジデンシャルプロキシは、サイトがリクエストの送信元ネットワークを判定する場合、つまり同じクライアントでも家庭の接続からは成功しクラウドサーバーからは失敗する場合に、適切な手段です。

FAQ

結論

レジデンシャルプロキシが解決するのは一つの特定の問題です:リクエストの送信元ネットワークによって判定するサイトです。クライアントをチェックするサイトには役立たず、公開APIやクラウドトラフィックをブロックしないサイトには不要です。各対象をスクレイパーが動く場所からテストし、これらのグループのいずれかに分類し、結果が変わる場合にのみレジデンシャルトラフィックに課金してください。私たちのWebスクレイピングのベストプラクティスが、責任ある収集の残りの部分をカバーしています。