Success rate
The share of requests that come back with the data you wanted, the metric that actually measures a proxy's worth.
Success rate is the fraction of requests that return the intended result rather than a block, a CAPTCHA, an error or an empty page. It is the number that matters most and the one advertised least, because it depends on the hard, changing reality of how a target treats your traffic, not on a headline pool size.
It is also where cheap proxies reveal their true cost. A pool of tainted addresses might quote a low price per gigabyte, but if half the requests fail you pay for the failures too, in wasted traffic and in retries, so the effective cost per successful result is far higher than the sticker.
The right way to compare proxies is therefore to measure success rate against your actual targets, not to compare pool counts or per-gigabyte rates in the abstract. A clean pool with a high success rate beats a huge one with a low one at almost any price.
The arithmetic is worth doing explicitly, because it inverts most price comparisons. A pool at half the per-gigabyte rate with a 50% success rate costs you the same per successful result as one at twice the price with 100%, before you count the retries, the wasted traffic on failed attempts and the engineering time spent chasing failures. Effective cost per success is the only number that reflects what you actually pay.
A definition trap sits underneath all of it, though, and it is the reason success rate is so easy to quote misleadingly. A request that returns HTTP 200 has succeeded at the transport layer and may still have failed completely: a CAPTCHA page returns 200, a block page returns 200, a page with prices quietly substituted for another region returns 200. If your measurement counts status codes, it is measuring the wrong thing and will report excellent numbers while your dataset degrades.
So a success rate is only meaningful with its definition attached. Ours should be, and so should a provider's. The version worth measuring is whether the response contained the data you came for, which means validating content rather than counting responses.
It is also not a fixed property of a proxy, which is why quoted figures deserve suspicion. The same pool can perform beautifully on one target and poorly on the next, because the number describes a relationship between an address and a destination rather than a quality of the address alone. Any provider quoting one number for all targets is quoting an average of things you do not care about.
Frequently asked questions
How should I measure proxy success rate?
By whether the response contained the data you wanted, not by status code. A CAPTCHA page, a block page and a regionally substituted page all return 200 and all failed. Validate a field you expect on every page, a price, a title, an item count, and count only responses that carry it. Anything else measures the transport and not the outcome.
What is a good success rate?
It depends entirely on the target, which is why an absolute number is not meaningful. An unprotected site should approach 100% and anything below that indicates a problem on your side. A heavily defended one may be good at a much lower figure. Compare providers against the same target rather than against a benchmark, and treat any single quoted number covering all sites as an average of irrelevant things.
Why is a cheaper proxy sometimes more expensive?
Because you pay for failures too. At half the rate with half the success, the cost per useful result is identical before counting retries, the bandwidth spent on failed attempts, and the engineering time spent diagnosing them. Effective cost per success is the comparison that matters; per-gigabyte price alone routinely points the wrong way.
Can success rate be improved without changing provider?
Often, and it is worth trying first. Most failures come from layers a proxy does not control: a TLS fingerprint that identifies your client, a browser fingerprint contradicting the exit's country, pacing too regular to be human, or concurrency high enough to trip a limit. Fix those and the same addresses frequently perform much better.
Back to the full glossary.