How to Fix VPN DNS Leaks on Windows

A DNS leak on a Windows PC is the situation where your website lookups travel outside the VPN tunnel even though the VPN shows as connected. The traffic to the website itself is protected, but the question "where is this site?" goes to your internet provider's resolver or the router at the cafe. This guide focuses on the Windows-specific reasons for a windows vpn dns leak and the fixes in the order that most often works. For the general idea behind DNS and why leaks matter, what a DNS leak is and how DNS works are the right starting points; here we stay practical and stay on Windows 10 and 11.

Why Windows is especially prone to DNS leaks

Many systems have one active network interface at a time. A typical Windows PC has several. Wi-Fi, a docking station's Ethernet port, a Bluetooth network, virtual switches created by Hyper-V or the Windows Subsystem for Linux, and the VPN's own virtual adapter can all exist together, each with its own DNS server list.

Windows gives each adapter an interface metric, a number that sets its priority. When the VPN connects it normally lowers its own metric so its DNS servers are asked first. Problems appear in a few predictable ways.

• Parallel lookups. Windows 8 and later introduced smart multi-homed name resolution, which can send a query to the DNS servers of several adapters at the same time and use the fastest answer. That is convenient on a laptop and is bad for privacy, because the physical adapter's resolver also hears the question.
• A stubborn adapter. The physical Wi-Fi adapter keeps the DNS servers handed out by the router, and the VPN adapter does not override them for every lookup.
• IPv6 resolvers. The router may advertise an IPv6 DNS server that the VPN does not cover, so lookups quietly use that path.
• A browser doing its own thing. Some browsers can resolve names over their own encrypted channel, bypassing the system settings entirely.
• Virtual machines and containers. Anything that creates a new adapter adds a new possible route for lookups.

A leak is therefore usually a configuration mismatch between several adapters, not a defect in the tunnel. That is encouraging, because configuration can be fixed.

Confirm the leak before you change anything

Fixing a leak you have not confirmed is how people end up breaking their network. Spend a few minutes collecting evidence.

1. Record your normal resolvers with the VPN off. Open PowerShell and run Get-DnsClientServerAddress -AddressFamily IPv4. The output lists each adapter with its DNS servers. Note the addresses for Wi-Fi or Ethernet; these are usually your router's address or your internet provider's resolvers.
2. Connect the VPN and run the same command. Look at the VPN adapter's entry. It should list DNS servers different from the physical adapter's.
3. Run nslookup example.com. The first two lines show which server answered ("Server" and "Address"). If that address matches the one you noted in step 1, your lookups are going to the physical adapter's resolver.
4. Use a DNS leak test page in your browser. These pages make your browser request random names and then report which resolvers asked on their behalf. Run the standard test with the VPN on. Compare the list against the addresses from step 1.
5. Read the result sensibly. If you see only the resolver associated with your VPN, there is no leak. If you see your internet provider's or router's resolvers, you have one. If you see a public resolver you recognise because you configured it, that is your own setting, not the VPN's.

If you want a fuller test routine that also covers WebRTC and the kill switch, see how to test a VPN.

Match the symptom to the likely cause

What you see	Likely cause	Where to look
Router or provider resolver appears on every test	Physical adapter DNS is winning	Adapter DNS settings and interface metric
Provider resolver appears only in some lookups	Parallel lookups	Smart multi-homed name resolution
Leak appears only on networks with IPv6	IPv6 DNS server advertised by the router	IPv6 section below
Leak disappears when you close the browser	Browser has its own secure DNS	Browser settings
Leak began after installing virtual machines	New virtual adapter changed priority	Interface metrics and adapter list
Test shows a public resolver you never chose	Another program changed DNS	Installed apps, router, security software
Leak appears only for a few minutes after boot	Lookups happen before the tunnel is up	Delay startup apps, use a kill switch

Work down the table rather than trying every fix at once. Each row points at one fix, and the section that follows describes it.

Fix 1: look at what each adapter says, then correct the obvious problem

Start with the simplest question: which adapter is Windows asking?

1. Run Get-NetIPInterface | Sort-Object InterfaceMetric in PowerShell. The interface with the lowest metric is preferred. When the VPN is connected, its adapter should be near the top.
2. Run ipconfig /all and read the DNS Servers line for each adapter. Note which ones are present.
3. If the VPN adapter has a higher metric than your Wi-Fi, some apps may talk to the Wi-Fi resolver first. You can set the metric by hand with Set-NetIPInterface -InterfaceAlias "Wi-Fi" -InterfaceMetric 50, then reconnect the VPN. The value is only a priority number; pick one higher than the VPN adapter's and keep a note of the original so you can undo it.
4. Do not set the DNS servers on the physical adapter to something random. If the VPN app documents a DNS address it expects you to use, use that. Otherwise leave the VPN to supply its own DNS and set the physical adapter back to automatic with Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ResetServerAddresses.

The goal is not to find a clever setting but to remove ambiguity: one adapter marked as preferred, and the VPN's resolver visible on it. After each change, reconnect the VPN and run the test again.

Fix 2: turn off parallel lookups if the evidence points there

