The homepage number is not the test
A pool headline measures the wrong thing. A provider can advertise tens of millions of IPs and still come up short on your country, your protocol, your target, or the session length you need, because the only part of that pool that matters to you is the slice that overlaps all four of those constraints at once. A hundred million exits worldwide is cold comfort when nine hundred of them are in the country you are billing for and half of those refuse the site you are scraping.
So the goal of any pool test is to measure that overlap directly. Pin down the exact country, protocol, and session behavior you intend to use, then push real traffic through it against your actual target or a close substitute, and count what survives rather than what was advertised.
Build a small pool audit
The audit itself is deliberately modest. A few hundred requests per country slice is enough to see the shape of a pool, and keeping it small means you can stop the moment the answer is obvious instead of paying to confirm bad news. For each request, record the exit IP, ASN (IANA AS numbers registry), country, status, and latency, and keep HTTP and SOCKS5 (RFC 1928) results in separate columns, since a pool that looks healthy over HTTP can quietly collapse the moment you switch protocols on the same plan.
- Run 100 to 500 requests per country slice.
- Record exit IP, ASN, country, status, and latency.
- Separate HTTP and SOCKS5 results.
- Run sticky sessions for the full session length you need.
- Measure billed GB, not only response body size.
One trap worth avoiding: do not run the whole test against a single public IP echo site, because that measures the echo site's tolerance as much as the pool's behavior. Point the traffic at your own logging endpoint where you can, so the only variable being tested is the proxy.
Where pool claims disappear
Most advertised pool numbers are technically true and practically useless, and they tend to evaporate at the same few points. The table below pairs the common claim with the question that actually tests it, so you can see where a big headline shrinks into the slice you can use.
| Claim | Reality check |
|---|---|
| Large global pool | How many exits appear in your country? |
| SOCKS5 support | Does SOCKS5 work on the same pool and plan? |
| Sticky sessions | How long does the same exit remain stable? |
| Premium quality | Does target block rate actually improve? |
Ask the uncomfortable vendor questions
A few questions feel awkward to ask and are exactly the ones worth asking: whether exits are shared with other customers, how rotation is assigned, which target categories are restricted, and whether failed requests against your target are still billed. None of this is rude. Each one maps to a line item you will otherwise discover on an invoice, and a vendor who answers them plainly is telling you the pool number was never the whole story.
Pool audit CSV columns
The audit is only useful if you can run it the same way twice, so keep the format boring enough that one person can read it in a spreadsheet without any custom tooling. A flat CSV does the job:
timestamp,provider,pool,country,protocol,session_label,exit_ip,asn,target,status,latency_ms,bytes,retry
2026-06-11,example,res-us,US,http,batch-12,203.0.113.10,AS1234,example.com,200,842,18431,0Once you have a few hundred rows, sort by ASN and by status and read the clusters. When most of the failures pile up inside a single ASN, you are looking at a pool-shape problem, where the provider's "large global pool" is really one network doing most of the work. When every ASN fails on the same target instead, the pool itself is healthy and the target's policy is blocking you, which is a different problem with a different fix.
What a bad pool test looks like
The fastest way to waste a day is to change too many things at once. A test that uses one country for provider A and another for provider B, curl on one run and a browser on the next, with no fixed retry policy, produces a table that looks scientific and answers nothing, because you can no longer tell whether the difference came from the pool or from your own setup.
A trustworthy run holds everything else still: same target, same hour, same client, same timeout, same country, same concurrency, same retry limit, varying only the provider. If one vendor needs a special configuration before it looks good, that is itself a finding worth writing down, because the operational friction of getting a pool to behave is part of its real cost. A genuine pool survives a plain test, and when a vendor's only response is that your test was unfair, the advertised number is probably not the number you get to use.
Decision rule
A pool test is worth running only if it ends in a decision: keep the pool, switch the country, switch the protocol, drop the concurrency, or stop buying. A run that produces a screenshot and a vague good feeling has done nothing useful. The job is to turn a vendor's claim into a number your workflow can act on. Save the CSV, rerun it after any pricing or routing change, and compare the trend against the same file next month rather than against your memory of how it felt. Repeatable evidence beats a larger advertised pool, so keep the records.
Pool-size FAQ
Can a huge pool still fail? Yes. Your usable slice may be small after country, protocol, ASN, and target restrictions.
How many requests make a test? Start with hundreds, not tens. Keep it small enough to stop fast.
What should I export? Exit IP, ASN, country, status code, target host, latency, and proxy label.