Success rates

If you compute a failure percentage over every request your tooling makes, it can look far worse than what you're actually getting. The reason is almost always that the number counts requests to ad, tracking and telemetry endpoints that very few proxies reach — not requests to the site you care about. This page explains the difference and how to measure the rate that matters.

Short version. Requests to the sites you actually target succeed the large majority of the time. Requests to third-party ad and tracking endpoints embedded in those pages fail across virtually every proxy service, by design. Measure success against your target host, not against every sub-resource a page pulls in.

One page load is many requests

When you drive a real browser or a headless automation tool through a proxy, loading a single page rarely makes a single request. The page itself is one request; then the page pulls in dozens more on its own — advertising exchanges, real-time-bidding and cookie-sync endpoints, analytics beacons, consent managers, fonts, and background service calls. It's common for the site you actually want to be a small fraction of the total requests your session generates.

If your success metric divides successful requests by all requests, those embedded third-party calls are in the denominator — and, as the next section explains, many of them are designed to fail through any proxy. That drags the overall number down even when every request to your real target succeeded.

Why some of those sub-requests fail — and why it usually doesn't matter

Advertising and tracking infrastructure actively rejects proxy and datacenter traffic. Ad exchanges, bid-sync pixels, and analytics/telemetry beacons block or refuse connections they flag as automated or proxied — using signals like datacenter IP ranges, cookie-sync behaviour and traffic patterns — and they do this on essentially every proxy network, not just ours. It's part of how the ad-tech ecosystem defends against fraud.

The good news: those endpoints have nothing to do with the data you're collecting. A blocked ad-sync pixel or a refused analytics beacon does not change the page content, the product listing, the search result, or whatever you actually came for. They're noise in the failure column.

Hosts that are expected to fail or be refused through any proxy include, among many others:

Ad exchanges and RTB / cookie-sync endpoints — for example hosts under adnxs.com, doubleclick.net, pubmatic.com, criteo.com, rubiconproject.com, openx.net, bidswitch.net, adsrvr.org and hundreds of similar ad networks.
Analytics and tracking beacons — telemetry pings and tag managers that report back to advertising and measurement platforms.
Background app / OS service calls — connectivity checks, software-update pings and push endpoints that a full browser profile fires automatically.

This is industry-wide, not proxy-specific. Sending these same requests through any residential or datacenter proxy — or through a plain VPN — produces the same refusals. They aren't a sign that your proxy plan is underperforming.

Measure success against your target, not every sub-resource

To see the rate that actually reflects your results, score only the requests to the host (or hosts) you set out to reach, and ignore third-party ad, tracking and telemetry hosts. Two practical ways to do that:

Filter your own logs to your target domain. If you're scraping example.com, count only requests whose host is example.com (and its API subdomains). Exclude everything else. The success rate you see on that filtered set is the one that matters.
Request only what you need. If your tool lets you block ads, trackers and non-essential sub-resources — for example with a request-interception rule or an ad-block ruleset — do it. You'll cut wasted requests, load pages faster, and your overall success number will jump because the failing noise is gone.

✓

What good looks like. On the sites customers actually target, the large majority of requests succeed. When people report a "low success rate," filtering the ad and telemetry hosts out of the calculation almost always resolves it.

When a real target is genuinely hard

Some destinations you legitimately want to reach are strongly defended against automation — large marketplaces, sneaker and ticketing sites, and a handful of platforms with aggressive anti-bot systems. These can refuse or challenge a share of requests even though they're your real target, not ad noise. If a specific site you care about is failing more than you'd like, a few things move the needle:

Rotate to a fresh IP. Change or drop your -session- value so the next request exits from a different address; a flagged IP for that one target may simply need to change. See Sessions & rotation.
Try a different country or a higher tier. A different -country- gives you a different pool. For the hardest targets, the cleaner IP quality of Residential / ISP or Mobile often succeeds where a shared rotating tier struggles.
Slow down and spread out. High request rates from one IP invite throttling and challenges. Lower your concurrency and spread work across more sessions. See Timeouts or slow responses.
Retry on failure. Because each retry can take a fresh IP, a simple retry-with-new-session loop lifts the effective success rate on tough targets considerably.

When to contact us

✓

Tell us the target, and we'll dig in. If a specific site you actually target — not an ad or tracking host — is consistently failing, email [email protected] or use the in-dashboard chat with the target URL, the product you're on, and a sample request (password redacted). We'll test it from our side and get you a concrete answer. For connection-level errors like 407s or refused connections, start with Troubleshooting.

Last updated 15 July 2026