Short answer: Windows DNS leaks usually come from a resolver path mismatch: the VPN is connected, but the browser or operating system still uses ISP DNS, router DNS, browser Secure DNS, an old adapter setting, or a split tunnel rule.
DNS can reveal domain-level lookups even when the page IP appears to use a VPN. A Windows-focused check helps you separate VPN DNS, browser DNS, adapter DNS, router DNS, and IPv6 behavior.
Problem
- This page is for one current browser/session and route, not every app or future connection.
- The useful question is whether the visible signal matches the route you expected.
- One clean result is helpful, but it is not proof of anonymity, device safety, or a complete VPN audit.
Run the test
Start with DNS Leak Test. Keep the same browser and network when comparing before and after.
- Run DNS Leak Test with the VPN disconnected and note resolver owner and country.
- Connect the VPN and run the same DNS Leak Test again in the same browser.
- If results differ by browser, check Secure DNS or DNS-over-HTTPS settings.
- If results still point to ISP/router DNS, review VPN DNS leak protection and Windows adapter DNS settings.
- Run VPN Leak Test, WebRTC Leak Test, and IPv6 Leak Test if the DNS result does not match the visible IP route.
- Use Safe Copy after the final run so you keep safe categories without raw resolver IPs.
How to interpret results
| Result | Usually means | What to do next |
|---|---|---|
| VPN provider DNS | Usually expected when the VPN manages DNS. | Check DNS, IP, WebRTC, and IPv6 together before assuming all is clean. |
| Public DNS you selected | Can be normal if browser or system Secure DNS is intentional. | Document that this is your chosen resolver path. |
| ISP or home router DNS | Stronger review signal while VPN is connected. | Check VPN DNS protection, adapter settings, and split tunneling. |
| Different country only | Not automatically a leak because anycast and geolocation can differ. | Focus on resolver owner and intent, not country alone. |
| Inconclusive endpoint | The browser could not get a usable signal. | Retest after reconnecting or use another browser/network for comparison. |
Windows places to review
- VPN app DNS leak protection and kill switch settings.
- Windows Network and Internet adapter DNS configuration.
- Browser Secure DNS settings in Chrome, Edge, Firefox, or Brave.
- Split tunneling rules that exclude the browser.
- Router DNS and IPv6 behavior when the router controls the route.
What to do after the result
If the result matches your expectation, keep the setup stable and save the receipt before changing anything else. If the result needs review, do not change several settings at once. Record the browser, device, network type, VPN server, DNS mode, and whether the test was run before or after connecting. Then change one layer, rerun the same test, and compare the new receipt with the previous one.
When two signals disagree, prioritize route ownership over labels. City and country labels can be approximate, but ISP, ASN, resolver owner, WebRTC candidate category, IPv6 reachability, and VPN state usually explain the next practical step. This keeps the page useful for real troubleshooting instead of turning the test into a one-off yes or no result.
Frequently asked questions
Is DNS country mismatch always a Windows DNS leak?
No. Anycast, resolver routing, and geolocation databases can make the country label differ. Resolver owner and intent matter more.
Can browser Secure DNS bypass VPN DNS on Windows?
Yes. If the browser uses its own Secure DNS provider, the DNS result can differ from VPN DNS.
Should I flush DNS cache before every test?
Usually no. Reconnect the VPN and retest first. Flush or restart only when stale behavior appears.
Limits and methodology
MyIPScan checks show observable browser and network signals for the current session. Results can change with browser profile, app route, VPN server, router, OS, carrier, DNS, and time. See the methodology and editorial policy.