The homepage number is not the test
A provider can advertise a huge pool and still fail your country, protocol, target, or session length. You need to test the slice you will actually use.
Ask for the exact country, protocol, and session behavior. Then run traffic against your real target or a close substitute.
Build a small pool audit
- 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.
Do not overfit one public IP echo site. Use your own logging endpoint when possible.
Where pool claims disappear
| 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 uncomfortable vendor questions
Ask whether exits are shared, how rotation is assigned, what categories are restricted, and whether failed target traffic is still billed. You are not being rude. You are finding the bill before it finds you.
Pool audit CSV columns
Make the test boring enough to repeat. Use a CSV that one person can inspect without custom tooling.
timestamp,provider,pool,country,protocol,session_label,exit_ip,asn,target,status,latency_ms,bytes,retry
2026-05-16,example,res-us,US,http,batch-12,203.0.113.10,AS1234,example.com,200,842,18431,0After a few hundred rows, sort by ASN and status. If most failures cluster in one ASN, you found a pool-shape problem. If all ASNs fail on one target, you found a target-policy problem.
What a bad pool test looks like
A bad pool test changes too many things at once. It uses one country for provider A, another country for provider B, curl for one run, a browser for another run, and no fixed retry policy. The result looks scientific but cannot answer anything.
Keep the run boring. Same target, same hour, same client, same timeout, same country, same concurrency, same retry limit. If one provider needs a different setup to look good, write that down. Operational friction is part of quality.
Pool claims should survive a simple test. If the vendor answer is always that your test was unfair, the pool number is probably not the number you can use.
Decision rule
A useful pool test ends with a decision. Keep the pool, change the country, change the protocol, lower concurrency, or stop buying. If the test produces only a screenshot and a vague feeling, it failed. The point is to reduce vendor claims into numbers your workflow can act on. Save the CSV and rerun it after pricing or routing changes. Repeatable evidence beats a larger advertised pool. Use the same file again next month. Compare trend, not memory. Keep receipts.
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.