A proxy checker answers three questions about a proxy: does it work, how fast does it respond, and what does it give away about whoever is using it? Any team that relies on proxies will sooner or later meet an endpoint that times out, exposes the real IP or behaves unexpectedly. A checker replaces those unknowns with facts, so problems get fixed rather than guessed at. Treat it like an acceptance test: run it when an order arrives, before a large job, and whenever results look odd.
What the report covers
| Field | What it tells you | What to look for |
|---|---|---|
| Reachability | Whether the proxy lets you connect and accepts your login | Connected, login accepted |
| Exit IP | The IP that websites record for your requests | An address that is not yours |
| Latency | Round-trip time in milliseconds | Low and steady; spikes suggest a busy or distant node |
| Protocol support | Whether HTTP, HTTPS and sometimes SOCKS work | The protocol your tools use |
| Anonymity level | Whether headers reveal the proxy or your origin IP | No revealing headers |
| Geolocation | Roughly where the exit IP is located | The country and city you ordered |
It works the same way for every order, whatever the type: datacenter, residential, mobile or premium residential.
Three anonymity grades, from transparent to elite
- Transparent: your real IP is passed on in headers such as
X-Forwarded-For; the site learns about the proxy and about you. Rarely what a team wants. - Anonymous: keeps your IP out of the headers, though the site may still be told it is talking to a proxy.
- Elite (high-anonymity): no sign of your IP and no sign of a proxy. Aim for this level in most work.
Seeing your own IP anywhere in the results means the configuration is wrong. Fix it before the proxy goes near sensitive work.
The browser check
Start in the browser. Enter the proxy into our proxy checker as host:port, with its username and password, and run the test; a few seconds later the results show the exit IP, how long the response took, and whether the connection succeeded. Then open our my IP tool without the proxy. If both show the same address, traffic is not going through the proxy.
Testing endpoints from a Python script
Checking a list of endpoints by hand gets slow. This script times one request and prints the exit IP:
import requests
import time
proxy = "http://USER:PASS@HOST:PORT"
proxies = {"http": proxy, "https": proxy}
try:
start = time.time()
r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)
elapsed = round((time.time() - start) * 1000)
print(f"OK exit IP: {r.json()['origin']} latency: {elapsed} ms")
except requests.exceptions.RequestException as e:
print(f"FAILED: {e}")
The second snippet asks the echo service to list the headers it received. Scan them for your own address: if it turns up in X-Forwarded-For or a header like it, you are on a transparent proxy.
r = requests.get("https://httpbin.org/headers", proxies=proxies, timeout=15)
print(r.json()["headers"]) # scan for any header containing your real IP
Checking a whole pool
Pools need a loop. This version checks every endpoint in parallel threads and marks each one alive or dead:
from concurrent.futures import ThreadPoolExecutor
import requests
proxy_list = [
"http://USER:PASS@HOST1:PORT",
"http://USER:PASS@HOST2:PORT",
]
def check(proxy):
try:
r = requests.get("https://httpbin.org/ip",
proxies={"http": proxy, "https": proxy},
timeout=10)
return proxy, "alive", r.json()["origin"]
except Exception:
return proxy, "dead", None
with ThreadPoolExecutor(max_workers=20) as pool:
for proxy, status, ip in pool.map(check, proxy_list):
print(status, ip or "-", proxy.split("@")[-1])
Splitting each entry on @ keeps credentials out of the printed output, which matters when logs are shared.
Reading the results
Green is only the start. Before signing off an order, answer four questions:
- Is the exit IP different from the office's? The my IP tool tells you.
- Will the latency suit the job? A few hundred milliseconds is fine for data collection; real-time work needs less.
- Is the location the one on the order? A different country from the one you bought is a matter for support.
- Any revealing headers? An elite proxy shows none.
Add our DNS leak test whenever privacy matters. Traffic can travel through the proxy perfectly while name lookups still go to your internet provider, and that undoes much of the point.
Failure messages and their usual causes
- 407 Proxy Authentication Required: recheck the username and password, and the format they are sent in.
- Connection timeout: check the port first, then any firewall on the outbound path; an exhausted endpoint can also be the cause.
- Works, but the IP keeps changing: on rotating residential and mobile endpoints that is expected behaviour, not a fault.
- Your own IP shows up: the proxy is transparent, so move to an elite (high-anonymity) one.
Making checks part of the routine
Build three checkpoints into the team's routine: when credentials arrive, before any large job, and the moment something behaves oddly mid-task. A thirty-second check often saves hours of debugging a script whose only problem was a dead proxy. It also helps before you commit: test new proxies as soon as they are provisioned, after comparing options on the proxies page and pricing.
Run the checker early, read every field instead of the pass mark alone, and problems that were never in the code stop eating the team's time.