Web UnlockerとResidential ProxyとMobile Proxyの比較:どれを使うべきか
データセンターサーバーから、単純なレジデンシャルプロキシを通じて、Web Unlockerを通じて同じURLを取得しました。一部のサイトは何も必要とせず、一部はレジデンシャルIPだけが必要であり、一部はUnlockerだけが開きました。ここでは、各レイヤーが修正するものと、モバイルティアがどこに適合するかを示します。
Residential Proxyはリクエストの発信元を変更します。Web Unlockerはリクエストの見た目も変更します:実際のブラウザのTLSフィンガープリントで送信し、新しいIPで再試行し、JavaScriptチャレンジが現れたときにヘッドレスブラウザを実行します。クリーンなResidential IPでもブロックされる場合にのみUnlockerが必要です。それ以外の場合はProxyで十分です。
それが理論です。それを確認するために、2026年9月29日に同じURLを3つの方法で取得し、結果をサイトごとに保存しました。何も必要としないページもあれば、住宅用IPだけが必要なページもあり、アンロッカーでのみ開くページもありました。以下の表は、どのページがどれに該当するかを示しています。
- プロキシ不要: docs.python.org、books.toscrape.com、Hacker News、Wikipedia、GitHubはデータセンターサーバーからの通常のリクエストに応答しました。
- Residential Proxyで十分: ZillowとLeboncoinはデータセンターサーバーをブロックしましたが、通常のResidential Proxyを通して実際のページを提供しました。
- Unlockerだけが通過: Indeed、Glassdoor、Walmart、Best Buyは、通常のクライアントを拒否し、Unlockerを通してページを返しました。
テスト方法
2026年9月29日に各URLを3つの方法で取得しました。まず、Chrome User-Agentを使用してフランクフルトのデータセンターサーバーから通常のcurlを使用しました。次に、QuantumProxies.ioのResidential Proxyを通して、米国の出口(Leboncoinにはフランスの出口)で同じcurlを使用しました。最後に、同じ出口国でResidential TierのWeb Unlockerフォワードプロキシを通しました。ステータスはクライアントが見た最終的なHTTPステータスです。時間は1つのUnlockerリクエストの壁時計時間です。
各レイヤーが何を解決するか
現代のボットウォールはページを送信する前にいくつかのことをチェックし、各ツールは異なるサブセットを解決します。どのウォールに当たっているかを知ることで、何を購入すべきかがわかります。
| ウォール | サイトがチェックすること | 通常のResidential Proxy | Web Unlocker(Residential) | Web Unlocker、Mobile Tier |
|---|---|---|---|---|
| IPの評判 | IPが属するネットワークとその履歴 | データセンター範囲のブロックを修正 | Residential exits、再試行ごとに新しいIP | 多くの電話が共有する4G/5GキャリアIP |
| TLSとHTTPフィンガープリント | ハンドシェイク、HTTP/2設定、ヘッダーの順序 | 変更なし:まだクライアントです | ブラウザのフィンガープリント、再試行時に回転 | Residentialと同じ |
| JavaScriptチャレンジ | クライアントがページのスクリプトを実行し、クッキーを保持するかどうか | いいえ | ヘッドレスブラウザにエスカレート | Residentialと同じ |
最初の行は、ほとんどのスクレーパーが開始する場所であり、レジデンシャルプロキシがその価値を発揮する場所です。ホスティング範囲は簡単に認識でき、多くのサイトはそれらを完全に拒否します。2番目の行は、クリーンなIPだけでは不十分な理由です。curl、Python、NodeのTLSハンドシェイクはChromeのものとは全く異なり、CloudflareはJA3/JA4フィンガープリントをクライアントを特定する方法として文書化しています。TLSフィンガープリンティングに関する当社のガイドでは、これを詳細に説明しています。3番目の行には、実際のJavaScriptエンジンが必要です。

