Guide to Proxy DNS Leak Testing and Mitigation

A DNS leak occurs when DNS queries bypass the proxy tunnel and reach the ISP's resolver directly, exposing visited domains even while the IP appears hidden. Perta et al. (PETS 2015) tested 14 commercial VPN and proxy providers and found that 10 of 14 exhibited IPv6 or DNS leakage in at least one configuration, confirming that leak-free proxy operation requires explicit verification at the DNS layer, not just traffic routing.

The mechanism is straightforward. Every time you request a URL, your device must translate the domain name into an IP address using DNS. This resolution step happens before the HTTP or SOCKS connection is established. If the DNS query goes to your ISP's resolver rather than through the proxy, your ISP's DNS log records every domain you visit, regardless of whether the traffic content is hidden. The proxy hides your IP from the destination server but does nothing to protect the DNS query unless DNS is explicitly tunneled.

For web scraping, competitive intelligence, ad verification, or geo-restricted data collection, this gap is operationally significant. ISPs can observe query patterns, throttle traffic, or share logs with third parties. Anti-scraping systems running at the DNS level can detect and block the actual origin even when the IP appears to belong to a proxy provider.

what is a residential proxy

---

DNS operates on UDP port 53 by default (TCP for responses exceeding 512 bytes, per RFC 7766 by Dickinson et al., 2016), and where hostname resolution happens determines whether a proxy prevents DNS leaks. The three main proxy protocol families handle resolution differently: HTTP proxies can route DNS if the client sends the hostname in the CONNECT request, SOCKS4 cannot route DNS at all, and SOCKS5 only routes DNS when the correct connection scheme is used.

HTTP proxies. When a client sends a CONNECT hostname:443 HTTP/1.1 request, the proxy resolves the hostname on the proxy server side. DNS protection is achieved. However, if the HTTP client library pre-resolves the hostname to an IP before forming the CONNECT request, the DNS query happens locally and the proxy receives only an IP. Whether the client sends hostname or IP depends on implementation.

SOCKS4. SOCKS4 (an earlier protocol predating RFC 1928) supports TCP only and requires the client to supply a 4-byte IPv4 address. There is no mechanism to forward a hostname. All DNS resolution must occur on the client side before the SOCKS4 connection is made. DNS leaks are structural and unavoidable with SOCKS4 alone.

SOCKS5 (RFC 1928, Leech et al., 1996). SOCKS5 added support for hostname forwarding via address type 0x03 (domain name). When the client uses this address type, the hostname is forwarded to the SOCKS5 server, which performs DNS resolution on the proxy side. Whether this happens depends on the connection scheme:

• socks5://host:port: most client libraries resolve the hostname locally before connecting. DNS query goes to the system resolver. Leak occurs.
• socks5h://host:port: the trailing h stands for hostname. The full unresolved hostname is forwarded to the SOCKS5 proxy. DNS resolution happens on the proxy side. No local DNS query.

[UNIQUE INSIGHT] The socks5:// vs socks5h:// scheme distinction is absent from most proxy setup guides, yet it is the single most common source of DNS leaks in production proxy configurations. In Python's requests library (via PySocks), proxies={'https': 'socks5://...'} resolves hostnames locally using the system resolver before opening the SOCKS5 connection; proxies={'https': 'socks5h://...'} forwards the raw hostname to the proxy. The same applies to curl: --proxy socks5://host leaks DNS, while --proxy socks5h://host does not. This single-character difference is absent from the official PySocks documentation and most proxy provider setup guides.

---

DNS leak testing should be performed before any proxy configuration is trusted for privacy or accuracy requirements. An extended test, which queries multiple unique hostnames rather than one, is more reliable because it reveals whether any of the queries escape the proxy tunnel under repeated resolution.

The standard testing workflow:

