How to check a proxy: a seven-step order instead of guesswork

Step 1: does the gateway name resolve

The most common cause mistaken for a dead proxy. curl has separate exit codes for this: 5 means the proxy name did not resolve, 7 means the proxy could not be connected to. Two entirely different cases that look identical in GUI tools.

curl -sS -x http://GATEWAY:PORT https://example.com -o /dev/null; echo "exit=$?"

# exit=5  -> DNS did not resolve the gateway name (typo, your DNS, a corporate gateway)
# exit=6  -> the target site's name did not resolve
# exit=7  -> the gateway refused the TCP connection (port, firewall, gateway down)
# exit=28 -> timeout
# exit=97 -> proxy handshake error

Step 2: does the proxy accept your credentials

Do not confuse three answers here. 407 means the proxy rejected the credentials — there is a separate article on that code. 403 can come from the proxy or from the site, and the two are not always distinguishable. And exit code 97 says HTTP never happened at all: the proxy handshake failed.

And check with the same protocol and port you will actually use. HTTP and SOCKS5 listen on different ports, and a successful check on the HTTP port says nothing about the SOCKS port: the same credentials sent to the other protocol's port yield either an auth refusal or a drop with no clear message. If you will use both, check both.

Step 3: which address the site sees

The only check that answers “is the proxy working” on the merits: look at whose address the remote side sees. If it is yours, the proxy was not applied, whatever the settings say. Our “My IP” page shows what a site will see, plus the country and provider from the databases.

Step 4: does the geo match reality

A database country that differs from the expected one is usually not the seller's error. An address's geolocation reflects where the range is registered, not where the hardware sits, and the databases disagree with each other. Check it by comparison: see who the range is assigned to via WHOIS, and compare against latency. Five milliseconds to an address labelled Brazil means a stale database record, not a swapped country.

Step 5: where DNS queries go

This is where one letter in the scheme changes the outcome. socks5h:// means the proxy resolves names; socks5:// means your machine does. In the second case the target domain goes to your ISP even though all traffic travels through the proxy. That mechanism is exactly what a DNS leak test shows.

# The proxy resolves the name — no leak
curl -sS -x socks5h://GATEWAY:PORT https://example.com -o /dev/null -w '%{http_code}\n'

# Your machine resolves it — the domain is visible to your ISP
curl -sS -x socks5://GATEWAY:PORT  https://example.com -o /dev/null -w '%{http_code}\n'

Step 6: what the browser reveals besides the proxy

This is where results diverge most often: curl passes the check while the browser leaks the address. The reason is that WebRTC and system DNS are not HTTP and do not travel through an HTTP proxy at all. An anonymity check looks at precisely this: which address WebRTC reports, whether the time zone matches the exit country, what the headers show.

Step 7: speed, and where exactly it is lost

“Slow” is not a diagnosis either until you know which leg. curl can break the time down by stage, and that immediately shows whose leg it is: time to connect is the hop to the gateway, while the gap between the start of transfer and the end of the handshake belongs to the target site.

curl -sS -x http://GATEWAY:PORT https://example.com -o /dev/null \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n'

# large connect -> the problem is on the path to the gateway
# large first minus tls -> the target site is slow, not the proxy

What to check it with

Every step above can be done with one curl command, but we also host a page for each: exit address and provider, an anonymity check covering WebRTC and time zone, a DNS leak test, a throughput measurement, WHOIS for the range and a site availability check. They are free and need no sign-up — handy when you need to show a result to a client or attach it to a support ticket.

One last word on order: if step 1 failed, checking step 5 is pointless. Most of the time lost to proxies goes on checks made in the wrong sequence.