Imagine you're buying proxies for a scraping job. You've narrowed it down to two options.
One charges $1 per GB. The other charges $5.
If you're mainly comparing pricing tables, the first option looks like an easy choice. Why pay five times more for bandwidth?
Well, because bandwidth isn't what you're actually trying to buy. You're trying to get usable data.
Let's put some numbers on it.
You need to collect 1,000 pages. Both proxy options transfer an average of 0.5 MB of billable traffic per request attempt, but their success rates are different.
| Proxy A | Proxy B | |
|---|---|---|
| Price per GB | $1 | $5 |
| Usable response rate | 10% | 80% |
| Expected attempts for 1,000 usable pages | 10,000 | 1,250 |
| Billable traffic | 5 GB | 0.625 GB |
| Proxy cost | $5.00 | $3.13 |
I'm using hypothetical numbers here, not results from testing actual providers. And I'm assuming 1 GB = 1,000 MB to keep the arithmetic straightforward.
The cheaper proxy ends up costing about 60% more to complete the same job.
The difference comes from all the failed attempts you're still paying for.
There's a useful break-even point in this example, too. With the same amount of billable traffic per attempt, a proxy costing five times more per GB needs to deliver more than five times the usable response rate to be cheaper on proxy bandwidth alone.
Here, that's 80% versus 10%.
But real requests aren't this neat
A failed request doesn't necessarily transfer the same amount of data as a successful one.
A block page might be tiny. A successful page might be several megabytes. You could also be dealing with retries, timeouts, geographic restrictions, or requests that return HTTP 200 but contain a CAPTCHA instead of the data you wanted.
That last part matters more than it might seem.
If you're scraping product prices and a request returns a page without the price, did it succeed?
From an HTTP perspective, maybe. From the perspective of your scraping job, no.
That's why I'd be careful with any comparison based only on a provider's reported success rate. You need to know what they're counting as a success, and whether the test resembles your workload.
There's also no universal guarantee that the $5 proxy performs better. It might perform exactly the same as the $1 option, in which case you're simply paying more.
A more useful number to calculate
For a real job, I'd look at the actual billed proxy cost and the number of results that passed whatever validation the job requires.
The calculation is straightforward:
Cost per 1,000 usable results = (total billed proxy cost / number of usable results) × 1,000
Then I'd look at completion time, retries and operational overhead separately. Proxy bandwidth isn't necessarily the largest expense in the whole pipeline.
You also need to test against representative targets. Getting good results from ten easy pages doesn't tell you much about a workload involving thousands of pages across different sites and regions.
And if your task requires persistent sessions, a particular country, or strict concurrency limits, those requirements can eliminate an otherwise cheap option before you even get to the price comparison.
Work out what a usable result costs for the job you're actually running.
Sometimes $1/GB really is the better deal. Sometimes it isn't.
Disclosure: I'm building ProxyClarity, a tool for comparing proxies and infrastructure based on workload requirements. We don't have our own live proxy performance benchmarks yet. The figures in this article are illustrative, not measured provider results.
Top comments (0)