A leak hides at one of these checkpoints. Seal the right one and every lookup stays on the encrypted path.
The fastest way to fix a leak is to stop guessing. The leak test already told you which resolver answered, and that resolver points straight at the layer to change.
First, pin the layer
Re-open the DNS leak test and look at who answered. The owner of that address tells you where the lookup escaped:
- An address belonging to your internet provider points at the operating system or the router: the lookup never entered the tunnel.
- A large public resolver you did not choose usually points at the browser running its own encrypted DNS.
- Your VPN's resolver plus a second one points at the VPN app letting part of the traffic past it.
If you are not sure what you are looking at, does your VPN leak DNS explains how to read the result, and how the DNS leak test works covers why a fresh lookup is reliable.
App-level fixes
Turn on the VPN's own DNS
Most VPN apps have a setting named DNS leak protection, use VPN DNS, or similar. Enable it so the app forces every lookup through the tunnel instead of leaving it to the system. Where there is a kill switch or always-on option, turn that on too so nothing slips out while the tunnel is reconnecting.
Stop the browser doing its own DNS
A browser set to encrypted DNS can answer lookups on its own, bypassing everything else. In Chrome and Edge it is under Privacy and security, Use secure DNS. In Firefox it is Privacy & Security, DNS over HTTPS. Either switch it off so the system decides, or point it at the resolver you actually want.
OS-level fixes
Handle IPv6
If your VPN only tunnels IPv4 but your network also has IPv6, lookups can leave over the path the VPN never claimed. Either enable IPv6 inside the VPN if it supports it, or disable IPv6 on the active network adapter so there is only one path to control.
Set the system resolver, do not leave it on auto
When the operating system is free to pick a resolver, it can fall back to the one your network handed it. Set DNS explicitly on the connection so it cannot wander: Settings or Network preferences on Windows and macOS, Private DNS on Android, resolved.conf or NetworkManager on Linux.
Preventing leaks on modern systems
Recent operating systems and browsers can speak encrypted DNS on their own, without a helper app or a script. Turning that on at the system level is the most reliable prevention: the encrypted resolver is used before any app gets involved, and a network that only intercepts plain DNS has nothing left to catch. Here is where each platform keeps the setting.
Windows 11
Settings, Network & internet, your connection, Hardware properties. Under DNS server assignment choose Edit, switch to Manual, and set DNS over HTTPS to On. The same dialog has an IPv6 block, so set or disable IPv6 here in one place rather than leaving it on automatic.
macOS & iOS
The Network settings only set plain DNS addresses. Real encrypted DNS on Apple systems comes from an installed configuration profile (a .mobileconfig describing a DoH or DoT server), after which Settings shows it under DNS. Once installed it applies system-wide, including Safari, which has no DNS toggle of its own.
Android 9 and later
Settings, Network & internet, Private DNS. Choose “Private DNS provider hostname” and enter the resolver's hostname. Android uses DNS over TLS here and applies it to the whole device, on Wi-Fi and mobile data alike. Avoid the Automatic option, which silently falls back to plain DNS.
Linux
With systemd-resolved, set your resolver and DNSOverTLS=yes in the resolved configuration, or set the same per connection in NetworkManager. That makes the encrypted resolver the system default so desktop apps inherit it without each needing its own setting.
Browsers
Chrome and Edge: Privacy and security, Security, Use secure DNS. Firefox: Privacy & Security, DNS over HTTPS, with a Max Protection option. Decide deliberately: a browser pointed at its own resolver overrides the system, which is useful on purpose but a leak by accident. Safari follows the system profile above.
Router
If the firmware supports DNS over HTTPS or TLS, setting it on the router covers every device on the network at once, including ones that cannot be configured individually. If it does not, set encrypted DNS per device instead, since a plain-DNS router cannot be trusted not to redirect lookups.
The exact server values and step-by-step screens for each of these live in the setup guide, and the protocols page explains the difference between DNS over HTTPS, TLS, and QUIC if you are deciding which to enable.
The fix that survives every network
Toggling a VPN setting fixes the leak only while that VPN is connected. If you set encrypted DNS on the device itself, the protection follows you onto any network, with or without a VPN, and a router that tries to intercept plain DNS has nothing to grab.
The setup guide walks through configuring DNS over HTTPS and DNS over TLS on Windows, macOS, Linux, Android, iOS, and routers. If you want to understand the difference between those protocols before choosing one, the guide on DoH vs DoT vs DNSCrypt vs DoQ compares them in detail.
Confirm it is closed
Change one thing at a time, then run the leak test again. Changing several settings at once tells you the leak is gone but not which fix did it, and the next network may bring it back.
A clean result shows only the resolvers you intended: your VPN's, or the encrypted resolver you set. If an unexpected address still appears, move to the next layer in the list above. If it disappears on one network but returns on another, the cause is that network's router, and the device-level encrypted DNS above is the durable answer.
Re-test after each change
One change, one test. That is how you know which layer was leaking and that it is sealed.
Run the DNS leak test