プロキシが全く必要なかったサイト
ここから始めてください。これは最も安価な結果です。これらのページはデータセンターサーバーからの通常のリクエストに応答しました。何か他のものを通すと、コストがかかり、遅延が増えるだけで、得るものはありません。
| サイト | 通常のデータセンターサーバー | 通常のResidential Proxy | Web Unlocker |
|---|---|---|---|
| docs.python.org | 200 | 200 | 200, 1.6 s |
| books.toscrape.com | 200 | 200 | 200, 1.9 s |
| news.ycombinator.com | 200 | 200 | 200, 4.1 s |
| en.wikipedia.org | 200 | 200 | 200, 1.9 s |
| github.com(リポジトリページ) | 200 | 200 | 200, 2.0 s |
| bbc.com(テクノロジー) | 302リダイレクト | 302リダイレクト | 200, 1.4 s |
BBCの302はリダイレクトであり、ブロックではありません。テストクライアントはリダイレクトを追跡しませんでしたが、追跡するクライアントはページに到達します。
通常のResidential Proxyで十分だった場所
| サイト | 通常のデータセンターサーバー | 通常のResidential Proxy | Web Unlocker |
|---|---|---|---|
| Zillow(オースティンのリスティング) | 403、PerimeterX 'このページへのアクセスが拒否されました' | 200、実際のリスティングページ | 200、1回の試行、2.7 s |
| Leboncoin(検索、フランスの出口) | 403、キャプチャページ | 200、実際の結果ページ | 200、1回の試行、1.4 s |
| Amazon(商品ページ) | 200、商品ページ | 200、商品ページ | 200、2回の試行+ブラウザ、10.2 s |
ZillowとLeboncoinは、Residential Proxyが作られたケースです。データセンターIPは拒否され、家庭用IPからの同じリクエストでページが取得されました。Unlockerも機能しましたが、必要なものを追加しませんでした。
Amazonは注意が必要な行です。両方の通常のクライアントはこの実行で商品ページを取得しましたが、Unlockerは2回の試行とブラウザを必要とし、10.2秒かかりました。Unlockerは移動するすべてのバイトを請求し、再試行やブラウザのロードも含まれます。必要のないページでそれを使用すると、その余分な作業に対して支払うことになります。これは1回のリクエストであり、Amazonに関する規則として読むべきではありません。通常のテストを最初に行うことに関する規則として読んでください。
Web Unlockerだけが通過した場所
| サイト | 通常のデータセンターサーバー | 通常のResidential Proxy | Web Unlocker |
|---|---|---|---|
| Indeed(求人検索) | 403、'セキュリティチェック'ページ | 403、'JavaScriptとクッキーを有効にしてください' | 200、1回の試行、2.6 s |
| Glassdoor(企業レビュー) | 403、キャプチャ付きの'セキュリティ'ページ | 403、'JavaScriptとクッキーを有効にしてください' | 200、2回の試行+ブラウザ、17.2 s |
| Walmart(検索) | 307リダイレクト、結果ページなし | 307リダイレクト、結果ページなし | 200、1回の試行、4.8 s |
| Best Buy(ラップトップカテゴリ) | 接続失敗、応答なし | 接続失敗、応答なし | 200、1回の試行、6.3 s |
ここでは、住宅用IPだけでは役に立ちませんでした。Walmart、Best Buy、Indeedは、ブラウザなしでアンロッカーの最初のTLS試行で実際のページを返しました。それでも、単純な住宅用カラムはすでにクリーンなホームIPを持っていて失敗し、明らかな残りの違いはリクエストの見た目でした。Glassdoorはさらに進んで、JavaScriptを要求しました。そのため、アンロッカーは2回のTLS試行とヘッドレスブラウザが必要で、17.2秒かかった理由です。
Walmartには独自の注意が必要です。307リダイレクトがどこに向かっていたのか記録していません。通常のクライアントが結果ページを受け取らず、Unlockerが受け取ったことだけがわかっています。
Residential exitsでWeb Unlockerを使用する
Mobile Tierがどこに適しているか
モバイルキャリアは多くの電話を各パブリックIP(キャリアグレードNAT)に置くため、キャリアアドレスをブロックするサイトは実際の顧客もブロックするリスクがあります。これがキャリアIPがResidential範囲よりも信頼される傾向がある理由です。なぜモバイルプロキシが信頼されるのか:CGNATでそのメカニズムを説明しています。
Web Unlockerには、4G/5Gキャリアエグジットで同じロジック(ブラウザフィンガープリント、リトライ、ブラウザエスカレーション、ブロックレポート)を実行するモバイルティアがあります。プロキシユーザー名で-tier-mobileを選択するか、RESTエンドポイントで"tier": "mobile"を選択します。独自のプリペイドGBバランスを持っています。これは、レジデンシャル範囲を拒否するサイト向けであり、レジデンシャルティアのaccess_deniedブロックが示唆するものです。
Pythonでのコスト意識のあるエスカレーションラダー
表は1つのルールを示しています:サイトが強制する限りのみ登ること。この関数は各段を順に試し、実際のページを返す最初の段で停止します。Residential Tierがaccess_deniedブロックを報告した場合にのみMobile Tierに移動します。HEADERSとlooks_blocked()は、PythonでのWeb Unlocker APIチュートリアルからのヘルパーです。
import os
import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
RESIDENTIAL = os.environ["QP_RESIDENTIAL_PROXY"] # http://USER:PASS@HOST:PORT from your residential plan
UNLOCK_USER = os.environ["QP_UNLOCK_USER"] # unlock-XXXXXXXX
UNLOCK_PASS = os.environ["QP_UNLOCK_PASSWORD"]
def unlocker(extra: str = "") -> dict:
u = f"http://{UNLOCK_USER}-country-us{extra}:{UNLOCK_PASS}@unlock.quantumproxies.io:9000"
return {"http": u, "https": u}
LADDER = [
# name, proxies, verify, timeout
("plain", {}, True, 30),
("residential", {"http": RESIDENTIAL, "https": RESIDENTIAL}, True, 30),
("unlocker", unlocker(), False, 120),
("unlocker-mobile", unlocker("-tier-mobile"), False, 120),
]
def climb(url: str):
last = None
for name, proxies, verify, timeout in LADDER:
try:
r = requests.get(url, headers=HEADERS, proxies=proxies, verify=verify, timeout=timeout)
except requests.RequestException:
continue # no response at all counts as a block
last = r
if not name.startswith("unlocker"):
if not looks_blocked(r):
return name, r
continue
if "x-qp-unlocker-blocked" not in r.headers:
return name, r
if r.headers.get("x-qp-block-class") != "access_denied":
break # a different IP will not fix this wall
return "blocked", last
本番環境では、ドメインごとに段を覚えておき、すべてのリクエストで失敗した段に対して支払わないようにしてください。Unlockerはx-qp-hintヘッダーを提案とともに送信することもあり、それはブロッククラスの横に記録する価値があります。

