How to Test Proxy Quality Before You Buy

Every provider claims millions of IPs and 99.9% uptime. Neither number is falsifiable from outside, and neither predicts whether your job will work. These nine checks take under an hour and are all runnable during a trial.

1. Confirm the exit IP

Route a request through the proxy to an IP echo service and confirm the address returned is not yours. Sounds trivial, and it catches misconfigurations constantly — particularly clients that silently ignore proxy settings for HTTPS. Our proxy tester does this in one step.

2. Check the ASN, not just the country

The ASN tells you who actually owns the address. A genuine residential IP belongs to a consumer ISP; if the ASN resolves to a hosting company, you have a datacenter proxy being sold as something else. This is the most common misrepresentation in the market and the easiest to detect.

3. Look up the fraud score

A fraud score aggregates an address's abuse history and hosting signals into a single risk figure that many sites consult. Low scores pass; high scores draw verification challenges and outright refusals on payment and signup flows. For account work this predicts outcomes better than any latency measurement. Ask which service produced the number and when — a zero from an unnamed tool certifies nothing.

4. Measure latency honestly

Measure from where your code will run, not from your laptop, and measure against your actual targets rather than a speed-test endpoint. Expect roughly 20–50ms added by an ISP proxy and 150–400ms by a residential exit. Anything far outside those ranges deserves an explanation.

5. Measure success rate on your targets

This is the one that matters. Send a few hundred requests to the sites you actually need, at the concurrency you actually intend to run, and record the proportion that return real content. Not HTTP 200 — real content, because bot walls return 200 with a challenge page.

A pool that is 99% successful on example.com and 40% successful on your target is a 40% pool. The average is not the number you are buying.

6. Check for leaks

A proxy that carries your traffic while your DNS queries resolve locally reveals your real location to any resolver-aware check. WebRTC can expose a local address from the browser independently of the proxy. Both are checkable in a couple of minutes with any leak-test site, and both are fatal for account work.

7. Probe the real pool size

You cannot verify a claim of millions of IPs, but you can measure what you receive. Make two hundred rotating requests to an echo service and count distinct addresses. Heavy repetition means the pool available to you in that location is far smaller than the headline figure — which is normal, and worth knowing before you scale.

8. Verify location accuracy

Request a specific city and check where the exits actually land, using more than one geolocation database. City-level accuracy in particular is often approximate, and databases disagree. If your use case depends on it — regional pricing, localised results — verify before committing.

9. Test session stability

If you need sticky sessions, hold one for the duration your workflow requires and check the exit IP at intervals. A session advertised as lasting 30 minutes that changes address after eight will break every checkout and login flow you build on it.

Questions to ask before paying

• How are residential IPs sourced? A provider that cannot explain consent has answered the question.
• Is an ISP IP dedicated to one customer? Shared means inheriting someone else's history.
• Does bandwidth expire? Monthly expiry turns unused data into a refundless loss.
• What is the actual pool size in the locations I need? Global figures hide thin regional coverage.
• Is there a trial or a small paid tier? Anything that lets you run check five before committing.