DNS Leak Test
Do your DNS queries actually go via the proxy or VPN, or do they escape to your ISP's resolvers? This test answers that. It fires DNS lookups from inside your browser, then asks you to compare whichever resolver answered them with the IP we record against your HTTP traffic.
Where to go from here
- In this same browser session, open dnsleaktest.com.
- Pick the "Extended test" option there, which names every single resolver that handled your queries.
- Set the resolver IPs and country side by side with 2600:1f28:365:80b0:be95:2351:59ad:3d05 shown above.
- If those resolvers sit somewhere other than your proxy's location, in your home country perhaps, or on your own ISP's network, then what you have is a DNS leak.
What is a DNS leak?
Type example.com into your browser and, before anything else, it puts a question to a DNS resolver: "what's the IP for example.com?" Only once that's answered does it open the real HTTP connection - normally through your proxy or VPN.
You have a leak when that first lookup goes off to your local ISP's resolver instead of the proxy's. Nothing about this is visible to the site you end up at. Your ISP, though, sees every domain you ask for, while your "traffic" carries on through the proxy quite happily. Resolvers also keep logs of what they were asked, and a log like that can be subpoenaed, sold on, or breached by someone else entirely.
Why proxies leak DNS so readily
Most HTTP and SOCKS5 proxies carry TCP/HTTP traffic and nothing besides. That means the DNS lookup for the destination domain happens before the proxy ever enters the picture - on your OS, via your local resolver. The proxy is then handed an already-resolved IP and simply forwards traffic to it. The upshot: the traffic goes through the proxy while the DNS doesn't.
Situations where this crops up:
- HTTP proxies using system-level DNS - the OS resolves the domain and the proxy only ever sees the IP, so the lookup leaks.
- SOCKS4 versus SOCKS5 - SOCKS4 can't carry DNS lookups at all; SOCKS5 can, but only once the client opts in (hunt for a "remote DNS" or "proxy DNS" setting).
- A VPN in split-tunnel mode with poor DNS config - part of the traffic travels via the VPN while the DNS slips past it.
- Browsers with built-in DoH - Firefox and Chrome may route DNS to Cloudflare or Google, skipping the proxy entirely.
How to fix DNS leaks
Browser-level fix
- Firefox: Settings → Network Settings → check "Proxy DNS when using SOCKS v5".
- Chrome: launch with
--proxy-server="socks5://host:port" --host-resolver-rules="MAP * ~NOTFOUND, EXCLUDE proxy"or use an extension that forces DNS-over-proxy. - Antidetect browsers (Multilogin, Dolphin Anty, GoLogin) - all of them route DNS through the proxy by default. This is one of the main reasons to use them for account management.
Scraper / automation fix
# Python requests + SOCKS5 with DNS-over-proxy
import requests
proxies = {
'http': 'socks5h://user:pass@host:port', # 'socks5h' = resolve via proxy
'https': 'socks5h://user:pass@host:port',
}
requests.get('https://example.com', proxies=proxies)
Mind the socks5h:// scheme (rather than socks5://) - that h stands for "resolve hostnames via the proxy". Leave it off and Python resolves DNS locally, which is exactly your leak.
Use HTTPS-over-proxy, or else a resolver you trust
Where a non-browser tool refuses to push its DNS through the proxy, point the operating system at a reputable public resolver instead: 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9) or 8.8.8.8 (Google). Better still over DNS-over-HTTPS, so the lookup itself stays out of your ISP's view.
How a DNS leak gives you away
Say you scrape a site through a proxy in Germany, but the DNS lookup for that site escapes via Comcast in Florida. Anti-fraud at the far end now has two arrivals to work with: one from Comcast asking "where is X?", the other from a German proxy saying "give me X". Put those side by side and the proxy's cover has gone. Test the once, fix it the once, then check again after each browser or OS update.
