DNS Leaks With Proxies: Causes, Tests, Fixes

Every request to a hostname like example.com needs a DNS lookup to turn that name into an IP address before a TCP connection can open. The question is who performs that lookup. If your client resolves the name itself, the query goes to whatever resolver your operating system is configured to use - typically your ISP or a public resolver on your real network. That happens before the proxied connection is established, so the lookup never touches the proxy.

The result is a split identity. Your HTTP(S) traffic exits the proxy IP, but the DNS query traveled a different road. As BrowserLeaks puts it, incorrect network configuration or faulty VPN/proxy software can send DNS requests directly to your ISP's server, exposing your browsing activity. In practical terms, the destination's DNS infrastructure and the resolver logs see a lookup that originates from your real network, not the proxy exit.

SOCKS5 supports two ways of handling the hostname, and the client picks which one by the scheme it uses. The curl project documents four SOCKS schemes, split by where the name is resolved:

The h stands for hostname. With socks5h, the client sends the raw hostname to the proxy and the proxy performs the lookup; with plain socks5, the client resolves the name first and only sends an IP. Same protocol, two behaviors - and the wrong one leaks silently, because the connection still works. HTTP proxies do not have this fork: for an HTTP proxy the client hands over the hostname (a full URL, or a CONNECT host:port for HTTPS), so the proxy resolves it by design.

The fix in code is almost always a one character change: add the h. Below is the same idea across three common clients.

curl

# Local DNS: curl resolves the hostname, then connects via the proxy (can leak)
curl --proxy socks5://user:pass@proxy:1080 https://example.com

# Remote DNS: the proxy resolves the hostname (the "h" is for hostname)
curl --proxy socks5h://user:pass@proxy:1080 https://example.com

# Equivalent explicit flag
curl --socks5-hostname user:pass@proxy:1080 https://example.com

Python (requests + PySocks)

The requests[socks] extra installs PySocks, whose rdns flag controls remote resolution. The urllib3 SOCKS docs recommend the socks5h:// (or socks4a://) scheme so DNS is done on the server side.

# pip install "requests[socks]"   (pulls in PySocks)
import requests

proxies = {
    "http":  "socks5h://user:pass@proxy:1080",
    "https": "socks5h://user:pass@proxy:1080",
}
requests.get("https://example.com", proxies=proxies)

# socks5h -> PySocks resolves DNS at the proxy (rdns=True)
# socks5  -> DNS resolved locally on your machine (rdns=False)

For a fuller walkthrough with auth, sessions, and rotation, see our Python requests SOCKS5 example.

Node.js (socks-proxy-agent)

The socks-proxy-agent package accepts the scheme in the proxy URL and supports socks5h, resolving DNS at the proxy rather than locally.

// npm i socks-proxy-agent
import { SocksProxyAgent } from "socks-proxy-agent"

// socks5h:// -> DNS resolved at the proxy; socks5:// -> resolved locally
const agent = new SocksProxyAgent("socks5h://user:pass@proxy:1080")

await fetch("https://example.com", { agent })

If you are working from the command line first, our mobile proxy with curl guide shows the full request setup end to end.

Testing is the only way to know for sure, because a leaking configuration still loads pages normally. Two long standing, real tools do the job:

• •browserleaks.com/dns - reports which DNS servers your browser used to resolve names, and flags when queries are going to your ISP instead of through your VPN or proxy.
• •dnsleaktest.com - forces lookups of a batch of unique, randomly generated hostnames and lists every resolver that answered, so you can see exactly which networks handled your DNS.

Reading the result: run the test while routed through the proxy. Compare the resolver location the tool reports against your proxy exit region. If the resolvers sit in the same country and network neighborhood as your exit IP, DNS is going through the proxy. If they show your home ISP or your real city, the lookup leaked - go back and switch the scheme to socks5h or enable remote DNS in your client.

Browsers are trickier than command line tools because they have their own DNS behavior layered on top of the proxy. Two settings matter.

For antidetect browsers, rely on the app's own proxy field rather than a system proxy, and confirm the profile is set to resolve DNS through the assigned proxy. Then verify the same way you would anywhere else: open a leak test inside that exact profile and check that the resolver region matches the proxy exit. The principle is identical to matching a fingerprint to its IP - every signal, including DNS, should agree.

Sources

• • everything curl - SOCKS proxy schemes (socks5 vs socks5h)
• • urllib3 documentation - SOCKS proxies and remote DNS
• • PySocks (PyPI) - the SOCKS library behind requests[socks]
• • socks-proxy-agent (npm) - supported SOCKS schemes for Node
• • BrowserLeaks - DNS Leak Test
• • dnsleaktest.com - DNS leak test
• • Mozilla Support - Configure DNS over HTTPS in Firefox