How to Fix a DNS Leak

What this actually is

A DNS leak is not a hole in the tunnel. The tunnel can be working perfectly - what escapes is the step that happens before it, when your device asks a resolver to turn a site name into an address. If that question goes to a resolver your VPN does not run, whoever operates it sees the name of every site you open, in order, with timestamps. The traffic itself stays encrypted the whole time, which is why this is so easy to miss: everything looks fine.

The resolver answering for you is not operated by your VPN. Whoever runs that resolver sees the name of every site you open, even though the traffic itself is encrypted - which is most of what a tunnel is supposed to hide.

How it shows up

• A leak test names your internet provider, or a resolver you did not choose, while your IP address correctly shows the VPN.
• Streaming services put you in the wrong region even though the exit node is in the right country.
• The problem survives disconnecting and reconnecting, and sometimes survives switching servers.
• Everything else on a leak test passes.

Causes, in the order to check them

Work down the list in order. The first is the quickest to check and to undo, and the later ones only apply once it has been ruled out - which stops you disabling things you never needed to touch.

1. 1 Encrypted DNS in the browser is bypassing the tunnel

   Check this first: it is one setting and easy to undo. The browser resolves names itself over HTTPS, so the VPN client never sees the query and cannot route it.

   On Android
   1. Chrome: Settings → Privacy and security → Use secure DNS → turn it off.
   2. Firefox: Settings → Privacy & Security → DNS over HTTPS → Off.
   3. Brave: Brave Shields & privacy → Use secure DNS → turn it off.
   4. Re-run the test. If the resolver changes, this was the cause.
   On iOS
   1. Apple and Google describe no secure DNS setting for Safari or Chrome on iPhone and iPad. Encrypted DNS there is set for the whole device, by an app or a profile - the next cause.
   Any platform
   1. Chrome and Edge: Settings → Privacy and security → Security → turn off "Use secure DNS".
   2. Firefox: Settings → Privacy & Security → DNS over HTTPS → set to Off.
   3. Re-run the test. If the resolver changes, this was the cause.
2. 2 A system-level resolver override is still in place

   It can be left over from earlier troubleshooting, or set by an app, and it survives reconnecting because it sits below the VPN client.

   On Windows
   1. Settings → Network & Internet → your adapter → Edit DNS server assignment → set to Automatic (DHCP).
   2. Run "ipconfig /flushdns" in Command Prompt.
   3. Reconnect the VPN - DNS is applied when the tunnel comes up, so the change does not take effect until then.
   On macOS
   1. System Settings → Network → your connection → Details → DNS → remove any manually added servers.
   2. Run "sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder" in Terminal.
   3. Reconnect the VPN afterwards.
   On Linux
   1. Check /etc/resolv.conf and your NetworkManager connection for a static DNS entry.
   2. Remove the override, then reconnect the VPN so it can install its own resolver.
   On Android
   1. Settings → Network & internet → Private DNS → Off → Save. On a Samsung Galaxy: Settings → Connections → More connection settings → Private DNS → Off.
   2. A provider hostname there (dns.google, for example) sends every lookup to that resolver. Mullvad and Proton both tell users of their apps to turn Private DNS off.
   3. Reconnect the VPN and re-run the test.
   On iOS
   1. Settings → Wi-Fi → the (i) next to your network → Configure DNS. If it says Manual, delete the servers added there, choose Automatic and tap Save. The setting is per Wi-Fi network; there is none for mobile data.
   2. Settings → General → VPN & Device Management: an encrypted DNS app or a configuration profile shows up here. Turn it off or delete the profile - Apple notes that if the app that made it is still installed, the setting can return.
   3. Reconnect the VPN and re-run the test.
   Any platform
   1. Look for a manually configured DNS server in your network settings and set it back to automatic.
   2. Reconnect the VPN afterwards - DNS is applied when the tunnel comes up.
3. 3 The tunnel does not supply a resolver of its own

   A case for self-hosted and hand-configured connections. Commercial apps push a resolver when they connect; a server that does not leaves the client using whatever it was using before, so the queries travel through the tunnel but are still answered by a third party.

   Any platform
   1. On a self-hosted OpenVPN server, add a push directive for DNS to the server config - for example: push "dhcp-option DNS 10.8.0.1" - and restart it.
   2. On WireGuard, set DNS = in the client's [Interface] section.
   3. For a commercial app, look for a "use the VPN's DNS" or DNS leak protection toggle and enable it.
   4. Reconnect and re-run this test - the resolver should then sit in the same network as your exit node.
   On Android
   1. In the WireGuard app, or any VPN profile you set up yourself, give the tunnel a DNS server; in a commercial app, turn off any custom DNS option.
   2. Mullvad (2024) and IVPN found in their own testing that Android sends lookups outside the tunnel when the VPN has no DNS server configured - even with Block connections without VPN on.
   3. Reconnect and re-run this test - the resolver should then sit in the same network as your exit node.
4. 4 The router is intercepting DNS

   Some ISP-supplied routers redirect all port 53 traffic to their own resolver regardless of device settings.

   1. Check your router for a "DNS relay", "smart DNS" or parental-filtering feature and disable it.
   2. If the router cannot be changed, a VPN protocol that carries DNS inside the tunnel avoids the interception entirely.