Testing a proxy means confirming that it does what you bought it for — presents the right IP, from the right place, without revealing yours — and measuring how fast it does it. The check takes five minutes and prevents the two most expensive proxy failures: bans caused by an IP that was already burned, and identity leaks caused by traffic that never went through the proxy at all. This is the checklist we use.
1. Does the IP actually change?
The first test is the obvious one, and it catches misconfiguration more often than you would expect. With the proxy configured, request a page that echoes your IP:
curl -x http://user:pass@proxy.example.com:8080 https://api.ipify.org
curl -x socks5h://user:pass@proxy.example.com:1080 https://api.ipify.orgCompare with the same request without -x. If the two IPs match, the proxy is not being used: wrong port, wrong protocol scheme, or an application that ignores system proxy settings. Note the scheme socks5h (with the h) — it tells curl to resolve hostnames through the proxy, which matters for the DNS test below.
In a browser, use any “what is my IP” page — but do it in a fresh profile or private window, because a page cached from before you enabled the proxy will lie to you.
2. Is the IP flagged?
An IP that changes but is already on blocklists is worse than useless: it makes you look like exactly what you are trying not to look like. Check three things.
Registration type
Look the IP up in a WHOIS or IP-intelligence service. You want to see the type the provider promised: an ISP name for residential, a mobile carrier for mobile, and — if you bought datacenter — at least a hosting company that is not on every list. If you paid residential prices and WHOIS says DigitalOcean, you have been sold datacenter IPs.
Proxy / VPN detection
Several public services score an IP for “proxy likelihood” using the same signals commercial anti-fraud vendors buy: known VPN ranges, hosting ASNs, prior abuse reports, port scans showing open proxy ports. A residential IP should score low; a datacenter IP will usually score as “hosting” and there is nothing to be done about that — it is a property of the type, not a defect of the provider.
Blocklists
Check the IP against major DNS blocklists (Spamhaus, SORBS and similar). A listing means past abuse from that address; for anything involving email, forms or account creation it is disqualifying. Rotating providers should never hand you a listed IP; if they do repeatedly, that is a pool-quality problem worth raising with support.
3. Anonymity level: what headers give away
HTTP proxies are classified by what they tell the destination about the client:
| Level | Headers sent to the site | What the site learns |
|---|---|---|
| Transparent | Via, X-Forwarded-For: <your real IP> | That you use a proxy and your real IP. Useless for privacy. |
| Anonymous | Via or X-Proxy-ID, but no real IP | That you use a proxy, but not who you are. |
| Elite (high-anonymity) | None of the above | Nothing — the request looks like it came from the proxy itself. |
Verify by requesting a page that echoes request headers:
curl -x http://user:pass@proxy.example.com:8080 https://httpbin.org/headersYou want to see no Via, X-Forwarded-For, Forwarded, or X-Real-IP. Any commercial proxy sold for privacy or automation should be elite; if you find your real IP in a header, stop using it immediately. SOCKS5 proxies do not add HTTP headers at all, so this test applies to HTTP(S) proxies specifically. For the ranking angle, see our elite proxy comparison.
4. DNS leak
This is the leak most people never test. When your application resolves example.com to an IP before handing the request to the proxy, the DNS query goes to your normal resolver — typically your ISP's. The website sees the proxy; your ISP (and anyone with access to those logs) sees every domain you visit.
How to test: use a DNS-leak test page while proxied. It will list the resolvers that answered its unique probe hostnames. If any of them belong to your ISP or sit in your real country, you are leaking.
How to fix:
- SOCKS5: enable remote DNS resolution. In curl that is
socks5h://; in Firefox it is Proxy DNS when using SOCKS v5; most SOCKS5-aware libraries have an equivalent flag. Plainsocks5://resolves locally. - HTTP(S) proxy: for HTTPS destinations the browser sends the hostname to the proxy inside
CONNECT, so the proxy resolves it — no leak. For plain HTTP the full URL is sent to the proxy, which also resolves it. Leaks here usually come from other applications on the machine that are not proxied at all.
5. WebRTC leak (browsers only)
WebRTC lets browsers establish peer-to-peer connections, and to do so it enumerates your network interfaces and can send your local and public IP to a page's JavaScript — bypassing the proxy entirely. This is the classic way a “perfectly configured” browser proxy still gives away the real address.
How to test: open a WebRTC-leak test page. If it shows any IP other than the proxy's — especially a 192.168.x.x local address or your real public IP — WebRTC is leaking.
How to fix: disable WebRTC or restrict it to proxied routes. In Firefox set media.peerconnection.enabled to false. In Chrome use a policy or an extension that limits WebRTC IP handling. Antidetect browsers do this by default and can spoof the WebRTC-visible IP to match the proxy; that is one of the reasons multi-account work uses them — see what an antidetect browser is.
6. Speed: latency and throughput
Two numbers matter, and they answer different questions.
- Latency (round-trip time) governs how snappy interactive use feels and how many sequential requests per second one connection can make. Measure it with a small request:
Compare against the same command without the proxy. Datacenter proxies add tens of milliseconds; residential and mobile add 50–300 ms. Consistently high or wildly variable numbers on datacenter IPs indicate an overloaded provider.curl -x http://user:pass@proxy:8080 -o /dev/null -s -w "connect %{time_connect}s ttfb %{time_starttransfer}s total %{time_total}s\n" https://example.com/ - Throughput governs bulk transfer — downloading pages with images, or many parallel requests. Fetch a known-size file (a few MB) and time it. On per-GB residential plans this also tells you how quickly you will burn your allowance.
Run each test several times at different hours; proxy performance varies with load. A single fast result at 3 a.m. proves nothing about business hours. Our speed-focused ranking describes the methodology we use for repeated measurement.
7. Geolocation and consistency
If you bought a proxy in a specific country or city, check that geolocation databases agree. Databases disagree with each other and with reality, particularly for mobile IPs, which are often located at the carrier's head office rather than the phone's position. What matters is what the target site's database says, and you cannot know that — but if two or three public GeoIP services all put your “Berlin” proxy in Frankfurt, expect sites to think so too.
Consistency checks worth doing once per setup:
- Does the browser's time zone match the proxy's location? A Tokyo IP with a Europe/Berlin clock is a classic tell.
- Does the Accept-Language header make sense for that country?
- For mobile proxies: does your User-Agent claim a mobile device? A carrier IP with a desktop UA is an anomaly some anti-fraud systems weight.
The five-minute checklist
- IP changes when proxied — and matches the provider's promised type in WHOIS.
- Not on major blocklists; proxy-detection score plausible for the type.
- No
Via/X-Forwarded-For/Forwardedheaders reach the destination (HTTP proxies). - DNS-leak test shows only resolvers that are not yours; SOCKS5 uses remote resolution.
- WebRTC test shows only the proxy IP (browsers).
- Latency and throughput acceptable across several runs at different times.
- GeoIP location, time zone and language are mutually consistent.
Anything failing 1, 3, 4 or 5 is a stop-and-fix. Failures on 2, 6 or 7 are quality signals to raise with the provider or to weigh when choosing one — our reliability ranking is based on repeating exactly these checks over time.
Frequently asked questions
What is the quickest way to check if a proxy is working?
Request an IP-echo service with and without the proxy and compare. If the IP differs and matches the provider's expected range, the proxy is working. Everything else on this list is about whether it is working well.
What is a DNS leak and why does it matter with a proxy?
A DNS leak is when the domain-name lookup for a site goes to your regular resolver instead of through the proxy. The site sees the proxy's IP, but your ISP or network still learns which domains you visit. Fix it by resolving names through the proxy (SOCKS5 remote DNS) or by using an HTTPS proxy, where the proxy resolves the name.
What is a WebRTC leak?
Browsers can reveal your real local and public IP addresses to web pages through WebRTC, even when a proxy is configured, because WebRTC negotiates connections outside the proxy path. Disable WebRTC or use a browser that routes or spoofs it.
What is the difference between anonymous and elite proxies?
An anonymous proxy hides your IP but adds headers revealing that a proxy is in use; an elite proxy adds nothing, so the request looks like it originated at the proxy. For any privacy or automation purpose you want elite.
How do I know if a proxy IP is blacklisted?
Query it against DNS blocklists such as Spamhaus, and against an IP-reputation service. A listing means prior abuse; avoid the IP for email, forms and account creation.
How often should I re-test?
Whenever you change provider, plan or configuration, and periodically thereafter — IPs are re-assigned, blocklists update, and providers' pools change quality. For long-running automation, build the IP-change and header checks into your startup routine.