If you use Mullvad VPN for privacy, a DNS leak can still expose the websites you visit to your ISP or network operator.
This guide explains how to fix DNS leak with Mullvad VPN and verify that your DNS traffic stays inside the tunnel.
DNS leaks usually come from local network settings, browser behavior, or system-level conflicts rather than from the VPN itself, which means the fix is often straightforward once you know where to look.
What a DNS leak means
When you type a domain name such as example.com, your device asks a DNS server to translate that name into an IP address.
If those requests bypass the VPN tunnel, your browsing history can be exposed even while the VPN appears connected.
Mullvad VPN includes built-in DNS protection, but leaks can happen if another resolver is still active on the device, if IPv6 is not handled correctly, or if a browser uses its own DNS feature.
Understanding the path of the request is the first step toward fixing it.
Why DNS leaks happen with a VPN
Most DNS leaks are caused by configuration conflicts.
Common causes include:
- Operating system DNS settings overriding VPN-provided resolvers
- Split tunneling or local network exceptions
- IPv6 traffic escaping while IPv4 is protected
- Browser features such as Secure DNS or DNS over HTTPS
- Static DNS entries from a router, DHCP server, or manual setup
- Firewall or antivirus software intercepting network traffic
Mullvad is designed to route DNS requests through its encrypted tunnel, but the device must also cooperate.
That is why the fix often requires checking both the VPN app and the system itself.
How to fix DNS leak with Mullvad VPN
1. Confirm Mullvad VPN is connected correctly
Start by disconnecting and reconnecting the VPN in the Mullvad app.
Verify that the app shows an active connection and that the selected server is functioning normally.
If the tunnel is unstable, DNS requests can briefly fall back to the local network.
If possible, switch to a different Mullvad server in another city or country and test again.
A server-specific issue is less common than a local settings problem, but it is easy to rule out.
2. Use Mullvad’s built-in DNS protection
Mullvad VPN normally routes DNS through its own encrypted infrastructure.
In the app settings, make sure DNS handling has not been changed by a custom configuration, advanced network tool, or third-party profile.
On supported devices, keep the default DNS behavior unless you have a specific reason to use another resolver.
Using external DNS servers defeats one of the main privacy benefits of Mullvad.
3. Disable browser-based DNS features
Modern browsers such as Google Chrome, Microsoft Edge, Firefox, and Brave may use Secure DNS or DNS over HTTPS.
These features can improve privacy in some cases, but they can also interfere with VPN DNS routing if they point to a provider outside the tunnel.
- In Chrome and Edge, check the Secure DNS setting in Privacy and security
- In Firefox, review DNS over HTTPS settings under Network Settings
- In Brave, inspect the Secure DNS option in Privacy and security
For troubleshooting, temporarily turn off browser-level DNS features and test again.
If the leak disappears, you have found the conflict.
4. Check system DNS settings
Your operating system may still be using a manual DNS address or a resolver pushed by your router.
Review your network adapter settings and confirm that DNS is not locked to a third-party provider such as Google Public DNS, Cloudflare, Quad9, or OpenDNS.
On Windows, inspect the adapter’s IPv4 and IPv6 properties.
On macOS, review DNS servers in Network settings.
On Linux, check NetworkManager, systemd-resolved, or your distribution’s network configuration.
Remove any manual entries that override the VPN.
5. Test IPv6 behavior
IPv6 is a frequent source of leaks because some VPN setups protect IPv4 more consistently than IPv6.
If your ISP provides IPv6 and your device uses it, DNS queries may bypass the tunnel if the VPN or the local network is not handling IPv6 properly.
To troubleshoot, test with IPv6 disabled on the adapter or at the router level.
If the leak stops, re-enable IPv6 only after confirming that Mullvad and your system route it safely.
On devices that support it, Mullvad’s leak protection should still prevent unwanted exposure, but testing is important.
6. Remove conflicting VPN or security software
Another VPN client, a corporate security tool, or a strict antivirus suite can rewrite DNS settings or inject its own filtering service.
If you recently installed network management software, temporarily disable it and retest Mullvad.
This also applies to parental control software, ad blockers that install network drivers, and endpoint protection products used by employers.
These tools can create false positives or genuine DNS leaks depending on how they are configured.
7. Flush the DNS cache
Even after fixing the settings, your device may keep using cached DNS records from before the VPN was properly configured.
Flushing the cache helps force a fresh lookup through Mullvad’s protected path.
- Windows: run ipconfig /flushdns in Command Prompt
- macOS: use the appropriate sudo killall command for your version of macOS
- Linux: restart systemd-resolved or the network service used by your distribution
After clearing the cache, reconnect to Mullvad and test again using a DNS leak checker.
8. Reboot the device and router
A router can supply its own DNS settings through DHCP, and a reboot may be needed after changing resolver configuration.
Restart both the device and the router if the leak persists after software fixes.
This is especially useful when you have changed IPv6 settings, adjusted custom DNS servers, or replaced your internet provider’s default router with a third-party model.
How to verify that the leak is fixed
Once you apply changes, use a reputable DNS leak test site while connected to Mullvad VPN.
The results should show Mullvad-associated DNS servers or servers consistent with the VPN tunnel, not your ISP or home router.
Look for these signs of a clean result:
- DNS servers do not match your ISP
- Your public IP address matches the VPN exit location
- WebRTC does not reveal local network details in the browser
- IPv6 requests are either protected or not exposed at all
Run the test more than once, ideally in a private browsing window and in a second browser, to confirm that the fix is consistent.
Device-specific issues to watch for
Windows
Windows can retain old network profiles and adapter settings longer than expected.
Check adapter DNS entries, flush the cache, and verify that security software is not managing DNS separately from the system.
macOS
macOS often uses resolver behavior tied to the active network service.
If you switch between Wi-Fi and Ethernet, verify DNS settings on both interfaces and retest after reconnecting Mullvad.
Linux
Linux distributions vary widely. systemd-resolved, NetworkManager, and manual /etc/resolv.conf setups can all affect DNS routing, so confirm which component is actually controlling name resolution.
Android and iOS
Mobile platforms may use per-app network features, private DNS options, or battery optimization settings that interrupt the VPN app.
Make sure Mullvad has the permissions it needs and that the device is not forcing a separate private DNS provider.
Best practices to prevent future DNS leaks
- Keep Mullvad VPN updated to the latest version
- Prefer default DNS behavior unless you have a clear reason to change it
- Avoid running multiple VPN tools at the same time
- Review browser Secure DNS settings after updates
- Retest after major OS updates or router changes
- Use a DNS leak test whenever you change network settings
Long-term stability usually comes from keeping the network stack simple.
The fewer third-party components involved, the less chance there is of a resolver escaping the tunnel.
When the problem is not actually a DNS leak
Sometimes what looks like a DNS leak is really a browser privacy feature, cached search results, or WebRTC exposure.
If your ISP is not appearing in DNS test results but your location still seems visible, inspect WebRTC settings and confirm that the VPN exit IP is the only public address in use.
Likewise, captive portals on hotel, airport, or coffee shop Wi-Fi can force temporary DNS behavior before the VPN fully establishes a tunnel.
In those cases, reconnect after the portal authentication completes and test again.