Everyone quotes a price. Almost nobody quotes a success rate.

A guide to choosing proxies for web scraping

This tool exists to answer one question that price sheets cannot: what does a thousand pages of usable data actually cost you, once the requests that came back blocked are counted?

Below the comparison, this guide covers what you are choosing between — the three shapes proxy access is sold in, the two ways it is billed, and the four IP types underneath — so the numbers in the table have something to sit on.

The three shapes proxy access is sold in

There are several hundred companies selling proxy access for scraping, automation and account work, and their product pages describe what they sell in wildly different language. Underneath, almost all of it falls into three shapes.

Proxy lists

The oldest form. You buy a set of IP addresses — usually datacenter ones — and receive them as a list of host and port pairs. From there, everything is yours to build: cycling through the list, picking a fresh address per request, noticing when one starts returning block pages, pulling it out of rotation, and handling whatever challenge the target throws back.

You also own your headers and user agents, which matters more than people expect. An otherwise clean pool gets recognised quickly if every request carries the same browser fingerprint.

Against an easy target this is a few hours of work and the cheapest access available. Against something like Google, Amazon or a large marketplace, building a rotation layer that holds up is a permanent maintenance job rather than a setup task.

Best for: teams where unit cost dominates every other concern, easy targets, or genuinely enormous volume. Billing: usually per IP address, with traffic unmetered. IP type: almost always datacenter.

Rotating proxy pools

The common form today. Instead of a list, you get one endpoint. You send every request there and the provider decides which underlying address to use, retires the dead ones, and handles the rotation logic on its side.

This is how nearly all residential and mobile access is sold, and increasingly how datacenter access is sold too. Integration is a single configuration line, which is the whole appeal.

The catch is the billing model that comes with it. Rotating pools are charged by bandwidth, and a bandwidth meter does not distinguish between a page you wanted and a block page you did not. Both transfer bytes, both bill at the same rate. That is why the price per gigabyte is only half the story here, and why success rate belongs in the same sentence as price.

Headless browsers make this worse. A browser-driven crawl pulls images, fonts, stylesheets and tracking scripts alongside the HTML you actually need, which can multiply your bandwidth several times over. If you are running Selenium, Puppeteer or Playwright through a bandwidth-billed pool, blocking unnecessary resource types is the single highest-value change you can make.

Best for: teams that need residential or mobile access, or want scale without building infrastructure. Billing: per gigabyte of bandwidth. IP type: datacenter, residential or mobile.

Smart proxies and scraping APIs

The newest form, and the one that changes the arithmetic most. You send a URL; the provider handles rotation, header construction, block and challenge detection, and retries; you get the page back.

Most also expose the harder features as request flags rather than as separate products — JavaScript rendering through a headless browser on their infrastructure, country-level geotargeting, residential or mobile routing for difficult targets, sticky sessions where a flow needs to stay on one address.

The important part is the billing. These charge per successful request, so a retry costs nothing and a block costs nothing. The quoted price is the price. That single property removes the largest source of uncertainty in a scraping budget, and it is why a per-request plan with a higher headline number frequently costs less per delivered page than a cheaper bandwidth plan.

Best for: teams that want the infrastructure problem to belong to someone else, or that are scraping targets where residential bandwidth would be wasted on blocks. Billing: per successful request. IP type: datacenter, residential or mobile, chosen by the provider or by a flag.

The two billing models, and why the comparison hinges on them

Everything above reduces to one distinction, and it is the reason this site computes an effective cost rather than listing prices.

Bandwidth billing charges for every byte transferred. Successful pages, block pages, CAPTCHA interstitials, redirect chains, empty shells — all of it meters. Your real cost per delivered page is therefore the list price divided by the share of requests that came back usable. A pool at four dollars a gigabyte succeeding seventy percent of the time costs more per usable page than one at five dollars succeeding ninety-five percent of the time.

Per-request billing charges only for responses that worked. Failures are free, retries are free, and the list price is already the real price.

Comparing a bandwidth plan and a per-request plan on their headline numbers is comparing two different things. The effective cost column puts them on the same footing.

The four IP types

Datacenter addresses come from commercial hosting facilities. Cheapest by a wide margin, fastest, available in bulk, and the first thing any serious bot defence filters out — hosting ranges are published and easy to match against. Correct for public registries, documentation, open APIs and anything without meaningful defences.

Residential addresses are assigned by internet service providers to real households. They look like ordinary users, which is the point, and they are the default once a target actually defends itself. Priced per gigabyte, which means page weight drives your bill directly.

ISP or static residential addresses are registered to an internet service provider but hosted in a data centre — residential legitimacy at datacenter speed, usually sold per IP per month rather than per gigabyte. Useful where you need an address that both looks residential and stays put.

Mobile addresses belong to cellular carriers. Because carriers share one address across many subscribers, blocking a mobile address means blocking a crowd of real phone users, and most sites will not do that. The hardest category to filter and the most expensive by a wide margin. Reach for it on mobile-first platforms, or when a properly configured residential crawl has genuinely failed.

Reading a success rate

A success rate is only meaningful if you know what counted as a success.

A 200 status code does not mean the page arrived. Block pages return 200. So do CAPTCHA interstitials, empty shells that render nothing without JavaScript, and soft blocks that serve a stripped version of the page. A measurement that counts status codes rather than checking the body for the elements you expect will overstate performance, sometimes dramatically.

That is the standard this site uses: a response counts only when the body contains the structure a real page would have. It is also worth applying to any figure a vendor quotes you — asking what was counted and over how many requests usually tells you more than the number itself.

A practical sequence

Start at the cheapest option that could plausibly work and move up only when it stops working.

Test a datacenter pool against your actual target first. If the pages come back, you are done, and you have saved a factor of ten.

If they come back blocked, try a per-request scraping API before moving to residential bandwidth. It removes the blocked-traffic cost entirely, and on most defended targets it lands cheaper per delivered page than a residential pool.

If that still fails, residential is the right spend. Configure sessions properly before blaming the pool — a crawl with wrong headers, too much concurrency or no session management fails in ways that look exactly like IP-level blocking.

Mobile is last, and only for mobile-first platforms or targets that have defeated a well-configured residential crawl.

At every step, measure your own success rate against your own target over a few thousand requests. That figure costs a few dollars to obtain and is worth more than every published comparison, including this one.