Plenty of proxies look fine and aren’t. The credentials go through, pages load, nothing throws an error, and then the target site quotes US pricing while the dashboard insists the exit node sits in Frankfurt.
Five minutes of testing beats finding out three hours into a scraping run that the whole thing was broken from the first request. What follows runs roughly in order of what catches the most problems, starting with the check almost everyone does and ending with the ones almost nobody bothers with.
Is the traffic even going through?
Easy one first. Pull your public IP with the proxy off, pull it again with the proxy on, compare the two. Identical results mean nothing is routing anywhere.
curl handles this faster than any browser tab. Running curl -x http://user:pass@proxy.example.com:8080 https://api.ipify.org spits out the exit IP as plain text, and dropping the -x flag gives you the before picture.
The failure mode worth worrying about is the quiet one. A lot of HTTP clients fall back to a direct connection when the proxy refuses a handshake, so the request succeeds, the page renders, and nobody gets told a thing. Seeing your own IP come back with no error attached is a nastier outcome than a connection that just dies.
Skip the terminal if that’s not your thing. An online proxy checker hands back the exit IP, the country it maps to, the protocol, and the anonymity level in one go. That last field is the one people ignore.
Anonymity level is where cheap proxies fall apart
Transparent, anonymous, elite. Transparent proxies pass your original IP along in the request headers, which means the destination server ends up with both addresses and a fairly clear picture of what you’re doing.
The header to inspect is X-Forwarded-For, along with Via and the newer Forwarded header. Send anything through the proxy to httpbin.org/headers and read the response. If your real IP shows up in any of those fields, the proxy is waving at every site you visit.
Elite proxies strip the lot. For price monitoring or ad verification, that’s the only tier worth paying for.
The two leaks nobody checks
Most “but my IP was hidden” complaints trace back to DNS. The proxy carries the traffic properly, but the operating system still resolves domain names through your ISP’s resolver, and those lookups give the location away anyway. Both ipleak.net and dnsleaktest.com catch it in about five seconds.
WebRTC is sneakier. Browsers use it for peer-to-peer voice and video, and the API can cough up local and public addresses through JavaScript no matter what the proxy settings say. Mozilla’s documentation covers exactly what gets exposed, and switching it off or blocking it with an extension shuts the door.
Then test it on the actual target
Everything above can pass and the proxy can still be useless for the job you bought it for. Latency, throughput, and how many requests survive out of a few hundred tell you more than one clean handshake ever will.
Throw 50 to 100 requests at the real site and log the status codes. Mostly 200s with a stray 429 is workable. A wall of 403s usually means somebody burned that IP range months ago.
But a 407 is a different animal. That’s the proxy rejecting your credentials, one of the codes defined in RFC 9110, and not the site blocking you at all. Worth knowing before you fire off an angry support ticket.
And geolocation databases argue with each other constantly. Cross-check the exit IP on MaxMind, IP2Location, and ipinfo.io, because the site you actually care about might be reading a database that puts your German IP somewhere in Austria.
What’s coming
Detection keeps moving. TLS fingerprinting and behavioral analysis now flag sessions that sail through every IP-level test going, so a green light from a checker means the basics work and nothing more than that.
The habit worth building is folding these checks into the workflow instead of running them once at setup. A ten-line script that confirms exit IP, header leakage, and status codes before a job kicks off will find the broken proxy long before hour three does.
