DNS Leaks Behind a Proxy: Why Lookups Can Skip It and How to Fix Them Per Profile
Picture a profile set up for a team in Germany: a German proxy, Europe/Berlin timezone, de-DE locale. Everything lines up. Then someone runs BrowserLeaks DNS and every query is resolving through a home ISP's DNS servers in Chicago, while the profile is supposedly browsing from Frankfurt. The leak happens before the page even loads.
That's a DNS leak, and it is easy to miss. Most setup guides cover canvas, WebGL, timezone and WebRTC, but DNS is the query that happens before any of those matter, and it tells your real ISP which sites you visit.
By the end of this tutorial, you'll have JustBrowser profiles with per-profile DNS-over-HTTPS configured, so each profile's DNS queries follow the profile instead of your home network.
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 and DNSLeakTest.com
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 the version of a lookup that leaks, 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.
Whether that happens depends on the setup. With an HTTP or HTTPS proxy set in the browser, the browser normally hands the hostname to the proxy, and the proxy does the lookup. SOCKS5 can do the same, if the hostname is sent to the proxy rather than resolved first. The leaky path shows up with SOCKS setups that resolve locally, with proxies applied at the system level rather than in the browser profile, and with anything that falls back to going around the proxy. That's why "I set a proxy" isn't the same as "I tested it".
Why it matters:
Your real ISP's resolver sees a log of every domain the profile looks up, whatever the proxy is doing. For a team that routes a profile through a regional proxy for QA or ad verification, the lookups should happen in that region too, or the test is not measuring what you think. Resolver location can change the answers, too: many sites hand out different server addresses depending on where the lookup comes from, so a lookup from Chicago can send a "German" profile to a US server.
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.
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.
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 pick a resolver template:
- 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
- Custom — your own DoH template URL, for example a resolver in the profile's region
And a mode: secure uses DoH only, while automatic falls back to ordinary DNS when DoH fails. Use secure when you need to be sure lookups never go around the resolver you chose.
For most profiles, Cloudflare or Google works fine. The key is that you're no longer using your home ISP's resolver.
Choosing a resolver: Pick a resolver that suits each profile's region and your privacy requirements.
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 every SOCKS5 setup resolves hostnames on the proxy side. 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 — many 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 when profiles need different regions. 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, Quad9 or a custom template, and choose secure mode if you want no fallback
- Save and test — Launch the profile, hit BrowserLeaks DNS, verify the resolver shown is the one you picked (Cloudflare's, for example) instead of your ISP's
- 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
Three mistakes come up again and again.
Mistake 1: Enabling DoH but not testing. In automatic mode, DoH can fail silently: the browser tries DoH, times out, falls back to system DNS. You're leaking and don't know it. Use secure mode where it matters, and 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 a Japanese IP, Cloudflare DNS, and a timezone that's still German. Three settings, none matching. Re-check DNS, timezone and language whenever you change a profile's proxy.
Mistake 3: Assuming every proxy setup behaves the same. A browser-level HTTP or HTTPS proxy usually resolves hostnames itself. A SOCKS setup may or may not, and a system-level proxy may leave lookups to the OS. Don't assume — verify.
Step 6: Verify the Complete Stack
Once DNS is configured, check the other places an address can leak. DNS is one vector — there are others:
1. BrowserLeaks DNS — Is your home ISP's resolver showing up? 2. BrowserLeaks WebRTC — Is a local IP exposed? (Separate from DNS, but often happens alongside.) 3. Timezone and language — Do they agree with the proxy's region?
If DNS is clean but WebRTC is exposing a local IP, you've still got a problem. These leak vectors are independent — fixing one doesn't fix the others. JustBrowser includes WebRTC protection in every profile (see what each profile includes).
For ad verification work where you're validating creatives in different regions, 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 in automatic mode when the DoH resolver is unreachable or blocked.
Fix: Switch the profile's DoH mode to secure, so a failure shows up as a failed lookup instead of a quiet fallback. 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.
Tests show no leak, but the profile still behaves oddly
Cause: DNS wasn't the issue, or wasn't the only issue. Pages that localise read the IP, the timezone and the language, and when those disagree they can serve the wrong market.
Fix: Check the profile's timezone and language against the proxy's region, and check WebRTC. DNS is one setting among many. The TLS and JA4 fingerprint guide covers the other network-level signals. And if the pages you're testing are your own and you record sessions with replay, make sure personal data is masked in those recordings.
Next Steps
Once DNS is locked down:
- Document your per-profile DNS settings. When managing 20+ profiles, it is easy to forget which resolver each one uses.
- 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.
- Match resolvers to regions. Where a profile represents a specific region, choose a resolver that suits it.
DNS leaks are subtle. They rarely cause an immediate visible problem, but they quietly send your lookups to the wrong network.
Five minutes of configuration per profile.
Frequently Asked Questions
What exactly is a DNS leak in a multi-account browser?
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. The site sees a German IP, while your real ISP's resolver sees every domain you look up. For privacy and for a coherent setup, both should follow the proxy.
Doesn't setting a proxy automatically route DNS through it?
Often it does: with an HTTP or HTTPS proxy set in the browser, the browser hands the hostname to the proxy and the proxy resolves it. Leaks come from setups where the name is resolved before the proxy sees it — a SOCKS proxy that resolves locally, a proxy applied at the system level rather than per browser profile, or a fallback path that goes around the proxy. Then your operating system answers with its configured DNS servers, usually your ISP's. Test every profile, and use DNS-over-HTTPS or SOCKS5 with remote DNS resolution where the test shows a leak.
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 the resolver is a worldwide anycast service while the proxy is in Germany. 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 a browser profile?
Two sites: BrowserLeaks DNS test shows which resolvers handle your queries. DNSLeakTest.com runs extended tests across multiple domains. Run both 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 browsers.
Try JustBrowser
Native Chromium multi-account browser for teams — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, with 40+ identity parameters rendered by the engine itself. Local REST API + CDP 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
Ready to manage multiple accounts?
Seven days free, then $9.99/month — one plan, everything included.