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だけが必要なページもあり、アンロッカーでのみ開くページもありました。以下の表は、どのページがどれに該当するかを示しています。

テスト方法

2026年9月29日に各URLを3つの方法で取得しました。まず、Chrome User-Agentを使用してフランクフルトのデータセンターサーバーから通常のcurlを使用しました。次に、QuantumProxies.ioのResidential Proxyを通して、米国の出口(Leboncoinにはフランスの出口)で同じcurlを使用しました。最後に、同じ出口国でResidential TierのWeb Unlockerフォワードプロキシを通しました。ステータスはクライアントが見た最終的なHTTPステータスです。時間は1つのUnlockerリクエストの壁時計時間です。

各レイヤーが何を解決するか

現代のボットウォールはページを送信する前にいくつかのことをチェックし、各ツールは異なるサブセットを解決します。どのウォールに当たっているかを知ることで、何を購入すべきかがわかります。

ウォールサイトがチェックすること通常のResidential ProxyWeb 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エンジンが必要です。

アンチボットの壁は順番に積み重ねられ、IPレピュテーション、TLSフィンガープリント、JavaScriptチャレンジがあり、レジデンシャルプロキシとWeb Unlockerの到達範囲がそれらに対してマークされています。
レジデンシャルプロキシは最初の壁をクリアします。Unlockerはすべての壁をクリアします。

プロキシが全く必要なかったサイト

ここから始めてください。これは最も安価な結果です。これらのページはデータセンターサーバーからの通常のリクエストに応答しました。何か他のものを通すと、コストがかかり、遅延が増えるだけで、得るものはありません。

サイト通常のデータセンターサーバー通常のResidential ProxyWeb Unlocker
docs.python.org200200200, 1.6 s
books.toscrape.com200200200, 1.9 s
news.ycombinator.com200200200, 4.1 s
en.wikipedia.org200200200, 1.9 s
github.com(リポジトリページ)200200200, 2.0 s
bbc.com(テクノロジー)302リダイレクト302リダイレクト200, 1.4 s

BBCの302はリダイレクトであり、ブロックではありません。テストクライアントはリダイレクトを追跡しませんでしたが、追跡するクライアントはページに到達します。

通常のResidential Proxyで十分だった場所

サイト通常のデータセンターサーバー通常のResidential ProxyWeb 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 ProxyWeb 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ヘッダーを提案とともに送信することもあり、それはブロッククラスの横に記録する価値があります。

スクレイパーのエスカレーションラダー:通常のリクエスト、次にResidential Proxy、次にResidential exitsでのWeb Unlocker、次にMobile Tier、テストからのサイトを最初にページを返した段に配置
サイトが強制する範囲までしか登らないでください。

5つの質問で決定する方法

  1. サーバーからの通常のリクエストが実際のページを返しますか?それならどちらも必要ありません。そこで止めてください。
  2. データセンターIPからは失敗しますが、Residentialからは機能しますか?Residential Proxiesを購入し、独自のクライアントを保持してください。
  3. クリーンなResidential IPからでも403、'Just a moment'や'JavaScriptを有効にしてください'ページ、または接続が切断されますか?それはUnlockerの仕事です。
  4. 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を再度変更します。ターゲットが受け入れる最低のランクを購入し、ブロッククラスが登るべき時を教えてくれるようにしましょう。

Web UnlockerのTierを比較する

Residential範囲を拒否するターゲット?モバイル出口でのWeb Unlockerをご覧ください。