DNS Leak Test: What It Is, Why It Happens, and How to Fix It in 2026

You've configured a proxy or VPN, your HTTP traffic routes through the right exit IP, and from the outside everything looks clean. But your DNS queries — the requests your device makes every time it resolves a domain name — might be going somewhere else entirely. That's a DNS leak, and it's one of the most common privacy and operational failures in proxy-based workflows.
This guide covers what DNS leaks are, the root causes, how to test for them, what the results mean, and how to fix them across different environments. There's a checklist at the end you can use as a pre-flight step before any proxy session.
What DNS Actually Does and Why It Leaks
DNS (Domain Name System) is the layer that translates human-readable domain names into IP addresses. When you navigate to any site, your device first asks a DNS resolver: "What's the IP address for this domain?" The resolver returns the answer, your browser connects to that IP, and the page loads.
By default, your device uses the DNS resolver assigned by your ISP or your router's DHCP configuration. That resolver is almost certainly operated by your ISP — which means your ISP gets a log of every domain your device queries, regardless of what proxy or VPN you're using for the actual traffic.
A proxy routes your HTTP/HTTPS requests through a different IP. It does not automatically reroute your DNS queries. Unless the proxy explicitly handles DNS resolution (which requires remote DNS mode — more on this below), your device continues sending DNS queries to your ISP's resolver using your real network connection, bypassing the proxy entirely.
This is a DNS leak: your traffic exits through a proxy IP in another country, but your DNS queries are still being served by your home ISP's resolver. Any site or platform that monitors both signals — which sophisticated detection systems routinely do — sees an obvious inconsistency.
Why DNS Leaks Are a Bigger Problem Than Most People Realize
For general privacy, a DNS leak means your browsing habits are visible to your ISP despite using a VPN or proxy. For operational workflows, the consequences are more specific.
Anti-fraud and anti-bot systems compare your HTTP exit IP against your DNS resolver's ASN (Autonomous System Number) and geographic location. A profile connecting from a German residential IP but resolving DNS through Comcast's US resolver creates a clear inconsistency. That mismatch elevates the risk score even if every other signal looks legitimate.
For multi-account workflows, a DNS leak can create a cross-account linkage. If multiple accounts share the same DNS resolver (your home ISP) despite having different proxy IPs, the resolver identity becomes a correlation point.
There's also the geo-accuracy problem. Platforms that serve geo-localized content — pricing, search results, ads — sometimes use DNS resolver location as an additional geo signal. If your proxy says Germany but your DNS says Virginia, the content served may not accurately represent what a real local user sees.
Common Causes of DNS Leaks
HTTP proxies with local DNS resolution. HTTP and HTTPS proxies route web traffic but do not handle DNS by default. The browser resolves domain names locally before connecting to the proxy, meaning DNS queries go to your system's configured resolver rather than through the proxy tunnel.
SOCKS5 proxies without remote DNS. SOCKS5 supports two modes: local DNS resolution (the client resolves the domain before connecting) and remote DNS resolution (the proxy server resolves the domain). Most configurations default to local DNS. You need to explicitly enable remote DNS — in curl this means using socks5h:// instead of socks5://, and in browsers using the appropriate setting.
VPN split tunneling. Many VPN configurations route only specific traffic through the tunnel. If DNS queries are excluded from split tunneling, they travel outside the VPN on the regular connection.
OS-level DNS override. Windows, macOS, and Linux all have system-level DNS settings that can override application-level proxy configurations. Some ISPs and corporate networks also use transparent DNS proxies that intercept DNS queries regardless of what resolver you've configured.
Browser-level DNS caching. Chrome maintains its own internal DNS cache separate from the OS cache. Stale entries in Chrome's cache can cause queries to bypass your current proxy configuration entirely. The same applies to Firefox's internal DNS cache. Note that this is distinct from a full DNS resolution failure — if you're seeing a "DNS server not responding" error rather than a leak, that's a different problem covered in the NodeMaven DNS server not responding guide.
IPv6 DNS leaks. If your system has an IPv6 address and your proxy only tunnels IPv4, IPv6 DNS queries will bypass the proxy and go to your ISP's IPv6 resolver. This is particularly common in environments where IPv6 is enabled by default but the proxy doesn't support it.
How to Test for a DNS Leak
Manual browser test
The fastest method is running a DNS leak test in the browser you want to verify. The NodeMaven DNS leak test tool sends test queries from your browser and reports which DNS resolvers responded — their IP addresses, ISPs, and geographic locations. If the resolvers shown belong to your home ISP rather than your proxy provider or a neutral resolver like Cloudflare or Google, you have a leak.
Run this test with your proxy active. The result should show resolvers that match your proxy's geographic location, not your physical location or home ISP.
For deeper verification, BrowserLeaks' DNS test resolves 50 randomly generated domains (25 IPv4-only, 25 IPv6-only) to maximize the chance of catching intermittent leaks. It's the most thorough browser-based DNS test available and worth running when you're auditing a new proxy setup for the first time.
Command-line verification
For a quick check outside the browser, you can verify which DNS resolver your system is actually using with standard command-line tools:

