How to Test if a Proxy Is Working (and Actually Hiding You)

“The proxy works” can mean four different things: it accepts your connection, it returns the country you paid for, it handles HTTPS, and it does not leak your real IP. A proxy can pass the first test and fail the other three. Here is how to check each.

1. Does it respond at all?

curl -x http://USER:PASS@HOST:PORT https://api.ipify.org

A different IP than your own means it works. If it hangs, you likely have the wrong port or a firewall in the way. If you get 407, authentication failed — see proxy error codes.

Add -v when it fails. The verbose output shows whether the TCP connection was established, which separates “cannot reach the proxy” from “the proxy refused me”.

2. Is it the right country?

Paying for a German IP and getting a Dutch one matters for geo-restricted work.

curl -x http://USER:PASS@HOST:PORT https://ipinfo.io/json

You will get country, region, city and the owning organisation. That last field is worth reading: if org names a hosting company on a proxy you bought as residential, you are not getting what you paid for.

Geolocation databases disagree with each other and lag reality by weeks. If one says Germany and another says Austria, check a second source before assuming the proxy is wrong.

3. Does HTTPS work through it?

Plenty of proxies handle plain HTTP and break on TLS.

curl -x http://USER:PASS@HOST:PORT -I https://www.google.com

You want a 200 or 301. A TLS error here usually means the proxy is trying to intercept the connection rather than tunnelling it with CONNECT. That is a serious problem: it means someone can read your traffic.

4. Is it leaking your real IP?

This is the test people skip, and the one that matters most.

Header leaks. Badly configured proxies forward your real address in X-Forwarded-For or Via:

curl -x http://USER:PASS@HOST:PORT http://httpbin.org/headers

Read the output. If your home IP appears anywhere, the proxy is not anonymous regardless of what the IP-check said.

DNS leaks. With an HTTP proxy your client usually resolves the hostname locally, so your ISP’s resolver sees every domain you visit even though the traffic goes through the proxy. With SOCKS5 you can push resolution to the proxy — in curl, use socks5h:// rather than socks5://:

curl -x socks5h://USER:PASS@HOST:PORT https://api.ipify.org

The h is the whole point. It is easy to miss and silently leaks otherwise. See SOCKS5 vs HTTP for when each makes sense.

5. Does it survive a real target?

Generic IP-check endpoints do not block anyone. The site you actually care about might:

curl -x http://USER:PASS@HOST:PORT -o /dev/null -w "%{http_code}\n" https://your-real-target.com

A 403 here on a proxy that passed every test above means the IP itself is distrusted — usually a datacenter range. That is not a broken proxy, it is the wrong type for the job.

Testing several at once

while read -r p; do
  code=$(curl -s -x "$p" -o /dev/null -w "%{http_code}" -m 10 https://api.ipify.org)
  ip=$(curl -s -x "$p" -m 10 https://api.ipify.org)
  echo "$code  ${ip:-no-response}  $p"
done < proxies.txt

With one proxy per line as http://user:pass@host:port. The 10-second timeout stops one dead proxy stalling the run.

What “working” should mean

Before you put a proxy into production, it should: return a different IP, return the country you bought, complete a TLS request, expose none of your own address in headers, and resolve DNS remotely if you are using SOCKS5. Four of those five are one curl command each.

Every proxy we sell can be checked this way the moment it appears in your dashboard — see pricing for what each type costs, or contact us if a proxy fails any of these tests.