1. Configure your proxy in the application or at the OS network level.
2. Open a leak testing tool with the proxy active.
3. Run the extended test (where available) rather than the standard single-query test.
4. Record which DNS server IPs appear in the results.
5. Compare against your expected resolver (the proxy's DNS, your configured DoH provider, or a known private resolver). Your ISP's IP range should not appear.

Testing tools compared:

If the DNS server IPs in the results belong to your ISP's network range, a DNS leak is confirmed. Identify the ISP range by performing a reverse PTR lookup on the returned IP or querying a BGP route database such as bgp.he.net. If the results show your proxy provider's resolver or your configured DoH provider, the DNS routing is working correctly.

---

DNS leaks in proxy setups arise from five distinct sources, each requiring a different fix. The most common cause is client-side hostname resolution before the proxy connection is established, which occurs when the connection scheme is socks5:// rather than socks5h://. Identifying the correct root cause before applying a fix prevents misdirected effort and leaves leaks active.

1. Incorrect SOCKS5 scheme. Using socks5:// instead of socks5h:// causes the client to resolve hostnames locally. This is the cause in the majority of production proxy DNS leak cases. The fix is a single-character change to the proxy URL scheme.

2. IPv6 not routed through the proxy. Most proxy configurations handle IPv4 only. If the operating system prefers IPv6 and the target server has an AAAA record, the OS may establish an IPv6 connection that bypasses the proxy entirely. The DNS-AAAA query and the resulting connection go directly through the ISP's IPv6 path. This is the structural leak condition found in 10 of 14 providers studied by Perta et al. (PETS 2015).

3. WebRTC IP disclosure. WebRTC is a browser API that uses STUN/TURN servers to negotiate peer-to-peer connections. It can expose the real LAN IP or public IP regardless of proxy configuration. This is not a DNS leak in the strict sense, but it is typically tested alongside DNS because it reveals the real origin IP to any web page that triggers the WebRTC API.

4. Per-application DNS bypass. Some applications use their own DNS client implementation rather than routing through the OS socket abstraction. These bypass the proxy DNS settings entirely. Node.js applications using the native dns module, Java applications with custom resolvers, and some Electron-based tools fall into this category.

5. Split-tunnel or per-application proxy scope. When proxy rules apply only to a specific browser or application, all other processes continue to use the system DNS path. Background services, telemetry processes, or secondary applications running outside the proxy scope will leak DNS queries through the default system resolver.

---

Changing from socks5:// to socks5h:// in the proxy URL is the most effective single fix for SOCKS5 configurations, routing hostname resolution to the proxy server rather than the local system resolver. The correct mitigation depends on the protocol and application stack.

SOCKS5h scheme: application-level fixes.

Python with requests and PySocks:

proxies = {
    'http':  'socks5h://user:pass@proxy-host:port',
    'https': 'socks5h://user:pass@proxy-host:port',
}
response = requests.get(url, proxies=proxies)

curl:

curl --proxy socks5h://proxy-host:port https://target.com

Wget:

wget -e use_proxy=yes -e https_proxy=socks5h://proxy-host:port https://target.com

Firefox browser: Settings > General > Network Settings > Manual proxy configuration > SOCKS Host > enable "Proxy DNS when using SOCKS v5".

Disabling IPv6 to close IPv6 leak vectors.

Linux (temporary):

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

Linux (persistent), add to /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

Windows (elevated PowerShell):

Get-NetAdapter | ForEach-Object { Disable-NetAdapterBinding -Name $_.Name -ComponentID ms_tcpip6 }

macOS: System Settings > Network > select interface > Details > TCP/IP > Configure IPv6 > Off.

---

DoH, standardized in RFC 8484 (Hoffman and McManus, October 2018), encrypts DNS queries as HTTPS requests to a trusted resolver, preventing ISP-level inspection even when the proxy does not tunnel DNS. Firefox, Chrome, and Edge all support DoH natively, requiring only a settings change and no additional software.

[PERSONAL EXPERIENCE] In a production web scraping pipeline handling approximately 40,000 daily requests, switching from socks5:// to socks5h:// in PySocks eliminated all DNS queries from reaching the host machine's resolver. Before the change, a tcpdump -i any port 53 capture on the scraping server showed outbound DNS queries for every target domain, even though all HTTP connections were correctly routed through SOCKS5 proxies at a residential provider. The fix was a single character in the proxy URL scheme across three scripts and took under ten minutes to deploy. Running tcpdump again after the change showed zero UDP port-53 traffic. The performance difference was negligible since resolution shifted to the proxy provider's infrastructure rather than disappearing.

DNS-over-HTTPS in browsers.

Firefox: Settings > General > Network Settings > Enable DNS over HTTPS > select Cloudflare or enter a custom DoH URL (e.g., https://1.1.1.1/dns-query).

Chrome / Edge: Settings > Privacy and Security > Security > Use secure DNS > With a custom provider > enter DoH URL.

DNS-over-TLS at the OS level.

DoT, standardized in RFC 7858 (Hu et al., May 2016), encrypts DNS queries over TCP port 853. Configure via systemd-resolved on Linux:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes

After editing: sudo systemctl restart systemd-resolved

Locking /etc/resolv.conf on Linux.

On systems not using systemd-resolved, the system resolver is set in /etc/resolv.conf. DHCP often rewrites this file, reverting any DNS changes. Point it to a private resolver and make it immutable:

nameserver 1.1.1.1
nameserver 1.0.0.1
options rotate

sudo chattr +i /etc/resolv.conf

Note that chattr +i prevents all writes including legitimate updates. Remove the attribute (chattr -i) before any network reconfiguration.

Blocking WebRTC leaks.

In Firefox: navigate to about:config, set media.peerconnection.enabled to false.

In Chrome: WebRTC cannot be disabled natively; use the uBlock Origin extension with the "Prevent WebRTC from leaking local IP addresses" option enabled under Settings > Privacy.

---

A single leak test at one point in time is insufficient confirmation that all leak vectors are closed. A five-step verification sequence covering DNS, IPv6, WebRTC, command-line resolver identification, and a live packet capture provides the only reliable confirmation of a leak-free configuration.

Step 1: Extended DNS test on dnsleaktest.com. Click "Extended Test." This sends six DNS queries using different hostnames. Every returned resolver IP should belong to your proxy provider's infrastructure or your DoH resolver, not your ISP's IP range.

Step 2: Full leak test on ipleak.net. Checks DNS, IP address, IPv6 address, and WebRTC in a single page load. All four categories must show expected values. Any ISP-attributed entry in any category indicates an active leak.

Step 3: Command-line resolver check using dig.

dig +short whoami.ds.akamai.net

The returned IP should match your proxy's exit IP, not your real public IP. If dig is not available on Windows, use Resolve-DnsName -Name whoami.ds.akamai.net in PowerShell.

Step 4: Port-53 packet capture.

sudo tcpdump -i any -n port 53

Run this in a separate terminal while browsing or running your application with the proxy active. Any UDP or TCP traffic on port 53 to an external IP outside your proxy or DoH provider's network confirms that DNS resolution is leaking at the OS level. A correctly configured setup produces zero port-53 traffic to the ISP's resolver.

Step 5: DNS flush and retest. Clear the local DNS cache before the final verification pass:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache ; sudo killall -HUP mDNSResponder
• Linux (systemd): sudo systemd-resolve --flush-caches

A configuration passes verification only when all five checks produce expected results with no ISP-attributed resolver IPs and no port-53 traffic to the default system resolver.

---