Most people who set up a proxy or VPN assume their DNS queries are private once the tunnel is active. In practice, that assumption is wrong more often than it's right. DNS leaks are one of the most common and least visible privacy failures in proxy-based setups — and the only way to know whether you have one is to run a test.
This guide covers what DNS leaks are, how to run a proper test, how to read the results, and what to do based on what you find — across Chrome, Firefox, and system-level DNS configurations.
What a DNS Leak Actually Is
Every time your browser or application connects to a domain, it first resolves the domain name to an IP address through a DNS query. That query goes to a DNS resolver — a server that handles the lookup and returns the answer.
By default, your device uses the DNS resolver assigned by your ISP. That resolver is almost always operated by your ISP, which means they receive a log of every domain you query, regardless of what proxy or VPN you have running.
A DNS leak happens when your DNS queries bypass the proxy tunnel and go directly to your ISP's resolver — even while your HTTP traffic routes through the proxy correctly. The result: your traffic appears to come from the proxy's IP, but your browsing activity (which domains you're connecting to) is still visible to your ISP.
For proxy users specifically, a DNS leak also creates a geographic inconsistency. Your HTTP connection exits from a German residential IP. Your DNS queries are answered by a Comcast resolver in Virginia. Any platform that checks both signals — and serious fraud detection systems do — sees an obvious contradiction.
When DNS Leaks Happen
DNS leaks aren't random. They occur in predictable situations:
HTTP proxies without explicit DNS configuration. HTTP and HTTPS proxies route web traffic but leave DNS resolution to the system by default. Unless you've explicitly configured your browser or application to route DNS through the proxy, queries go to your system resolver.
SOCKS5 with local DNS mode. SOCKS5 supports two DNS modes: local (the client resolves the domain before connecting) and remote (the proxy server resolves it). The socks5:// scheme uses local DNS. The socks5h:// scheme uses remote DNS. Most library defaults use local, which leaks DNS.
VPN split tunneling. When a VPN is configured to route only specific traffic through the tunnel, DNS queries are often excluded — meaning they travel outside the VPN on the regular connection.
System DNS override persisting after proxy activation. Some ISPs and corporate networks use transparent DNS proxies that intercept queries at the network level, regardless of what resolver you've configured. Activating a proxy doesn't override this interception.
IPv6 DNS leaks. If your machine has an IPv6 address and your proxy only tunnels IPv4 traffic, IPv6 DNS queries bypass the proxy entirely and go to your ISP's IPv6 resolver. This is one of the most overlooked leak vectors because most people don't think about IPv6 unless they've specifically configured it.
Stale browser DNS cache. Chrome maintains an internal DNS cache that's separate from the OS cache. Cached entries from before you activated the proxy can still resolve without going through the proxy's DNS path, resulting in inconsistent behavior where some queries leak and others don't.
How to Run a DNS Leak Test
Using the NodeMaven DNS Leak Test Tool
The NodeMaven DNS Leak Test tool is the most straightforward way to check your current configuration. Open it with your proxy active, and it automatically sends test queries from your browser and reports which DNS resolvers responded — showing their IP addresses, ISP names, and geographic locations.
The test runs in under 30 seconds and requires no setup or login. The result shows you exactly which resolvers are handling your DNS queries right now, in the context of your current proxy configuration.
Run the test in this sequence for complete coverage:
Without any proxy active — note your default DNS resolvers (this is your baseline)
With your proxy active — compare against baseline
After changing any DNS settings — verify the change took effect
The comparison between Step 1 and Step 2 is the diagnostic. If the same resolvers appear in both, your proxy isn't routing DNS queries. If Step 2 shows different resolvers that match your proxy's location, you're clean.
Reading the Results
A clean result shows one of three things in the resolver field:
Your proxy provider's DNS servers. Some proxy providers operate their own resolvers and route DNS through them automatically. If the resolver IP belongs to the same ASN as your proxy's exit IP, DNS is routing correctly through the proxy network.
A neutral third-party resolver. If you've configured Cloudflare (1.1.1.1), Google (8.8.8.8), or another public resolver explicitly, and those appear in the results, DNS is going where you directed it — not to your ISP.
Resolvers in the same geographic region as your proxy. If the resolver location matches your proxy's exit location, DNS and HTTP traffic are at least geographically consistent, which satisfies most platform checks.
A leaking result shows one or more of these signals:
Your home ISP's resolver. The ISP name in the resolver field matches your real internet provider. This is a confirmed leak regardless of what proxy is active.
Geographic mismatch. Resolvers in a different country than your proxy's exit IP. Even if it's not your home ISP, the inconsistency is a problem for workflows that require accurate geo-localization.
Multiple resolvers including both proxy-side and ISP-side. Mixed results indicate partial DNS routing — some queries go through the proxy, some bypass it. This is unstable and platform-dependent.
IPv6 resolvers alongside IPv4. If you see IPv6 resolver addresses and your proxy is IPv4-only, the IPv6 entries represent a leak channel.
Extended Test for Intermittent Leaks
Some leaks only appear under specific conditions — particular apps that bypass the proxy, specific query types that take a different path, or caching behavior that resolves some domains locally. For a thorough check, also run BrowserLeaks' DNS test, which sends 50 randomized domain queries (25 IPv4, 25 IPv6) to maximize the chance of catching intermittent leaks that a single-query test would miss.
Fixing DNS Leaks by Environment
Chrome and Chromium-based browsers
Chrome has its own DNS-over-HTTPS (DoH) setting that, when enabled, bypasses the system resolver entirely. Go to Settings → Privacy and security → Security → Use secure DNS and select a provider (Cloudflare, Google, or custom). This overrides the system DNS for Chrome's web traffic and eliminates ISP resolver visibility for browser-originated queries.
For automation environments running Chrome or Chromium via Puppeteer or Playwright, add the DoH flag at launch:
chromium --proxy-server=http://user:pass@host:port \
--host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 127.0.0.1" \
--disable-features=AsyncDns
Or use the --proxy-bypass-list and DNS configuration options in your launch arguments to force DNS through the proxy connection.
For complete DNS leak prevention in Puppeteer with SOCKS5:
const puppeteer = require('puppeteer');
const browser = await puppeteer.launch({
args: [
'--proxy-server=socks5://host:1080',
// socks5 in Chrome uses remote DNS by default for SOCKS5 connections
'--host-resolver-rules=MAP * ~NOTFOUND , EXCLUDE 127.0.0.1'
]
});
Note: Chrome's behavior with SOCKS5 proxies defaults to remote DNS (unlike most libraries), which means DNS queries go through the SOCKS5 proxy automatically when you configure a SOCKS5 proxy server in Chrome.
Firefox
Firefox gives you the most direct control over DNS behavior. Three settings in about:config cover all scenarios:
// Disable WebRTC to prevent IP leaks alongside DNS leaks
media.peerconnection.enabled = false
// Enable DNS over HTTPS
network.trr.mode = 2
// 0 = off, 2 = prefer DoH (fallback to system), 3 = DoH only
// Set DoH provider (Cloudflare example)
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
// For SOCKS5 users: route DNS through proxy
// Settings → Network Settings → "Proxy DNS when using SOCKS v5" ✓
The "Proxy DNS when using SOCKS v5" checkbox in Firefox's network settings is the single most important setting for SOCKS5 proxy users. Enabling it changes Firefox's DNS behavior from local resolution to remote resolution through the proxy — one checkbox, leak closed.
Python and requests library
import requests
HTTP proxy — DNS resolves locally (potential leak)
proxies_http = {
"http": "http://user:pass@host:8080",
"https": "http://user:pass@host:8080"
}
SOCKS5 with local DNS — still leaks
proxies_socks_local = {
"http": "socks5://user:pass@host:1080",
"https": "socks5://user:pass@host:1080"
}
SOCKS5 with remote DNS — no leak
proxies_socks_remote = {
"http": "socks5h://user:pass@host:1080", # h = remote DNS
"https": "socks5h://user:pass@host:1080"
}
Verify which resolver is handling DNS
resp = requests.get("https://httpbin.org/ip", proxies=proxies_socks_remote)
print(resp.json()) # Should show proxy IP, not real IP
The socks5h:// vs socks5:// distinction is the most commonly missed detail in Python proxy setups. Both connect through SOCKS5. Only socks5h:// routes DNS through the proxy.
System-level DNS fix
For a fix that covers all applications — not just the browser:
Linux: edit /etc/resolv.conf
Replace ISP-assigned nameservers with:
nameserver 1.1.1.1 # Cloudflare
nameserver 1.0.0.1 # Cloudflare secondary
Flush DNS cache after changing:
Linux (systemd)
sudo systemd-resolve --flush-caches
macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows
ipconfig /flushdns
After changing system DNS, flush Chrome's internal cache separately at chrome://net-internals/#dns — the system DNS change doesn't clear Chrome's in-memory cache.
The DNS and WebRTC Combination
DNS leaks and WebRTC leaks are the two most common vectors that break proxy isolation, and they're worth checking together. A session where DNS is clean but WebRTC exposes your real IP through ICE candidates is still a leaking session. Run the NodeMaven WebRTC leak test alongside the DNS test as part of your pre-flight checklist.
The combination tells you:
DNS test clean + WebRTC test clean: proxy isolation is solid at both the application and network layer
DNS test clean + WebRTC leaking: browser-level WebRTC configuration needs attention
DNS test leaking + WebRTC clean: DNS routing configuration needs attention
Both leaking: start with the DNS fix (usually simpler), then address WebRTC
Pre-flight Checklist: DNS Leak Verification
Before any proxy workflow where DNS consistency matters:
[ ] Proxy active — HTTP exit IP matches expected location
[ ] Run NodeMaven DNS Leak Test tool — no ISP resolvers visible in results
[ ] Resolver locations geographically consistent with proxy exit IP
[ ] If using SOCKS5: socks5h:// scheme or "Proxy DNS when using SOCKS v5" enabled in Firefox
[ ] IPv6 disabled or confirmed routing through proxy (check for IPv6 entries in test results)
[ ] Chrome internal DNS cache cleared after any proxy configuration change (chrome://net-internals/#dns)
[ ] Run NodeMaven WebRTC leak test — no real IP in ICE candidates
[ ] Re-run after any browser update or proxy provider change
DNS leaks are a configuration problem, not a proxy quality problem. The fix in most cases is a single setting change — socks5h:// instead of socks5://, one Firefox checkbox, or a DoH provider selected in Chrome settings. The test takes 30 seconds. Running it before every proxy session costs almost nothing and closes one of the most reliable fingerprinting vectors in browser-based workflows
