HomeBlog

DNS Leaks, and How to Actually Fix One

Published August 29, 2026 Updated August 30, 2026 11 min read

A DNS leak means your VPN is hiding your traffic but not the names of the sites you visit. Here is how to confirm you have one, what it actually exposes, and how to close it on every platform.

You connect to a VPN, check your IP address, and it shows the VPN's location. Everything looks right.

But your browser still has to turn example.com into an IP address before it can fetch anything, and that lookup is a separate request that does not automatically follow the same path as your traffic. If it goes to your ISP's resolver instead of through the tunnel, then your ISP still has a timestamped list of every domain you visited — even though it could not read a single byte of the traffic itself.

That is a DNS leak. Your data stayed private; the index of it did not.

Check your own resolvers

The DNS leak test shows which resolvers actually answered for you, who operates them, and where they sit — the three things that determine whether you have a leak.

Run the DNS leak test →

What a leak does and does not expose

Worth being precise here, because this gets overstated in both directions.

What leaks: the domain names you look up, when you looked them up, and the IP address that asked. Whoever operates the resolver sees that list. If the resolver belongs to your ISP, they may be able to associate those queries with the connection or subscriber account they serve.

What does not leak: the pages within a site, form contents, credentials, or anything else inside the encrypted connection. A DNS leak does not decrypt your traffic. If you want to know whether something is decrypting your traffic, that is a different test.

If you are worried that something is decrypting the traffic itself rather than watching the lookups, that is a different problem — see how to tell if your network is inspecting HTTPS.

So the practical risk is metadata, not content. Whether that matters depends entirely on why you are using a VPN. For someone avoiding ISP-level profiling or regional blocking, it defeats much of the point. For someone on a hostile public network who mainly wants their traffic unreadable, it matters considerably less.

How to read the result

The DNS leak test triggers lookups for unique subdomains and records which resolvers arrive to answer. Three things are worth reading together — the help page covers the mechanics in detail.

Who operates the resolver. If you are on a VPN and the operator shown is your home ISP, that is a leak, full stop. If it is the VPN provider, or a public resolver you deliberately chose, it is not.

How many distinct resolvers appear. Large public resolvers answer from many machines, so several addresses under one operator is normal and not a sign of trouble. Several addresses under different operators usually means your system is querying more than one resolver and only some of them are inside the tunnel.

Where they are. A resolver geographically nowhere near your VPN endpoint is worth a second look, though large providers use anycast, so location alone never proves a leak by itself.

The question that resolves most cases

Who operates the resolver? Not where it is, not how many addresses appeared — who runs it. If the answer is your ISP while you are connected to a VPN, that is a leak.

What your result means

ResultInterpretation
VPN provider's resolver onlyExpected
A public resolver you chose deliberatelyExpected
Your ISP's resolver while the VPN is connectedLikely leak
Several addresses, one operatorNormal — large providers answer from many machines
Several different operatorsInvestigate — more than one resolver is in play
Location differs from your VPN endpointNot conclusive on its own; anycast moves this around

Why leaks happen

Five common causes:

1. The OS queries several resolvers at once

Windows supports multi-homed DNS behaviour that can send queries via more than one network interface and select among the responses. With a VPN active, that can result in queries escaping through the physical adapter if the VPN's own DNS configuration does not take control of resolution. The exact behaviour varies by Windows version and policy, and modern releases handle it better than older ones did — but it remains a common cause on that platform.

2. IPv6 goes around the tunnel

A VPN that only routes IPv4 leaves IPv6 to the physical connection. If your ISP provides IPv6, lookups can travel over it, entirely outside the tunnel. It is only a leak if queries actually take that path — many clients either tunnel IPv6 properly or disable it outright precisely to prevent this.

3. The browser has its own resolver

Firefox and Chrome can perform DNS-over-HTTPS independently of the operating system. That is usually good for privacy, but it means the browser may be using a different resolver than everything else on the machine — and it can bypass a VPN's DNS configuration. It also explains results that seem to contradict each other between a browser test and a system-level one.

System DNS   →  VPN resolver
Browser DoH  →  a different public resolver

Your browser can therefore look clean while another application uses a different resolver entirely — or the reverse.

4. The router hands out its own DNS

If the VPN runs on the router, or a device is configured with static DNS, the resolver may be set at a layer the VPN client on your laptop never touches. If several devices on the same network all show the same unexpected resolver, check the router or gateway before anything else.

5. The VPN dropped without you noticing

If the tunnel disconnects and there is no kill switch, traffic falls back to the normal network path (how to test yours). At that point the issue is broader than a DNS leak: the VPN's traffic protection itself has failed, and DNS is simply one of the things no longer going through it.

Fixing it

Start with the VPN client

Most reputable clients have settings for exactly this, and enabling them resolves the majority of cases without touching the OS:

If those exist and are off, turn them on and re-test before doing anything else below.

Windows

The multi-homed resolution behaviour can be disabled by policy. In gpedit.msc:

Computer Configuration
  → Administrative Templates
    → Network
      → DNS Client
        → Turn off smart multi-homed name resolution   [Enabled]

This is a system-level policy change that affects all name resolution, not just the VPN. Try the VPN client's own DNS protections first, and only change it if those are insufficient.

Home editions lack gpedit, so the equivalent registry value is:

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
  DisableSmartNameResolution = 1   (DWORD)

You can also set the adapter's interface metric so the tunnel is always preferred, and confirm what is configured with:

