Proxy Tester: Check If Your Proxies Actually Work

A proxy that fails silently costs more than one that fails loudly. A dead proxy in a rotation list produces timeouts you attribute to the target. A proxy that geolocates somewhere other than advertised produces data labeled with the wrong market. A proxy that leaks identifying headers produces results that do not match what a real user sees. None of these announce themselves — they just quietly degrade your output.

Testing proxies before you use them catches all three in a few seconds. The FlameProxies proxy tester is a free browser tool for exactly this: paste proxies, run the check, read the results.

What a Proxy Test Should Tell You

Connectivity is the obvious check and the least informative. These are the dimensions that actually matter:

Reachability. Does the proxy accept a connection and complete a request? Separates dead entries from live ones.

Authentication. Do the supplied credentials work? A 407 here means wrong credentials, expired access, or an IP allowlist that does not include you — a different problem from a dead proxy, and worth distinguishing immediately.

Latency. How long does the round trip take? Connection time and time-to-first-byte are what determine your achievable throughput per thread.

Exit IP. What address does the destination actually see? Confirms the proxy is doing its job, and gives you the address to check everything else against.

Geolocation. Which country and city does the exit IP resolve to? This is where advertised and actual frequently diverge.

IP type and network. Is it residential, datacenter, mobile, or hosting? Which ASN and ISP? This determines how targets will classify your traffic, and it is the single most predictive attribute for whether a proxy will work on a protected site.

Anonymity level. Does the proxy forward headers that reveal your origin IP or announce itself as a proxy? Some proxies pass X-Forwarded-For or Via headers that make the arrangement obvious to the destination.

Protocol support. Does it work over HTTP, HTTPS, and SOCKS5 as claimed?

Using the Tester

Paste proxies in standard notation — host:port for open proxies, host:port:username:password for authenticated ones — one per line, and run the check. Results come back per proxy with the dimensions above.

It works with any proxies, not only FlameProxies. If you are evaluating a provider, auditing a list you inherited, or debugging why a subset of your rotation keeps failing, paste them in and read the breakdown.

Reading the Results

Connection failed

The proxy did not accept a connection. Causes, roughly in order of likelihood: the entry is dead or expired, the host or port is wrong, the provider's gateway is down, or your network blocks outbound traffic on that port. If a whole batch from one provider fails together, suspect the gateway or your egress rules rather than the individual entries.

Authentication failed

The proxy is alive but rejected your credentials. Check the username and password first, then the parameter syntax if you are encoding targeting into the username — a malformed parameter string fails authentication on many gateways, which is confusing because the credentials themselves are fine. If you use IP allowlisting, confirm your current outbound IP is on the list.

Works, but geolocation does not match

The most important failure to catch, because nothing downstream will flag it. You requested one city and received another, or the country is simply wrong.

This happens through several mechanisms. The provider may have silently fallen back when your requested location was unavailable. The geolocation databases may genuinely disagree about this address. Or the pool's coverage in that market may be thinner than advertised, with addresses borrowed from nearby regions.

Whatever the cause, using it for location-sensitive work produces wrong-market data. Discard the proxy for that market, and if a pattern emerges across many addresses, take it up with the provider.

Works, but IP type is wrong

You bought residential and the tester reports a hosting provider in the ISP field. The address will be classified as datacenter by any target that checks, which means it will fail on exactly the protected sites you bought residential IPs to reach.

This one is worth checking in bulk rather than on single samples. Test a few hundred addresses and look at the distribution of ISP and ASN values. A genuine residential pool shows consumer ISP names spread across many autonomous systems. Clustering in a few ASNs, or hosting provider names appearing at all, tells you something about what you actually bought.

Works, but anonymity is poor

The proxy forwards headers that reveal your origin or announce itself. For most data collection this is disqualifying — the destination can see both that you are using a proxy and, in the worst case, where you really are.

Works, but latency is high

Not necessarily a failure. Residential proxies routing through consumer connections are legitimately slower than datacenter ones, and some geographic routes are simply long. The question is whether the latency fits your workload. Judge it against the distribution across your pool rather than against an absolute number, and pay attention to outliers — a handful of very slow addresses in a rotation will tie up threads disproportionately.

When to Test

Before buying. Run a provider's trial proxies through the tester before committing. Geolocation accuracy and IP type are verifiable in minutes and tell you more than any marketing page.

When onboarding a new market. Coverage quality varies enormously by country. Accuracy in one market predicts nothing about another, so test each one you plan to use.

When a success rate drops. If collection degrades, testing a sample of your rotation separates "my proxies went bad" from "the target changed." That distinction saves a lot of wasted investigation.

Periodically, as maintenance. Pool composition drifts. Addresses get reallocated, reclassified, and recycled. Accuracy that was excellent at onboarding degrades quietly. Periodic sampling catches drift that one-time validation misses.

When auditing an inherited list. Lists handed over from another team or bought in bulk are usually part dead. Testing tells you what fraction is live before you build anything on it.

What a Quick Test Does Not Cover

Worth being clear about the limits. A tester checks a proxy against a neutral endpoint. It cannot tell you:

Whether it works on your specific targets. A proxy that passes every check here may still be blocked by a particular site whose bot management has seen the address before. Real success rate is measured against your own targets.

How it behaves under concurrency. Single-request results say nothing about what happens at fifty parallel sessions. Latency and error rates can change substantially under load.

Whether accuracy holds over time. A point-in-time check is exactly that.

Pool depth. Testing individual addresses tells you about those addresses, not about how many usable ones exist behind the gateway at your required concurrency.

For those dimensions you need a sustained test against your own targets. The tester is the fast first filter that eliminates obviously broken proxies before you spend time on the slower, more expensive evaluation.

Pairing It With the Other Tools

The tester works well alongside the rest of the FlameProxies tools. Use whatsmyip to confirm what a browser or desktop connection is actually presenting, and the tester for checking proxies in bulk before they go into a rotation list. Together they cover both "what am I presenting right now" and "which of these hundred proxies are worth keeping."

FlameProxies proxies pass these checks by design — residential IPs with accurate country and city targeting across 180+ countries, correct IP type classification, and no identifying header leakage — and the tester is deliberately provider-agnostic so you can verify that claim against whatever else you are considering.