DNS Leaks Behind a Proxy: When Your Resolver Quietly Reveals the Real You

Two months ago I burned an entire afternoon debugging why a client's accounts kept getting flagged. Fingerprints were clean — passed CreepJS, passed FingerprintJS Pro, passed every test I threw at them. German residential proxy, Europe/Berlin timezone, de-DE locale. Everything aligned.

Then someone suggested running BrowserLeaks DNS.

Comcast.

Every single query resolving through Comcast's DNS servers in Chicago. While the "German user" was supposedly browsing from Frankfurt. I felt like an idiot. Four hours of canvas debugging when the leak was happening before the page even loaded.

That's a DNS leak. And honestly? It's the leak vector that antidetect documentation never covers properly. We talk endlessly about canvas fingerprinting, WebGL, timezone mismatches, WebRTC — but DNS? The query that happens before any of those fingerprints even matter? Crickets.

By the end of this tutorial, you'll have JustBrowser profiles with per-profile DNS-over-HTTPS configured, routing DNS queries appropriately so they don't expose your real ISP. No more German proxy with American DNS fingerprint.

Prerequisites

Before we start:

JustBrowser installed — the 7-day trial is full access, so every setting below is available during it
A working proxy — residential, ISP, datacenter, whatever. Configured and connecting.
Access to DNS leak test sites — BrowserLeaks, DNSLeakTest.com, IPHey

If you haven't set up proxies yet, the ISP proxy setup tutorial covers the basics. Get that working first.

Step 1: Understand Why DNS Leaks Happen

Here's what happens when you type "amazon.de" into a proxied browser:

Browser asks: "What IP address is amazon.de?"
Your operating system answers this question — using its configured DNS servers
OS returns the IP (say, 52.95.120.67)
Browser now connects to 52.95.120.67 through your proxy

See the problem? Step 2 happens locally. Your OS queries its DNS servers — usually your ISP's — before the proxy ever gets involved. The proxy routes the connection, sure. But the DNS lookup already leaked.

This is why just "setting a proxy" isn't enough. The proxy handles TCP connections. DNS is a separate query that happens earlier in the request lifecycle. Most proxy configurations don't touch DNS at all.

I think this is the most under-discussed gap in antidetect tooling. Everyone obsesses over canvas hashes. Nobody talks about the DNS query that fired 200ms before the canvas even rendered.

What detection systems see:

Anti-fraud systems can infer which DNS resolver answered the query through various fingerprinting methods — embedded resources, timing patterns, TLS certificate fingerprints. German residential IP + American ISP DNS resolver = obvious proxy user. Real Germans use German DNS resolvers. Vodafone DE, Deutsche Telekom, or maybe Cloudflare/Google. Not Comcast Chicago.

Step 2: Test Your Current Setup

Before fixing anything, confirm you have a leak. Open your JustBrowser profile with the proxy active and visit these sites:

BrowserLeaks DNS Test: https://browserleaks.com/dns Shows exactly which DNS servers handle your queries. You'll see IP addresses and their geographic locations. If you see your ISP's name or your home country while proxied elsewhere — leak confirmed.

DNSLeakTest.com: https://dnsleaktest.com Run the extended test. It queries multiple domains to catch resolvers you might miss with a single query. If any result shows your real location — leak confirmed.

IPHey: https://iphey.com Includes DNS resolver info in its overall fingerprint report. Good for checking multiple leak vectors at once.

What you want to see: DNS resolvers that make sense for your proxy's location — Cloudflare, Google, Quad9, or local ISPs. What you don't want to see: "Comcast" when your proxy claims Berlin. "AT&T" when your proxy claims Tokyo.