Get-DnsClientServerAddress
ipconfig /all

macOS

DNS is set per network service, and a VPN may or may not override it depending on how it was configured:

scutil --dns | grep nameserver
networksetup -getdnsservers Wi-Fi

If your ISP's resolvers appear there while connected, check the VPN client's own DNS setting first — many clients manage DNS dynamically, and overriding it manually can bypass the DNS path the VPN intended to use. Where a manual override is the right answer, set it and flush:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Android

Enable the VPN app's Always-on VPN and Block connections without VPN, both under Settings → Network → VPN. Then check Private DNS in the same area: it operates independently of any VPN, and it is frequently the resolver you are actually seeing in the result.

iPhone and iPad

There is less to configure. Enable the VPN profile's always-on behaviour where the provider supports it, and check whether a DNS profile or a third-party content blocker has set a resolver of its own — configuration profiles can override what the VPN expects.

If iCloud Private Relay is on, expect results that look unusual: it routes traffic through Apple's relays and handles name resolution itself, so the resolver you see may belong to neither your ISP nor your VPN. It also does not run at the same time as most VPNs, so check which one is actually active before drawing conclusions.

Router

If DNS is set on the router, change it there — a client-side fix cannot override it. This is also the case where a leak affects every device on the network at once, which is worth checking if several devices show the same unexpected resolver.

Verify

Re-run the DNS leak test with the VPN connected, then disconnect and run it again.

Compare who operates the resolvers in each case, and check whether the connected result matches the DNS path you intended to use. A VPN connection still sending queries to your ISP's resolver is a strong sign of a leak.

Note that identical results are not automatically a failure — if you deliberately use a public resolver both with and without the VPN, seeing it in both is correct. Different results are not automatically a success either. The operator is what to read, not the change.

Encrypted DNS is a different thing

DNS-over-HTTPS and DNS-over-TLS encrypt the lookup so the network path cannot read it. That is genuinely useful on untrusted networks, and it is worth enabling.

But it does not make you anonymous to the resolver. Whoever operates it still receives every query — you have changed who can see your lookups, not whether anyone can. Encrypted DNS to a resolver you do not trust is not obviously better than plaintext DNS to one you do.

One caveat on reading our own tool here: the DNS leak test identifies which resolvers answered and who operates them, and flags whether those operators are known to support encrypted DNS. That is not the same as observing that your query was actually encrypted in transit — the encrypted hop is between you and your resolver, which an authoritative nameserver cannot see. Treat the encryption indicator as a property of the resolver, not a measurement of your transport.

When the result looks wrong

No resolvers captured. Usually aggressive DNS caching, or a browser doing its own DoH so no system-level lookup ever happens. Try a different browser, or a private window.

Resolvers you do not recognise. Many ISPs outsource resolution, and corporate networks often route DNS through a filtering service. An unfamiliar name is not automatically a leak — check who operates it before concluding anything.

Result differs between browsers. That is the browser-level DoH case above, and it is real rather than a test artifact.

Both your VPN's resolver and your ISP's appear. More than one resolver is in play — commonly split DNS, browser DoH alongside the system resolver, or IPv4 and IPv6 taking different paths. Several addresses under one operator is routine; several operators is the thing worth chasing.

Frequently asked questions

What is a DNS leak in simple terms?

Your DNS lookups — the requests that turn domain names into IP addresses — travel outside your VPN tunnel to a resolver your VPN does not control, typically your ISP's. Your traffic stays encrypted, but the list of sites you visited is visible to whoever answers those lookups.

Does a DNS leak mean my traffic is exposed?

No. The contents of your connections stay encrypted. What leaks is metadata: which domains you looked up and when. That is meaningful if your reason for using a VPN is to avoid being profiled, and much less so if you mainly wanted your traffic unreadable on a public network.

How do I know if the resolver shown is a leak?

Ask who operates it. If it is your home or mobile ISP while you are connected to a VPN, that is a leak. If it is the VPN provider or a public resolver you chose deliberately, it is not. Multiple addresses belonging to one large operator is normal.

Why do I see several different DNS servers?

Public resolvers answer from many machines, so several IPs under a single operator is expected. Several IPs under different operators usually means your system is querying more than one resolver, with only some inside the tunnel.

Does DNS-over-HTTPS stop DNS leaks?

Not by itself. DoH stops the network path from reading your lookups, but the resolver still sees them. If your browser's DoH resolver sits outside your VPN, you have simply moved the exposure from your ISP to that provider.

Can my router cause a DNS leak?

Yes, and it is easy to miss. If DNS is configured on the router, that setting applies to every device and cannot be overridden by a VPN client on a laptop. If several devices all show the same unexpected resolver, check the router first.

Does a DNS leak expose my IP address?

Not necessarily — they are separate problems. Your DNS queries can go to the wrong resolver while your public IP still belongs to the VPN, and the reverse also happens. Checking whether the VPN is working covers the IP side.

Can my ISP see my browsing history if I have a DNS leak?

They can see the domain names your device asked about, and when. That is not the same as your browsing history: with HTTPS they do not see which pages you viewed or anything you sent. It is a list of sites, not a record of what you did on them.

Why does my phone leak DNS when my laptop does not?

Mobile operating systems give you far less control over resolver selection, and Android's Private DNS setting works independently of any VPN. Enabling always-on VPN with "block connections without VPN" is usually the fix.

More guides