If your leak appears intermittently and the router's resolver shows up in some tests but not others, smart multi-homed name resolution is a suspect. Its behaviour has changed between Windows builds, so confirm with Microsoft's documentation for your version before relying on a recipe from any article, including this one.

For Windows Pro, Enterprise and Education, the policy sits in the Group Policy editor (gpedit.msc) under Computer Configuration, Administrative Templates, Network, DNS Client, with the setting named "Turn off smart multi-homed name resolution". Setting it to Enabled stops Windows from sending queries to all adapters at once. Windows Home does not include that editor, and the same effect is controlled by a registry value that you should not edit from memory.

Practical advice:

• Make a restore point before you change anything.
• Change one thing, reboot, retest.
• If the result does not change, set it back. A policy that does not help is a policy that adds confusion.
• On a managed work PC, leave it alone. DNS policy belongs to the IT team and a change may violate your company rules.

Fix 3: close the IPv6 gap

Many home routers hand out both IPv4 and IPv6 settings. If the router advertises an IPv6 DNS server and the VPN does not carry IPv6, Windows may prefer that resolver for certain lookups. What an IP leak is explains the wider IPv4 and IPv6 picture, and the IPv6 specification, RFC 8200, is the reference for how addresses are structured.

To check, run Get-DnsClientServerAddress -AddressFamily IPv6 with the VPN connected. If the physical adapter shows an IPv6 DNS server and the VPN adapter does not, that is your path. Options in order of preference:

1. Look for an IPv6 leak protection option in your VPN app.
2. Test with IPv6 disabled on the physical adapter only. In the adapter's Properties, clear Internet Protocol Version 6 (TCP/IPv6) and retest. Microsoft cautions against disabling IPv6 system-wide, so limit the change to one adapter and know how to restore it.
3. If that fixes the leak, you have found the cause. Decide whether to keep it, or to look for an app update that handles IPv6.

Fix 4: sort out encrypted DNS in Windows 11 and in browsers

Windows 11 can use DNS over HTTPS, an encrypted way of sending lookups (described in RFC 8484). You set it in Settings, Network and internet, your connection's hardware properties, DNS server assignment. Browsers have a similar secure DNS option in their privacy settings.

Encrypted DNS and a VPN do different jobs. Encrypted DNS hides lookup content from the network between you and the resolver, while the resolver you chose still sees every name. A VPN moves your traffic into a tunnel to someone else's network. When you mix them, be sure you know where the lookups end up. If a browser's secure DNS points at a public resolver, its lookups may skip the VPN's resolver entirely, and a leak test will show that resolver.

Two approaches work:

• Turn the browser's secure DNS to "use system settings" while the VPN is on, so lookups follow the tunnel.
• Keep encrypted DNS on purpose, understand that your chosen resolver sees the names, and treat that as your own decision, not as a leak.

DNS over HTTPS versus a VPN goes through the trade-offs in more detail.

Flush, reconnect, retest

DNS answers are cached, so a change may seem not to work simply because the old answers are still stored.

1. Disconnect the VPN.
2. Run ipconfig /flushdns in an elevated Command Prompt.
3. Close and reopen the browser.
4. Connect the VPN again and wait until it shows connected.
5. Run nslookup example.com and the leak test page.
6. Record the result in a short note: date, network, what changed, what the test showed.

Repeat on every network that matters to you. A fix that works on home Wi-Fi may not work on the hotel network, which hands out different DNS settings.

Two worked examples

The laptop with virtual machines. Mei uses a laptop for work and runs a Linux environment through the Windows Subsystem for Linux. After she installed it, her leak test began showing her router's resolver. The adapter list showed a new virtual adapter with a lower metric than the VPN adapter. She raised the virtual adapter's metric, reconnected, flushed the cache and the test passed. She wrote the change in a note in case a Windows update reset it.

The student on a shared network. Arun's dorm network hands out both IPv4 and IPv6 settings. His test showed the dorm's resolver only on some lookups. The IPv6 query turned out to be the cause: the dorm router advertised an IPv6 DNS address the VPN did not cover. Disabling IPv6 on the physical adapter alone fixed it. He kept the setting and noted it, because he knew the change was easy to undo.

Limits and what to watch for

A clean test does not prove anything permanent. DNS settings change when networks change, when Windows updates run, and when software is installed. Test again after those events.

It is also worth being clear about what you are protecting. Fixing a DNS leak stops the local network from seeing which names you look up. It does not hide the sites you visit from the VPN provider or from the sites themselves, it does not stop phishing, and it does not make you anonymous. What a VPN cannot protect you from is a useful reality check. If a leak keeps returning after you have followed the steps here, collect your notes and ask the VPN's support for help instead of piling on registry changes. The download page links the official app builds in case you need a clean reinstall.

Summary

To fix a windows vpn dns leak, prove it first with a command-line check and a test page, then work down the causes: adapter order and interface metrics, parallel lookups, IPv6 resolvers, and browser secure DNS. Change one thing at a time, flush the cache, reconnect and retest, and record what you did so it can be undone. Treat Windows updates and new network software as reasons to test again.

If you would like a pass to test this on, the pricing page shows the options without any pressure.