How to Test a Proxy, Check Proxy Health, and Compare Regions

Test one proxy before you run a batch

Start with a single endpoint and a destination you control or are explicitly allowed to query. Write down the four things that define it — protocol, host, port, and authentication method — because the most common cause of a mysterious failure is that one of those four is wrong rather than that the proxy is broken. An HTTP proxy and a SOCKS5 proxy on the same port behave completely differently, and a client configured for the wrong one usually reports a generic error.

A single working request establishes your baseline: it proves the protocol assumption is right, the credentials are accepted, and the destination is reachable through that path. Only then does a batch mean anything. Running a list of two hundred entries before you have one confirmed success produces two hundred identical errors and no information, which is a slow way to discover a typo in the port.

Measure the baseline as well as observing it. Record the time to connect, the time to first byte, and the status. Those three numbers give you something to compare the rest of the list against, and they let you tell a proxy that is down from a proxy that is merely saturated. A response in four seconds is a different operational problem from no response at all, and both will show up as "failed" under a short timeout.

# socks5h:// makes the PROXY resolve the hostname.
# socks5:// resolves locally and sends an address instead --
# that difference alone explains a lot of "works in curl, fails in the app".
$ curl -sS -o /dev/null \
    --proxy socks5h://198.51.100.20:1080 \
    -w 'connect %{time_connect}\nttfb    %{time_starttransfer}\nstatus  %{http_code}\n' \
    https://www.example.com/

connect 0.186
ttfb    0.944
status  200

# HTTP proxy with credentials -- keep them out of the command line
# and out of shell history:
$ curl -sS --proxy http://198.51.100.21:8080 \
    --proxy-user "$(cat ~/.config/proxy-user)" \
    -o /dev/null -w '%{http_code}\n' https://www.example.com/
200

Identify which stage failed

A proxy request has more stages than a direct one, and each stage fails with a recognisable signature. Getting the stage right is most of the diagnosis, because the stage tells you whether the problem is yours, the proxy's, or the destination's. A 407 is your credentials; a 502 from the proxy is the destination or the path beyond it; a connection refused is neither, it is the endpoint itself.

The distinction that catches people most often is between an error the proxy generated and an error it relayed. Both arrive as an HTTP response. The proxy's own errors normally come with the proxy's server header and no content from the destination, while a relayed error carries the destination's headers and body. If you are not sure which you are looking at, compare the response against what the same URL returns without a proxy.

Work down the table until the symptom matches. Everything above the matching row already succeeded.

Interpret proxy responses

Compare the HTTP status, the response time, the failure stage, and the observed exit address together rather than one at a time. A successful connection proves that this one request, at this one moment, completed through that path. It does not describe every network path the current browser or application uses, and it does not predict what the same proxy will do in an hour when the provider's pool has rotated.

Read the status against its origin. A 403 returned through a proxy is almost always the destination refusing the exit address, not the proxy refusing you — the same URL fetched directly will usually return 200, which is how you confirm it. A 429 through a proxy means the destination is rate-limiting the exit address, which is shared with everyone else using it. A 502 or 504 emitted by the proxy means the proxy could not complete the upstream request, and the timing tells you which: a fast 502 is a refusal, a slow 504 is a timeout.

Non-transparent proxies frequently add or rewrite headers. A Via header, an X-Forwarded-For chain, or a Forwarded header will be visible to the destination and can change how it treats the request. If you are testing whether a destination sees what you expect, fetch a header-echo endpoint you control and read exactly what arrived, rather than assuming the proxy is invisible.

State the limit plainly: a proxy check measures reachability, latency, and the exit address for one request. It is not an anonymity assessment and should not be read as one. Account sessions, cookies, TLS and browser fingerprints, application-layer identifiers, and traffic outside the tested client are all outside what any connectivity check can observe. For browser-level WebRTC, IPv4 and IPv6, and DNS resolver signals, run Browser Leak Check from the same device and network — keeping the two checks side by side is what lets you separate proxy availability from browser routing behaviour.

Compare regional exits

Regional exits are useful for a specific and legitimate job: confirming that a geographically routed system behaves correctly. Does the CDN serve the nearby edge? Does the regional deployment return the right currency, language, and legal notices? Does a latency-sensitive endpoint actually get served from the region you paid for? Those questions require making a request from somewhere else, and comparing results across exits is how you answer them.

When you compare, expect the advertised region and the observed region to disagree sometimes, and be careful about which one you treat as wrong. A provider labels an exit from its own inventory records; a geolocation database labels it from inference. Either can be stale. The signal worth acting on is a systematic disagreement across many exits from the same provider, or a mismatch that correlates with the thing you were actually testing — for example, a supposedly European exit that consistently receives content intended for another region.

Group results by exit region, then compare success rate, latency distribution, and error stage within each group. Grouping surfaces patterns a flat list hides: one region failing at the TLS stage while the others succeed points at something specific in that path, and a whole region with uniformly high latency usually means the traffic is being backhauled somewhere far away before it exits. Re-run unstable entries at a different time of day, because provider load and destination rate limits vary.

Handle credentials and authorisation properly

Proxy credentials are secrets and deserve the same handling as any other secret. Keep them out of command lines, where they land in shell history and in the process table visible to other users on the machine. Keep them out of tickets, screenshots, and chat. Store them in a file with restrictive permissions or in a secret manager, and rotate them when a test list has been shared around. If your provider supports authorising by source IP instead of a password, that is usually the safer option because there is no shared secret to leak.

Where testing is concerned, the rule is simple and worth stating explicitly: only test proxies you own or have been authorised to use, and only against destinations you own or are permitted to query. Running a connectivity test through someone else's infrastructure without permission is unauthorised use of their resources, and pointing a batch at a third-party destination generates load on a service that never agreed to it. Respect published rate limits and terms of service, and identify your own tooling honestly.

Proxy Check on this site allows 500 checks per visiting IP per UTC day. A single pass over a 500-entry list consumes the entire budget, so deduplicate the list, drop entries you already know are dead, and decide what you are measuring before you spend it. The counter keys on the visiting address reported in X-Forwarded-For, which means a shared office egress shares one budget across everyone behind it.

• Never paste production proxy credentials into any tool, including this one, without first confirming you are permitted to.
• Redact the userinfo portion of a proxy URL before sharing a result — user:pass@host is a password in a URL.
• Keep a dated record of which endpoints you tested and why; an undated list of proxy addresses is hard to justify later and easy to misuse.

Continue with related checks and tools