5つの質問で決定する方法
- サーバーからの通常のリクエストが実際のページを返しますか?それならどちらも必要ありません。そこで止めてください。
- データセンターIPからは失敗しますが、Residentialからは機能しますか?Residential Proxiesを購入し、独自のクライアントを保持してください。
- クリーンなResidential IPからでも403、'Just a moment'や'JavaScriptを有効にしてください'ページ、または接続が切断されますか?それはUnlockerの仕事です。
- UnlockerがResidential exitsで
access_deniedを報告しますか?そのサイトでMobile Tierをテストしてからボリュームを購入してください。
よくある質問
Residential Proxiesを購入するべきか、それともWeb Unlockerを使用するべきか?
まずターゲットをテストしてください。2026年9月29日のテストでZillowとLeboncoinが示したように、Residential IPからの通常のリクエストが実際のページを返す場合、Residential Proxiesで十分であり、運用コストも安くなります。クリーンなResidential IPでも403やJavaScriptチャレンジが発生する場合、IndeedやGlassdoorが示したようにUnlockerが必要です。
Residential Proxiesが必要ですか、それともどのプロキシでも機能しますか?
サイトによります。我々のテストではWikipedia、GitHub、Hacker Newsが通常のデータセンターリクエストに応答したため、プロキシは必要ありませんでした。ZillowとLeboncoinはデータセンターIPを拒否し、Residentialを受け入れました。データセンタープロキシは最初の問題を共有しています。ホスティング範囲はサイトが認識しやすく、拒否されやすいからです。
モバイルプロキシはWeb ScrapingにおいてResidential Proxiesよりも信頼性がありますか?
キャリアIPはCGNATを通じて多くの電話で共有されているため、サイトはそれらをブロックすることに消極的であり、IPレピュテーションブロックに対して有効です。それらはTLSフィンガープリントを変更したり、JavaScriptチャレンジを自動的に解決したりしません。
モバイルプロキシはキャプチャを減らしますか?
キャリアアドレスは多くの普通の電話ユーザーのように見えるため、IPレピュテーションによってトリガーされるキャプチャを減らすことができます。
Web UnlockerはResidential Proxyと比較してどのように請求されますか?
どちらもGB単位で請求されます。Unlockerは、再試行、ブロックされたページ、ブラウザのページロードを含め、あなたのために移動するすべてのバイトをカウントし、各Tierごとに独自のプリペイド残高を使用します:Residential exitsとモバイルキャリアexits。現在のGBあたりの価格はダッシュボードに表示されています。
レジデンシャルプロキシはリクエストの発信元を修正します。Web Unlockerはリクエストの見た目やJavaScriptを実行できるかどうかも修正します。モバイルティアは、レジデンシャル範囲を拒否するサイトに対してIPを再度変更します。ターゲットが受け入れる最低のランクを購入し、ブロッククラスが登るべき時を教えてくれるようにしましょう。
Residential範囲を拒否するターゲット?モバイル出口でのWeb Unlockerをご覧ください。