(I once spent two hours convinced a profile was clean because IPHey showed a good score. Never checked DNS specifically. Don't be me.)

Step 3: The Three Ways to Fix DNS Leaks

You've got options here. Each has tradeoffs.

Option A: DNS-over-HTTPS per Profile (Recommended)

JustBrowser supports per-profile DNS-over-HTTPS configuration. This encrypts DNS queries and routes them through a specific resolver — bypassing your OS's DNS settings entirely.

In your profile settings, find the DNS-over-HTTPS option. You'll have three choices:

Cloudflare (1.1.1.1) — Fast, privacy-focused, worldwide anycast
Google (8.8.8.8) — Fast, reliable, worldwide anycast
Quad9 (9.9.9.9) — Privacy-focused with malware blocking

For most profiles, Cloudflare or Google works fine. These are common enough that using them doesn't flag your profile — millions of legitimate users configure browser DoH. The key is that you're no longer using your ISP's resolver.

Important caveat: If you're running 50 profiles all pointing to the same Cloudflare DoH, you've created a new fingerprint. Same resolver across your whole fleet. For account separation on paranoid platforms, mix it up: some on Cloudflare, some on Google, some on Quad9. Real user populations are messy. Your profiles should be too. For tracking profile-level analytics across your fleet, JustAnalytics can log the sessions you run through your own scripts.

Option B: SOCKS5 with Remote DNS

If your proxy supports SOCKS5, you can configure DNS resolution to happen on the proxy server itself — not locally.

This is technically cleaner than DoH because the DNS query actually routes through your proxy's network. The resolver you hit is determined by the proxy server's location, not your configuration. German proxy server queries German ISP DNS or whatever that datacenter uses.

How it works: With a SOCKS5 proxy configured in JustBrowser, hostname resolution behaviour depends on the proxy; for a guaranteed per-profile resolver, use the profile's DNS-over-HTTPS setting (Option A).

The catch: Not all SOCKS5 proxies support remote DNS. Some will silently fall back to local resolution. Infuriating. You think you're covered, you're not. Always test after configuring.

Option C: System-Level DoH (Fallback)

If you're working in a browser that doesn't expose per-profile DoH — most don't — configure DNS-over-HTTPS at the OS level instead. Windows 11 and macOS both support it natively. Not per-profile, though: every profile on the machine ends up on the same resolver. Fine for basic setups, not ideal for serious account separation. But it beats leaking your ISP to every site.

Step 4: Configure DNS-over-HTTPS in JustBrowser

Quick walkthrough — there's one plan, so these settings sit on every account, trial included:

Open profile settings — Click Edit on your profile, find Network or Advanced section
Enable DNS-over-HTTPS — Toggle it on, pick Cloudflare, Google, or Quad9 from the dropdown
Save and test — Launch the profile, hit BrowserLeaks DNS, verify you see Cloudflare's IPs (104.16.x.x range) instead of your ISP
Repeat for each profile — DNS config is per-profile, not global. Twenty profiles means twenty configurations.

If you're on SOCKS5: Resolution behaviour is down to the proxy, so test it the same way — BrowserLeaks should show a resolver matching your proxy's region. If it doesn't, fall back to the profile's DNS-over-HTTPS setting above.

Step 5: Avoiding Common Mistakes

Look, I've made all of these. Repeatedly.

Mistake 1: Enabling DoH but not testing. DoH can fail silently. Browser tries DoH, times out, falls back to system DNS. You're leaking and don't know it. Test with BrowserLeaks after every configuration change.

Mistake 2: Forgetting DNS when switching proxies. You set up a profile with a German proxy and Cloudflare DoH. Later, you change the proxy to Japanese. Now you've got Japanese IP, Cloudflare DNS, and your timezone's still German. Three signals, none matching. I did this last month. Took me an hour to figure out why accounts were getting flagged immediately after proxy rotation.

Mistake 3: Assuming the proxy handles it. HTTP proxies don't handle DNS. HTTPS proxies usually don't either. Only SOCKS5 with explicit remote DNS support routes DNS through the proxy. Don't assume — verify.

Step 6: Verify the Complete Stack

Once DNS is configured, run your full verification stack. DNS is one leak vector — there are others. A clean profile passes all of these:

1. BrowserLeaks DNS — No ISP resolver leaking 2. BrowserLeaks WebRTC — No local IP leaking (separate from DNS, but often happens alongside) 3. IPHey — Overall fingerprint coherence, includes DNS check 4. CreepJS — Trust score, lies detection 5. Pixelscan — Cross-references multiple signals

If DNS is clean but WebRTC is leaking local IPs, you've still got a problem. These leak vectors are independent — fixing one doesn't fix the others. The WebRTC protection guide covers that specific leak.

For ad verification work where you're checking competitor landing pages or validating creatives, pair this setup with ClickzProtect to catch click fraud patterns draining your ad budget.

Common Errors and How to Fix Them

DNS leak test shows ISP despite DoH enabled

Cause: DoH failed silently, browser fell back to system DNS. This happens when the DoH resolver is unreachable or blocked.

Fix: Check if your network blocks DoH (some corporate networks do). Try a different resolver — if Cloudflare fails, try Google or Quad9. If all fail, your network might be blocking DoH entirely. Consider using SOCKS5 with remote DNS instead.

SOCKS5 remote DNS not working

Cause: Your proxy provider doesn't support remote DNS resolution.

Fix: Contact your proxy provider and ask explicitly: "Does your SOCKS5 support remote DNS resolution?" Some cheap providers don't. If they can't confirm it, stop relying on the proxy for resolution and turn on the profile's DNS-over-HTTPS setting instead — that's the resolver control JustBrowser actually gives you per profile.

DNS resolvers show weird locations

Cause: DoH resolvers like Cloudflare use anycast — your query goes to the nearest edge server. If you're in Chicago using Cloudflare DoH with a German proxy, the DoH query might still hit a US edge.

Fix: This is expected with anycast DoH. Annoying, but still better than leaking your ISP's resolver. For perfect geographic consistency, use SOCKS5 remote DNS so the resolver is on the proxy's network. Or accept the tradeoff — Cloudflare's edge location is way less damning than "Comcast Chicago."

Tests show no leak, but accounts still get flagged

Cause: DNS wasn't the issue, or wasn't the only issue. Platforms check multiple signals. Clean DNS with dirty fingerprint still fails.

Fix: Run the full verification stack. Check canvas, WebGL, timezone, WebRTC, TLS fingerprint. DNS is one vector. If you've fixed it and still see flags, something else is leaking. The CreepJS walkthrough covers fingerprint debugging in detail. For multi-account operators running ads, tracking conversion anomalies can help identify which profiles are triggering platform flags.

Next Steps

Once DNS is locked down:

Document your per-profile DNS settings. When managing 20+ profiles, you will forget which resolver each one uses. Trust me.
Run periodic leak tests. Monthly spot-check. Systems update, configurations drift.
Test after any network change. New WiFi, VPN toggle, OS update — any of these can reset DNS behavior.
Mix your resolvers. If all 50 profiles use Cloudflare DoH, that's a fingerprint. Diversify.

DNS leaks are subtle. They don't trigger immediate bans — they contribute to a risk score that eventually tips over. By the time you realize DNS was the problem, you've already lost the accounts.

Five minutes of configuration per profile. Beats explaining to a client why their "undetectable" setup got flagged on day two.

Frequently Asked Questions

What exactly is a DNS leak in an antidetect browser context?

A DNS leak happens when your browser resolves domain names through your real ISP's DNS servers instead of routing those queries through your proxy. You set a German proxy, traffic routes through Germany — but the DNS query for "amazon.de" still goes to your ISP in Chicago. Detection systems see German IP but American DNS resolver fingerprint. That inconsistency flags the session as proxied or VPN traffic. It's subtle, but sophisticated platforms absolutely check for it.

Why doesn't setting a proxy automatically route DNS through it?

Because DNS resolution happens at the OS level by default, before the proxy even sees the request. Your browser asks "what's the IP for amazon.de?" and your operating system answers using its configured DNS servers — usually your ISP's. Only after getting that IP does the browser connect through the proxy. The proxy routes the connection, but the DNS lookup already happened locally. You need explicit DNS-over-HTTPS or SOCKS5 with remote DNS resolution to fix this.

Does DNS-over-HTTPS fully prevent DNS leaks?

It depends on the configuration. If DoH is enabled but still pointing to your ISP's resolver, you're encrypting queries but still leaking resolver identity. If DoH points to Cloudflare (1.1.1.1) while your proxy is in Germany, you're better — but now you have American DoH resolver with German proxy IP. Ideally, route DNS through the proxy itself using remote DNS resolution, or use a DoH resolver in the same region as your proxy. JustBrowser's per-profile DoH lets you set different resolvers per profile.

How do I test for DNS leaks in my antidetect browser profile?

Three sites: BrowserLeaks DNS test shows which resolvers handle your queries. DNSLeakTest.com runs extended tests across multiple domains. IPHey includes DNS resolver checks in its fingerprint report. Run all three with your proxy active. If any show your real ISP or a resolver in the wrong country, you have a leak. Test every profile — DNS configuration doesn't automatically carry across profiles in most antidetect browsers.

Try JustBrowser

Native Chromium antidetect browser — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, so 40+ identity parameters are genuine, not faked. REST API for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.

Get started → · How it differs from Multilogin / GoLogin / AdsPower