Success rate sounds like one number, but it depends on three choices: what counts as success, which target was tested, and over what period. A request can connect but return an error, return 200 OK with a CAPTCHA page, or return the right page slowly. Each definition gives a different figure, which is why vendor headline numbers are hard to compare with each other or with your own job.
Define success before you measure
Sort every response into one bucket:
| Outcome | Example | Counts as |
|---|---|---|
| Proxy failure | Timeout, 407, 502 from the proxy | Failure |
| Hard block | 403, 429 from the site | Failure |
| Soft block | 200 with a challenge or empty result | Failure |
| Good | 200 and the element you came for is present | Success |
The soft-block row is the one most tests miss. Check for a selector or a string you expect on a real page, not just the status code.
Measure your own
Run a sample of real URLs from your target, at the concurrency you plan to use, and record the bucket, the exit IP and the time for each request. A few hundred requests spread across a day gives a usable figure; ten requests does not. How to test a proxy provider includes a script that does this and reports the results by category.
Reading the result
Report the rate with its definition, target, sample size and date, or it cannot be compared with anything. If the rate is low, the buckets tell you where to look: proxy failures point at the provider, hard blocks at your pace or IP type, soft blocks at your client's fingerprint. How to avoid getting blocked covers the fixes for each.