Check which DNS server resolves a query

Linux / macOS

dig +short TXT whoami.ds.akahelp.net
nslookup example.com

Windows

nslookup example.com

More detailed: show the resolver being used

dig example.com +short

Compare the server line in the output with your expected proxy resolver

For SOCKS5 proxies, you can test whether DNS is resolving remotely or locally using curl:

socks5:// = local DNS resolution (potential leak)

curl --proxy socks5://user:pass@host:port https://ipinfo.io/json

socks5h:// = remote DNS resolution through proxy (no leak)

curl --proxy socks5h://user:pass@host:port https://ipinfo.io/json

The difference in output between the two commands tells you whether your DNS queries are actually going through the proxy. If both return the same resolver information, remote DNS is working. If socks5:// shows your real ISP's resolver and socks5h:// shows a different one, you've confirmed the leak vector.
Python: automated DNS leak check
For integrating DNS leak detection into a proxy workflow:
import requests
import socket

def check_dns_leak(proxy_url: str) -> dict:
"""
Check which DNS resolver handles queries when using a proxy.
Uses DNS leak test APIs that return resolver info.
"""
proxies = {"http": proxy_url, "https": proxy_url}

# Query a DNS leak test API that returns resolver information
try:
    # This endpoint returns the DNS resolver IP that resolved the request
    response = requests.get(
        "https://bash.ws/dnsleak/test/random_id_here?json",
        proxies=proxies,
        timeout=15
    )
    resolvers = response.json()

    # Get the HTTP exit IP for comparison
    ip_response = requests.get(
        "https://httpbin.org/ip",
        proxies=proxies,
        timeout=10
    )
    exit_ip = ip_response.json().get("origin", "unknown")

    return {
        "http_exit_ip": exit_ip,
        "dns_resolvers": resolvers,
        "leak_detected": any(
            r.get("ip") != exit_ip for r in resolvers
        ) if resolvers else None
    }
except Exception as e:
    return {"error": str(e)}

result = check_dns_leak("http://user:pass@host:port")
print(result)

A clean result shows DNS resolvers whose IP addresses are consistent with your proxy's exit IP location. If the resolver ASN or country differs from your proxy's exit IP, you have a leak.
What the Results Mean
When you run a DNS leak test, you'll see one or more resolver entries. Here's how to interpret them:
No leak detected. The resolvers shown belong to your proxy provider's infrastructure, your VPN provider, or a neutral third-party resolver (Cloudflare 1.1.1.1, Google 8.8.8.8) that doesn't identify you geographically. The ISP field in the results doesn't match your home ISP.
ISP resolver visible. Your home ISP's DNS servers are handling queries. This is a confirmed leak — your browsing activity is being logged by your ISP regardless of the proxy being active.
Geographic mismatch. The resolvers shown are in a different country than your proxy's exit IP. For example, your proxy exits in the Netherlands but your DNS resolves through a US-based resolver. Even if it's not your home ISP, the geographic inconsistency is a problem for workflows that depend on accurate geo-localization.
Multiple resolvers. Multiple resolvers in the results isn't automatically a problem, but if the list includes both expected resolvers and your home ISP, the ISP entries represent a leak that needs to be addressed.
How to Fix DNS Leaks
Fix 1: Use SOCKS5 with remote DNS
The cleanest fix for proxy-based workflows is switching from local DNS resolution to remote DNS. If you're using curl or a library, change socks5:// to socks5h://. In Python's requests library:
import requests

