Most proxy testing consists of checking that a connection succeeds and an address other than yours comes back. That is a useful five-second sanity check and it tells you almost nothing about whether the proxy will do your job.
A proxy can connect perfectly, report a plausible foreign address, respond quickly, and still be worthless — because the site you actually care about blocks it, or because it is geolocated in a different country from the one you were sold, or because your hostname lookups are going somewhere else entirely.
We are Geonode and we sell proxies, which makes this article slightly against type: a good testing routine is how customers discover that a provider is not delivering, and we are telling you to run one on us. That is deliberate. The most expensive outcome in this market is someone paying for months on a service that never worked properly for their target, and it happens because the only test they ran was "does it connect".
The four tests below take about an afternoon to set up and roughly a minute to run thereafter. In rough order of how much they matter:
- Connectivity and reported address — fast, necessary, insufficient.
- Geolocation accuracy — whether the address is really where it was sold as being.
- Leaks — headers and DNS, both of which can undo the whole exercise.
- Success rate on your actual target — the one that decides everything.
Every endpoint recommended below was checked and responding at the time of writing. That is a low bar, but a surprising number of published guides recommend services that have been gone for years.
The Four Things Worth Testing
Before the commands, the reasoning — because knowing why each test exists tells you how to interpret a failure.
Connectivity
Does the proxy accept your connection, authenticate you, and forward the request? Does the address the destination sees belong to the proxy rather than to you?
This is table stakes and it is where most people stop.
Geolocation
An address sold as being in Berlin may be classified as being in Frankfurt, or in the Netherlands, or nowhere in particular. Geolocation databases disagree with each other, and the one your target uses is the one that matters, not the one your provider used.
This is a common and genuinely confusing failure: everything works, the proxy reports a German address, and the site keeps showing you Dutch content.
Leaks
Two kinds, both of which can silently defeat the purpose.
Header leaks. Some proxies add headers that disclose the original client address or announce that a proxy is in use. If your reason for using one is that the destination should see an ordinary user, a header saying otherwise is a problem.
DNS leaks. Your traffic goes through the proxy while hostname lookups happen locally. Your resolver — typically your ISP — sees every site you visit, and worse, a locally resolved hostname can return a regionally wrong address, so you connect to the wrong endpoint from the right country.
Success Rate on Your Target
The only test whose result transfers to your actual work.
Everything above is generic and measurable against public endpoints. None of it predicts whether the specific site you need will serve you content. A proxy that passes all three earlier tests can still be blocked outright by your target, and one that looks unremarkable can work perfectly.
Measure this before you buy anything at volume. It is the difference between a proxy that works and a proxy that connects.
Does It Connect and What Address Shows
The basic test, with endpoints verified as responding at the time of writing.
The One-Liner
curl -x http://user:pass@proxy.example.com:8080 https://api.ipify.org?format=json
If you get back an address that is not yours, the proxy is working at the most basic level.
Useful Endpoints
| Endpoint | Returns |
|---|
https://api.ipify.org?format=json | Address only, minimal and fast |
https://httpbin.org/ip | Address, in JSON |
https://ipinfo.io/json | Address plus location and network details |
http://ip-api.com/json | Address plus detailed geolocation |
https://ifconfig.me/all.json | Address plus the headers you sent |
That last one is worth knowing about, because it reflects your request back at you — which is how you check for header leaks without any special tooling.
Compare Against Your Real Address
# Without the proxy
curl -s https://api.ipify.org
echo
# With it
curl -s -x http://user:pass@proxy.example.com:8080 https://api.ipify.org
Two different values means the proxy is in the path. The same value means it is not — and this happens more often than you would think, usually because of a typo in the proxy URL that curl silently ignored.
Add -v if they match, and check which host curl actually connected to.
The Failures and What They Mean
Connection refused — wrong host or port, or the proxy is down.
407 Proxy Authentication Required — credentials wrong or missing. Note that some providers authenticate by allowlisting your own address instead, in which case your current address may not be on the list.
Timeout — the proxy is unreachable or overloaded. Add --max-time 10 so you find out quickly rather than waiting.
It works but the address is yours — the proxy setting is not being applied. Check for typos, and check whether an environment variable is overriding what you passed.
Test SOCKS Properly
curl -x socks5h://user:pass@proxy.example.com:1080 https://api.ipify.org
Note socks5h, not socks5. The h makes the proxy resolve hostnames rather than your own machine — which is the DNS leak covered below, and the single most common half-working configuration in this field.
Geolocation Accuracy
The test that catches a genuinely common problem nobody warns you about.
The Command
curl -s -x http://user:pass@proxy.example.com:8080 http://ip-api.com/json | python3 -m json.tool
You get country, region, city, and the organisation the address belongs to.
What to Check
Country matches what you paid for. The obvious one, and it fails more often than it should on cheaper pools.
City is plausible. If you bought a Manchester address and it reports as London, that may be fine for most purposes and fatal for local search testing.
The organisation looks like a consumer ISP if you bought residential. If it reports a hosting company, you have a datacenter address regardless of what it was sold as — and this is worth checking specifically, because it is the difference between a product that works on protected sites and one that does not.
The Part That Confuses People
Geolocation databases disagree. There is no authoritative mapping from address to place; there are several commercial databases that infer it from registration data, routing and observation, and they are updated at different times with different methods.
So an address can be:
- Berlin according to one database
- Frankfurt according to another
- Germany but no city according to a third
- The Netherlands according to a fourth, because it was reassigned recently
Your target uses one of those, and you do not know which. This is why an address that tests as German can still produce Dutch content on the site you care about, and why the only conclusive geolocation test is on the target itself.
The Practical Test
Check two or three databases, then check the target:
PROXY="http://user:pass@proxy.example.com:8080"
curl -s -x $PROXY http://ip-api.com/json | python3 -m json.tool
curl -s -x $PROXY https://ipinfo.io/json | python3 -m json.tool
If they agree, you probably have what you bought. If they disagree, the target's opinion is the only one that counts — load the actual site through the proxy and see which currency, language or regional content appears.
Headers and DNS Leaks
Two silent failures, both easy to check and rarely checked.
Header Leaks
Some proxies add headers that either disclose your original address or announce that a proxy is involved. Check by having the destination reflect your request back:
curl -s -x http://user:pass@proxy.example.com:8080 https://httpbin.org/headers | python3 -m json.tool
Headers that should not be there:
X-Forwarded-For containing your real address. Via. X-Real-IP. Forwarded. Proxy-Connection. Anything naming a proxy vendor.
A proxy that adds X-Forwarded-For: your.real.address has, from a concealment point of view, done nothing at all — it has just written your address into the request for the destination to read.
The three anonymity levels you will see described in this industry map directly onto this test. Transparent proxies forward your address in headers. Anonymous proxies do not forward it but do identify themselves as proxies. Elite proxies do neither. The command above tells you which you have, and it is worth running rather than trusting a listing.
DNS Leaks
Harder to test with a single command, and more consequential than most people realise.
The problem: your traffic goes through the proxy, but the hostname lookup happens on your own machine. Your resolver learns every site you visit even though the traffic is routed elsewhere.
With curl and SOCKS, the fix is one character:
# Leaks the lookup to your local resolver
curl -x socks5://proxy.example.com:1080 https://example.com
# Proxy resolves the hostname
curl -x socks5h://proxy.example.com:1080 https://example.com
With HTTP proxies, hostname resolution normally happens at the proxy, so this is less of an issue — but verify rather than assume, particularly if a client library is involved.
Why it is not only a privacy question: a locally resolved hostname can give you a regionally different server. If you are proxying through Germany but resolving from Britain, you may connect to the British endpoint from a German address. That combination is both wrong for your purpose and unusual enough to be noticed.
The Check
Use a DNS leak testing service through the proxy and confirm the resolvers reported belong to the proxy's network rather than yours. It takes thirty seconds and it is the highest-value verification in this article after the target test.
Success Rate on Your Actual Target
The test that matters more than the other three combined, and the one almost nobody runs before buying.
Why the Generic Tests Do Not Predict It
Every test so far measures the proxy against neutral public endpoints that have no reason to block anyone. Your target is not neutral. It may check address origin, maintain its own blocklists, apply rate limits, fingerprint your client, or serve different content by region.
A proxy that passes every generic test can be blocked outright by your target. One that looks entirely ordinary can work perfectly. The generic tests tell you the proxy functions; only the target tells you it works.
The Method
Take a representative sample of the URLs you actually need — not the homepage, the pages your job touches. Fifty to a few hundred is enough to be meaningful.
Run them through the proxy. Record:
How many succeeded, where success means the response contained the content you wanted — not that it returned HTTP 200.
How much bandwidth was consumed, including the failures.
How long each took.
The Trap in Counting Successes
This deserves its own warning because it survives for months in production systems.
Do not count HTTP 200 as success. The characteristic failure mode here is a plausible page with the wrong contents: a challenge page, a soft block, a "we noticed unusual activity" interstitial, a regional variant, or an empty result set that looks exactly like a legitimately empty result set. All of these return 200.
Check for something that only appears on a genuinely successful page — a price, a product title, a specific element, a minimum content length. A success counter that trusts the status code will report excellent numbers while collecting nothing.
The Number That Matters
cost per successful request = (bandwidth used × price per GB) ÷ successes
This is the only figure that compares providers meaningfully, because failed requests consume paid bandwidth exactly like successful ones. A cheaper proxy with a poor success rate on your target can cost more per result than an expensive one that works.
Run this against two or three providers on the same morning, with the same target list and the same concurrency, and the ranking frequently differs from the price list. That is the point of doing it.
A Script That Tests a Whole List
Testing one proxy by hand is fine. Testing two hundred needs a script.
import concurrent.futures
import time
import requests
TEST_URL = "https://api.ipify.org?format=json"
TIMEOUT = 10
def check(proxy):
"""Return a dict describing one proxy's behaviour."""
proxies = {"http": proxy, "https": proxy}
started = time.perf_counter()
try:
r = requests.get(TEST_URL, proxies=proxies, timeout=TIMEOUT)
elapsed = time.perf_counter() - started
if r.status_code != 200:
return {"proxy": proxy, "ok": False, "error": f"HTTP {r.status_code}"}
return {
"proxy": proxy,
"ok": True,
"ip": r.json().get("ip"),
"seconds": round(elapsed, 2),
}
except Exception as exc:
return {"proxy": proxy, "ok": False, "error": type(exc).__name__}
def main(proxy_list, workers=20):
with concurrent.futures.ThreadPoolExecutor(max_workers=workers) as pool:
results = list(pool.map(check, proxy_list))
working = [r for r in results if r["ok"]]
print(f"{len(working)}/{len(results)} responded")
for r in sorted(working, key=lambda x: x["seconds"]):
print(f"{r['seconds']:>6}s {r['ip']:<16} {r['proxy']}")
for r in results:
if not r["ok"]:
print(f" FAIL {r['proxy']} ({r['error']})")
if __name__ == "__main__":
main([
"http://user:pass@proxy1.example.com:8080",
"http://user:pass@proxy2.example.com:8080",
])
Things Worth Noting In It
Every request has a timeout. Without one, a single unresponsive proxy hangs a worker indefinitely and the run never finishes. This is the most common defect in homemade proxy checkers.
Exceptions are caught and classified, so one bad entry does not stop the run and you can see whether failures are timeouts, refusals or authentication problems.
It runs concurrently, because two hundred proxies tested one at a time with a ten-second timeout is a long lunch.
It records duration, which is the basis of the speed comparison in the next section.
Extending It Usefully
Swap TEST_URL for your actual target and replace the status check with a content check. That converts it from a connectivity checker into the success-rate test from the previous section, which is where the real value is.
Run it on a schedule and store the results. Proxy pools change, and a list that worked last month is not evidence about today.
Speed and Latency, Measured Properly
Speed matters less than people think and is measured badly more often than not.
Get the Breakdown, Not a Single Number
curl can tell you where the time actually went:
curl -s -o /dev/null -x http://user:pass@proxy.example.com:8080 \
-w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
https://example.com
The gaps between these numbers tell you what is slow: name resolution, the TCP handshake, the TLS negotiation, or the server thinking. A single total figure tells you none of it, and "the proxy is slow" is frequently "the target is slow".
Measure Repeatedly, Not Once
One measurement is noise. Run ten and take the median, and note the worst case.
The 95th percentile matters more than the average for anything running at volume. An average of 400 ms hides the fact that one request in twenty takes eight seconds, and at scale those are what fill your worker pool.
Compare Like With Like
Same target, same time of day, same concurrency. Residential pool composition shifts with when real users are online, so a test at 3 a.m. and a test at 6 p.m. measure different networks.
Keep It in Proportion
Residential proxies are slower than datacenter proxies, and that is inherent — they route through consumer broadband rather than data centre backbone. Comparing them on speed alone will always favour datacenter addresses, which is not useful information if datacenter addresses do not work on your target.
Rank on success rate first. Compare speed only among the options that actually work. A fast proxy that gets blocked is worth nothing; a slower one that returns content is worth everything.
What Proxy Checker Sites Cannot Tell You
The free web-based checkers are genuinely useful for one thing and misleading for several others.
What They Do Well
Quick verification that a proxy is alive and reachable, and a rough anonymity classification from the headers it forwards. For triaging a large list of unknown proxies, that is real value for no effort.
What They Cannot Do
Predict your target. They test against themselves. Your target has different defences, different blocklists and different regional behaviour. This is the entire limitation and it is a large one.
Tell you about geolocation as your target sees it. They use one database. Your target uses another.
Measure success rate over time. A single check is a snapshot. Pools rotate, addresses get reused, and reputation changes hourly.
Test authentication properly. Many checkers only accept host and port, so anything with credentials cannot be tested there at all.
The Part Worth Being Careful About
If you paste working proxies with credentials into a third-party checker, you have handed a stranger a working set of credentials.
For free public proxies that is no loss. For paid proxies it is genuinely careless — those credentials are attached to your account and your bill. Test paid proxies with your own commands, not on someone else's website.
On Free Proxy Lists Generally
A related warning, since testing tools and free lists tend to travel together. A free public proxy is a machine whose operator has volunteered to relay strangers' traffic at their own expense. The plausible reasons for that are limited, and "seeing what passes through" is prominent among them.
They are also unreliable by nature: overloaded, short-lived, and frequently already blocked by anything worth accessing. Testing them tells you which ones respond right now, which is a fact with a very short shelf life.
People Also Ask
How do I check if a proxy is working?
Request an address-reporting endpoint through it and compare with your real address: curl -x http://user:pass@host:port https://api.ipify.org. If a different address comes back, the proxy is in the path. If the same one comes back, the setting is not being applied — add -v and check what curl actually connected to.
How do I test a proxy's real location?
Request a geolocation endpoint such as http://ip-api.com/json or https://ipinfo.io/json through the proxy. Check two of them, because geolocation databases disagree. If they conflict, the only opinion that counts is your target's — load the actual site and see which regional content appears.
How do I know if my proxy is leaking my IP?
Request https://httpbin.org/headers through the proxy and look for X-Forwarded-For, Via, X-Real-IP or Forwarded containing your real address. A proxy that forwards your address in a header has concealed nothing.
What is a DNS leak with a proxy?
Your traffic goes through the proxy but hostname lookups happen on your machine, so your own resolver sees every site you visit. With curl and SOCKS, use socks5h:// rather than socks5:// so the proxy resolves names. It can also cause you to reach a regionally wrong server.
How do I test many proxies at once?
A short concurrent script — a thread pool, one request per proxy, a timeout on every request, and exceptions caught so one bad entry does not stop the run. The timeout is the part people omit, and without it a single unresponsive proxy hangs the whole test.
What is a good proxy success rate?
Above roughly 95% on your target is healthy. Below about 80%, retries start dominating your bandwidth and your effective cost per result climbs quickly. The number is target-specific, so a rate measured against one site says nothing about another.
Should I use an online proxy checker?
For triaging unknown free proxies, yes. For paid proxies, no — pasting working credentials into a third-party site hands a stranger access billed to your account. Use your own commands instead.
How often should I test proxies?
Continuously for anything in production, as a health check rather than a one-off. Pools rotate, addresses get reassigned and reputations change. A test result is a fact about a moment, not a property of the service.
Wrapping Up
Four tests, and they are not equally important.
Connectivity takes one command and is necessary but nearly meaningless on its own. Geolocation catches a real and confusing failure, with the caveat that databases disagree and only your target's opinion decides anything. Leak checks — headers and DNS — take a minute each and can reveal that a correctly connecting proxy is doing nothing useful.
Success rate on your actual target is the one that matters, and it is the one almost nobody runs before committing. Take fifty real URLs, run them through, and count successes by checking for content you expect rather than HTTP 200 — because challenge pages, soft blocks and empty results all return 200, and a success counter that trusts the status code will report excellent numbers while collecting nothing.
Then divide bandwidth by successes to get cost per successful request. Failed requests consume paid bandwidth exactly like successful ones, which is why the cheapest provider per gigabyte is regularly not the cheapest per result.
A few practical notes. Put a timeout on every request in any test script, or one dead proxy hangs the run. Measure the 95th percentile rather than the average, because that is what fills your workers at scale. Rank on success rate first and compare speed only among the options that actually work. And do not paste paid proxy credentials into third-party checker websites.
We sell proxies and we would rather you tested ours properly than bought on a rate. The customers who run this routine before committing are the ones who stay, because they bought something that demonstrably worked rather than something that connected.
