DNS Leaks and Proxies

What is a DNS leak?

Before connecting to a website, your device looks up the site's IP address using DNS. A DNS leak happens when those lookups go through your normal network and DNS resolver instead of through the proxy. The website you visit may not see it, but your ISP (or network operator) can see every domain you look up, and some detection systems can notice that your DNS resolver is in a different country from your proxy IP.

Do proxies leak DNS?

It depends on the proxy type and the client.

HTTP(S) proxies

When a client uses an HTTP proxy correctly, it sends the hostname to the proxy (in the absolute URL for HTTP, or in the CONNECT request for HTTPS). The proxy resolves the name. So browsers and well-behaved HTTP clients usually don't leak DNS through HTTP proxies for proxied requests.

SOCKS proxies

SOCKS5 supports sending hostnames, but some clients resolve locally first and send the IP. That's a leak.

• In curl and Python: socks5:// resolves locally; socks5h:// sends the hostname to the proxy.
• In Firefox: tick Proxy DNS when using SOCKS v5.
• Chrome resolves through the SOCKS proxy by default.

See SOCKS5 proxies.

System-wide and partial setups

If only some apps use the proxy, other apps' DNS lookups (and traffic) go out directly. Also, some browsers prefetch DNS for links on a page, and some operating system features perform lookups independently.

Why DNS leaks matter

• Privacy: your ISP can log the domains you visit.
• Geo-consistency: a DNS resolver in Germany with a proxy IP in the US can look inconsistent to some detection systems.
• Geo-routing: some sites use DNS-based geo-routing (returning different server IPs for different resolver locations), so local DNS can route you to the wrong regional server.

How to test

Use a DNS leak test website in the configured browser. It shows which DNS resolvers made the lookups. If they belong to your ISP rather than the proxy's network, you're leaking.

For command-line clients, test with verbose output and check where resolution happens.

How to prevent leaks

• Use socks5h:// (not socks5://) in curl, Python requests and similar tools.
• In Firefox, enable remote DNS for SOCKS.
• Prefer HTTP(S) proxies for browsers, which resolve on the proxy for proxied requests.
• Configure all relevant apps to use the proxy, or use a system-wide solution.
• In Chromium automation, consider --host-resolver-rules to block local resolution. See Puppeteer SOCKS5 proxy.
• Disable DNS prefetching in privacy-sensitive browser setups.

DNS behaviour by client

DNS and geo-consistency in practice

Some sites use DNS-based routing (GeoDNS) to direct users to regional servers. If your DNS resolves locally in Germany but your proxy exits in the US:

• You may connect to a European server via a US exit.
• Content, speed or even blocks may differ from what a real US user experiences.

Resolving through the proxy keeps the whole path consistent with the exit's location.

Encrypted DNS (DoH/DoT)

Browsers can use DNS over HTTPS. With a proxy, DoH requests themselves go through the proxy if configured, which hides them from your local network. But a DoH resolver in a different country from your proxy exit can still affect GeoDNS results. Consider choosing a resolver near your proxy, or letting the proxy resolve.

Quick fixes summary

• Use socks5h in code.
• Enable remote DNS for SOCKS in Firefox.
• Prefer HTTP proxies for browsers.
• Route all relevant apps through the proxy.
• Test after every configuration change.

See how to check if a proxy works.

Catching DNS leaks in scripts and pipelines

Browser leak-test sites don't help with scripts, containers or CI jobs. For those, watch the DNS traffic leaving the machine while the job runs:

sudo tcpdump -n -i any port 53

Start it in one terminal, run your job in another, and look for queries naming your target domains. If they appear, something is resolving targets locally instead of through the proxy. Common culprits:

• socks5:// instead of socks5h:// in curl, Python or other clients, which resolves locally.
• Other tools in the pipeline, such as health checks, package managers or git, that don't use the proxy at all.
• Containers that don't receive the proxy environment variables, and so resolve and connect directly.
• Pre-flight lookups in your own code, for example resolving a hostname to log its IP before making the request.

Two caveats. Encrypted DNS (DoH) runs over port 443 and won't show up in this capture, so check whether any tool uses it. And lookups for the proxy's own hostname are expected; only target domains matter.

HTTP proxies resolve target hostnames on the proxy side when the client sends the hostname, so a correctly configured HTTP client shouldn't leak. For the SOCKS details, see SOCKS5 proxies; for how DNS affects which server answers, see geo-targeted proxies.

Key takeaways

• A DNS leak occurs when lookups bypass the proxy and go through your local resolver.
• HTTP proxies normally resolve hostnames on the proxy side for proxied requests.
• With SOCKS, use socks5h in code and enable remote DNS in Firefox.
• DNS leaks expose browsing to your ISP and can cause geo-inconsistency with GeoDNS.
• Test with a DNS leak page after any configuration change. See webrtc leaks and proxies.

FAQ

Does a DNS leak reveal my IP to websites?

Not directly. It reveals the domains you visit to your DNS provider and can reveal your resolver's location.

Do VPNs prevent DNS leaks?

Good VPNs route DNS through the tunnel; misconfigured ones can leak too. See proxy vs VPN.