proxies = {
"http": "socks5h://user:pass@host:port", # h = remote DNS
"https": "socks5h://user:pass@host:port"
}

response = requests.get("https://example.com", proxies=proxies)

In Firefox: go to Settings → Network Settings → Manual proxy configuration → check "Proxy DNS when using SOCKS v5". This single checkbox routes all DNS queries through the SOCKS5 proxy rather than your system resolver.
Fix 2: Configure DNS over HTTPS (DoH) in the browser
Chrome and Firefox both support DNS over HTTPS, which bypasses the system resolver and sends encrypted DNS queries to a provider of your choice. This prevents ISP interception and resolver logging.
In Chrome: Settings → Privacy and security → Security → Use secure DNS → select a provider (Cloudflare, Google, or custom). This overrides the system DNS for Chrome's web traffic.
In Firefox: Settings → General → Network Settings → Enable DNS over HTTPS → select provider. Firefox has used Cloudflare's DoH by default on US connections for several years; verify it's enabled if you're running Firefox-based automation.
Fix 3: System-level DNS configuration
For a system-wide fix that covers all applications, configure your OS to use a reliable third-party resolver:

Linux: edit /etc/resolv.conf

Add or replace nameserver lines:

nameserver 1.1.1.1 # Cloudflare
nameserver 1.0.0.1 # Cloudflare secondary

nameserver 8.8.8.8 # Google alternative

macOS: System Settings → Network → your connection → DNS → add servers

Windows: Control Panel → Network → adapter → Properties → IPv4 → DNS server

Flush DNS cache after changing:

Windows

ipconfig /flushdns

macOS

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd)

sudo systemd-resolve --flush-caches

Fix 4: Disable IPv6 if not using it through the proxy
If your proxy doesn't support IPv6, IPv6 DNS queries will bypass it:

Linux: disable IPv6 temporarily

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

Make permanent: add to /etc/sysctl.conf

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

On Windows, disable IPv6 per network adapter in the adapter properties, or use netsh interface ipv6 set global disabled.
Fix 5: Flush Chrome's internal DNS cache
Chrome's internal DNS cache is separate from the OS cache and persists independently. Clear it before testing a new proxy configuration:
Navigate to chrome://net-internals/#dns and click "Clear host cache". Also check chrome://net-internals/#sockets and click "Flush socket pools" to close any existing connections that might be holding stale DNS entries.
Proxy Type and DNS Leak Risk
Different proxy types have different default behaviors around DNS:

For scraping or account management workflows, SOCKS5 with remote DNS is the recommended configuration — it routes both traffic and DNS queries through the proxy's network, which means the DNS resolver ASN matches the proxy exit IP and the identity is coherent across both layers.
DNS Leak Pre-flight Checklist
Run through this before any proxy session where DNS consistency matters:
[ ] Proxy is active and HTTP exit IP shows the expected location
[ ] Run the NodeMaven DNS leak test tool — no ISP resolvers visible
[ ] Resolvers shown are geographically consistent with proxy exit IP
[ ] If using SOCKS5, confirm remote DNS mode (socks5h:// or browser "proxy DNS" setting enabled)
[ ] IPv6 disabled or routed through proxy if IPv6 support is available
[ ] Chrome internal DNS cache cleared if recently changed proxy configuration
[ ] Cross-check with WebRTC leak test — NodeMaven WebRTC leak test confirms no IP exposure through browser peer connections
[ ] Re-run after any browser update, system update, or proxy provider change
DNS leaks and WebRTC leaks are the two most common vectors that break proxy isolation in browser-based workflows. Fixing DNS takes one configuration change in most environments. The test takes under 30 seconds. Running both checks as a standard pre-flight step costs almost nothing and closes the most frequently overlooked gaps in proxy setups.