A proxy is not a transport detail. It is the channel through which every site, API and LLM perceives you. Before a single line of your script runs, the target has already decided what to show you based on the IP alone:

The most common cause of "bad data" is not the scraper. It is a mismatched or unstable IP producing a different page than the one you expected.

Verify it before you trust the data. On the first run of any new configuration, check where you are actually coming out — open an IP-echo page, or watch the session's live view — and confirm the country, region and currency the target is serving you. Most "the data looks wrong" reports are a session that was never in the location it was configured for.

The Scraping Browser runs on residential and mobile proxies only. Datacenter and static/ISP proxies are not supported — they are the first thing a serious anti-bot system filters out, so the browser is built around real-network IPs by design.

Residential (30M+ IPs) - real IPs on real consumer ISPs. The default for search engines, marketplaces, PLA/Shopping data and anything with serious bot protection.

Mobile (295K+ IPs) - IPs from mobile carrier networks (4G/5G). The highest trust level available, because carrier-grade NAT means thousands of real users share the same address and blocking it is expensive for the target. The pool is smaller, so reserve it for where it counts: the hardest targets, mobile-first platforms and social apps, or when residential is still getting challenged.

Both pools are filtered for low fraud score before an IP ever reaches you, so what you get is a real, clean address that looks like a real user to the target. That filtering is the product.

What no provider can remove is the nature of the network itself: these are real devices, and a real device can go offline mid-session. It happens occasionally — the exception, not the rule — so build for it rather than assuming a permanently open connection. The Sticky session type absorbs it for you by substituting an equivalent IP (§3).

Everything in this section lives under Proxy Settings in the dashboard.

Target the location explicitly — Country, then Region and City when the data is local (prices, availability, local packs). ISP and ZIP targeting narrow it further when you need to reproduce a very specific user's view. Do not leave geography to the pool if it affects the output.

Country and region show a quality badge (High / Medium / Low) indicating pool depth for that location. Prefer High where you can - a thin pool means fewer IPs to rotate through and faster reuse of the same addresses.

The trade-off is continuity vs. identity. Sticky keeps the job alive and absorbs the fact that residential and mobile IPs drop; No rotating keeps the identity perfectly intact but hands you the drop to deal with yourself.

Rotating per request looks like a hundred different people arriving at the same funnel in the same second. Sticky looks like one person browsing - and your cookies, consent state and any solved CAPTCHA stay valid for the rest of the run.

Two options: HTTP and SOCKS5.

Use SOCKS5 for protected sites. It is the more reliable choice against targets with serious bot protection — Google in particular — and we have measured noticeably more consistent results with it. HTTP is fine for undefended endpoints and simple fetches.

Controls how the pool picks an IP for you.

Mixed IPv4 and IPv6 by default. Switch to IPv4 only if the target handles IPv6 badly or serves different content over it — some sites still treat IPv6 ranges as higher risk.

This is the single biggest speed and success-rate lever in the product.

Under Browser Profile Settings, the Browser state toggle decides everything here:

A persistent browser profile keeps the real Chrome state between sessions — cookies, local storage, history, consent flags and the trust signals a site has already granted you. Consequences:

Pin the profile to the proxy. A profile carrying cookies issued to a US residential IP that suddenly appears from Germany is a contradiction, and it is exactly the pattern anti-bot systems look for. Bind each profile to one location and keep it on the same (or closest available) IP every time.

Never deep-link straight to the page you actually want. Jumping from a search engine - or from nothing at all - directly into a product page, a listing or a detail URL is one of the clearest automation signals a platform has, and it is a common reason for an instant block or challenge on an otherwise perfect setup.

A real customer does not materialise on amazon.com/dp/B0XXXXXXX. They land on the homepage, search, filter, and click through. Reproduce that path:

The referrer chain, the cookies picked up along the way and the timing between steps all end up in the platform's risk score. Deep-linking discards every one of them.

This compounds with §4: the navigation warms the profile, the profile keeps that warmth for the next run, and after a few clean passes the site stops treating you as a first-time stranger.

The built-in solver handles challenges reliably — including Google's /sorry/ interstitial. The thing to internalise is it is not instant.

So the default 30–60 second timeout most scripts ship with is the wrong number here.

Poll actively while you wait - don't sleep. This is the trap: the session closes after 5 minutes of inactivity, and that limit is fixed (§7). A blind sleep(240) is 4 minutes of nothing happening, and the session can die right as the solver finishes. Poll the page every few seconds instead - that keeps the session alive and lets you continue the moment the challenge clears.

The 5-minute idle window is therefore your real ceiling: treat ~4 minutes as the practical maximum for a single CAPTCHA wait. And budget the session as a whole - a hard solve can eat 3 of your 30 available minutes.

Combine this with §4: with a warmed profile you will usually not reach the challenge at all, which is why the profile is worth setting up.

These limits are fixed - they are not settings you can change. Plan your jobs around them:

What this means in practice:

Need more than this? Write to support with your use case. Limit increases are reviewed case by case rather than granted on request, so explain what you are running and why the default does not fit.

Google is the hardest common target, so it makes a good worked example. This configuration reliably pulls clean product data — titles, prices and merchant URLs — from both the inline shopping unit and the Shopping tab, with Extra Stealth and the CAPTCHA Solver doing the work.

One practical note on the flow: if the regular search returns no inline shopping unit, retry the query on the Shopping tab (&tbm=shop). Expect the /sorry/ wall on either step — handle it the same way both times.