iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To test a VPN for DNS leaks in 2026, record DNS, public-IP, IPv6 and WebRTC results with the VPN disconnected, then repeat the identical tests on the same device, browser and network while connected. Compare each signal with the VPN provider’s documented routing. An ISP resolver appearing during the connected test is a reason to investigate, but a Google, Cloudflare or other public resolver is not automatically a leak: a VPN may intentionally use third-party infrastructure. DNS, IP, IPv6 and WebRTC are separate checks, so passing one does not prove the others are protected. This controlled before-and-after method, followed by tests during network changes and split-tunnel use, gives a more reliable answer than a single browser result.
What exactly is a VPN DNS leak?
A DNS leak occurs when a device sends a domain-name lookup outside the VPN route to a resolver that can observe it, even though other traffic appears to use the VPN. DNS translates names such as example.com into IP addresses; those lookups can reveal the services a user is trying to reach. A VPN can hide the public IP used for ordinary connections while leaving DNS, IPv6 or browser WebRTC traffic on another path.
The resolver’s IP address also does not have to match the VPN exit IP. A provider can operate separate DNS infrastructure or route lookups to a third-party resolver. Interpret the resolver identity against the provider’s documented design, not against a brand name alone. Proton VPN’s DNS-leak guidance, for example, says its apps route DNS through its servers and explains situations in which custom DNS settings or a VPN interruption can let queries escape.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How should I set up a fair VPN leak test?
Control the variables before you compare results. Use one device, one internet connection, one browser and the same test pages in both states. Record the baseline first, because a resolver that is normal for your local network may look suspicious if you only inspect the VPN-connected result.
#1 Best Overall
Keep the test conditions fixed
- Use the same laptop, phone or tablet for every run.
- Stay on the same Wi-Fi or wired network while collecting the initial pair of results.
- Use the same browser window and avoid changing privacy extensions, proxy settings or secure-DNS options between runs.
- Close any second VPN and note whether Apple iCloud Private Relay is enabled; either can alter the route you are trying to measure.
- Write down the time, VPN server or location, and whether split tunneling or a kill switch is enabled.
These controls follow the comparison approach described in AMTSO’s VPN testing guidance. The guidance is dated February 2025, while client features and labels can change, so use your application’s current wording.
Choose the test pages
Use a DNS test that lists the resolver organizations or addresses it observes. DNSLeakTest.com provides standard and extended tests. Extended testing can produce a longer list of resolvers and is useful when a single lookup does not expose intermittent behavior. Also use separate pages or tools for public IP, IPv6 and WebRTC; one page’s result cannot establish protection for all four signals.
What should I record with the VPN disconnected?
Disconnect the VPN completely, wait for the operating system to restore its ordinary network route, then run the DNS test and record every resolver shown. Save the public IP, whether an IPv6 address is available, and the browser’s WebRTC result as separate baseline fields.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches- Turn off the VPN in its app, not merely by closing the window. Confirm the app reports that the tunnel is disconnected.
- Check for another VPN, proxy, iCloud Private Relay or custom DNS service that remains active, and note it in your log.
- Open the DNS test and run the standard test; repeat with the extended option if available.
- Record resolver names, resolver IP addresses and the country or network label shown by the test.
- Record the public IPv4 address, IPv6 availability and address, and the WebRTC-discovered address or status.
Do not treat the disconnected result as a failure. It is your reference for what the ISP, router or another configured resolver normally does on that network.
How do I run the same test with the VPN connected?
Connect to the VPN, wait until the client shows a stable tunnel, and repeat the same checks without changing the device, browser or network. If the provider recommends an extended DNS test, run it; Proton VPN’s support instructions direct users to DNSLeakTest.com and describe standard and extended modes.
- Choose the VPN server or location you normally use and note its name.
- Wait for the connection indicator to settle. Do not begin while the app is still negotiating or reconnecting.
- Run the same DNS test mode used for the baseline, then repeat in extended mode when that is part of your provider’s instructions.
- Record every resolver and its organization, then capture public IP, IPv6 and WebRTC results independently.
- Keep screenshots or copied results with the time and server so you can compare after a configuration change.
A new public IP demonstrates that ordinary traffic is exiting elsewhere; it does not prove that DNS requests, IPv6 packets or WebRTC candidates followed the tunnel.
Rank #2
How do I interpret the results without false positives?
Compare the VPN-off and VPN-on records one signal at a time. The following matrix keeps the evidence separate.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Signal | VPN-off baseline | VPN-on observation | What it means |
|---|---|---|---|
| DNS resolver identity | ISP, router, corporate or configured resolver | Provider-operated or documented third-party resolver | Expected when it matches the provider’s stated design; an ISP resolver on the connected run merits investigation. |
| Public IP | Your normal ISP address | VPN exit address | Shows the apparent source of ordinary traffic, not DNS or IPv6 protection. |
| IPv6 | Available or unavailable, with address and route | Provider-tunneled, intentionally disabled, or still exposed | Behavior depends on client, operating system and server; verify the provider’s platform-specific documentation. |
| WebRTC | Browser candidates visible or blocked | VPN or local candidates visible | Browser behavior is separate from DNS and can expose a route the DNS page does not test. |
A resolver branded Google, Cloudflare or another public service is not proof of a leak. The decisive questions are whether it appeared only after the VPN connected, whether it belongs to the VPN’s documented infrastructure, and whether the provider says that third-party resolution is intentional. Conversely, a provider-looking resolver is not proof by itself if the provider has not documented that address range.
What counts as a strong warning?
- The VPN-connected test lists the same ISP resolver seen when the VPN is off, while the provider says DNS should go through its servers.
- The resolver list changes back to the ISP during a reconnect, sleep/wake event or network transition.
- IPv6 remains active on the physical interface even though the client does not document IPv6 tunneling or blocking.
- WebRTC exposes a local or ISP address that your threat model requires you to hide.
- A split-tunneled application produces a different result from traffic routed through the VPN.
These are investigation triggers, not universal proof that every application is leaking. A browser test covers that browser and its current connection state only.
How can I test IPv6, WebRTC and the public IP separately?
Run each check as its own experiment and label the network state. AMTSO’s guidance treats DNS, IP, IPv6 and WebRTC as distinct evidence axes and recommends checking behavior during network changes and split tunneling.
Public IP
With the VPN off, record the address and approximate network or country reported by an IP-check page. With the VPN on, confirm that the address changes to the selected VPN exit. If it does not change, the client may not be connected, the tested application may be excluded by split tunneling, or another routing layer may be taking precedence.
IPv6
Record whether the device has an IPv6 address before connecting. Repeat after connection and check both the address and route, not merely whether a page displays an IPv4 address. IPv6 support differs by platform and server; Proton VPN’s IPv6 documentation describes those differences and the leak-protection behavior it supports. Do not apply one operating-system switch as a universal fix without checking how your client handles IPv6.
WebRTC
Run a WebRTC leak check in the same browser used for the DNS test. Note every candidate address and whether it is labeled local, public or VPN-related. A clean WebRTC result does not validate DNS, and a DNS pass does not prevent a browser from exposing a WebRTC candidate.
What network changes should I test?
A VPN that looks clean on a stable Wi-Fi connection can behave differently when an interface changes. AMTSO’s guidance states: “When connected to a VPN server and while the device is switching Wi‑Fi access points no data packets should exit the device unencrypted (via any other network interface except the VPN interface).” Test the transitions that match how you actually use the device.
Wi-Fi access-point changes
- Connect the VPN on one Wi-Fi network and run the DNS, IP, IPv6 and WebRTC checks.
- Move to a second access point or force a handoff while the VPN remains enabled.
- Wait for the client to report a stable connection, then repeat every check.
- Look for a brief ISP resolver, old public IP or exposed IPv6 address during reconnects; capture results immediately if the test page shows a history.
Wi-Fi-to-mobile transitions
On a phone or tablet, repeat the procedure while switching from Wi-Fi to cellular data and back. Some clients rebuild the tunnel, change servers or briefly suspend leak protection during the handoff. The relevant question is whether your client prevents traffic outside the VPN during that interval, not whether the steady-state page eventually looks clean.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteSleep, wake and captive portals
After the device wakes or signs into a new network, run the same checks again. A captive portal or authentication step may require temporary access outside the tunnel; document what the client does and whether the tunnel automatically re-establishes before you use sensitive applications.
How do split tunneling and kill switches change the result?
Split tunneling intentionally sends selected apps or destinations outside the VPN. A DNS result from an excluded browser, game or system service can therefore differ from a browser routed through the tunnel. Test one application inside the tunnel and one explicitly excluded application, and label both records.
A kill switch is designed to block traffic when the VPN drops, but implementations vary by platform and mode. Disconnect the tunnel deliberately only on a device where data loss is acceptable, then verify whether DNS queries and ordinary traffic stop or revert to the normal interface. Reconnect before continuing other work. Do not assume that an app-level kill switch covers system services or every IPv6 path.
Rank #4
What should I do if the test shows a possible DNS leak?
Work from the least disruptive checks to the most configuration-specific. Repeat the test after each change so you know which action altered the result.
Recommended Free Tools
- Confirm the connection state. Reopen the VPN client and verify that it reports an active tunnel to the intended server. A stale browser tab can show a result collected before the tunnel finished connecting.
- Remove competing routing layers. Temporarily disable another VPN, proxy or iCloud Private Relay, then rerun the baseline and connected tests. Record the original state so you can restore it.
- Review custom DNS settings. Check the operating system, browser secure-DNS option, router and VPN app for manually entered resolvers. A custom global DNS setting can override the provider’s normal path; the provider’s guidance identifies this as a potential escape route.
- Enable the client’s DNS protection. VPN applications use different labels and defaults. Follow the current platform-specific instructions in your client rather than copying a setting intended for another operating system.
- Inspect IPv6 controls. Determine whether the client tunnels IPv6, blocks it, or supports it only on particular servers. The IPv6 support documentation explains why the behavior can differ by platform and server.
- Check split-tunnel rules. Remove the tested browser or app from the exclusion list, reconnect, and compare again. If you need split tunneling, decide whether DNS for the excluded app is acceptable outside the VPN.
- Test the interruption path. With the kill switch enabled, briefly interrupt the connection and verify that traffic is blocked until the tunnel returns. If queries continue through the ISP, contact the client’s support team with timestamps and resolver addresses.
Do not “fix” a result solely by switching to a famous public DNS brand. That may change the resolver name without placing the lookup inside the VPN tunnel.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Can one browser test prove that every app is protected?
No. A browser test describes the browser, device state and connection path at the moment of the test. System resolvers, background applications, games, command-line tools and split-tunneled programs can use different APIs or interfaces.
For higher confidence, repeat the comparison in the applications that matter to you and after each relevant transition. Check the VPN client’s connection log if it provides one, and compare timestamps with the DNS test. Treat a clean browser page as evidence for that scenario, not as a certificate covering the entire device.
How should I keep a useful test record?
A short log makes intermittent leaks easier to identify and lets you verify a change later. Include:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →- Date and time, device, operating system and browser version.
- Network type and access point, including whether the run followed a Wi-Fi or cellular transition.
- VPN server, protocol if shown, split-tunnel rules, kill-switch state and DNS-protection setting.
- Every resolver name and IP, public IP, IPv6 result and WebRTC result.
- Whether another VPN, proxy, iCloud Private Relay or custom DNS was active.
- The exact configuration change made before the next run.
Keep the VPN-off and VPN-on records side by side. The important comparison is not a single “safe” badge but whether each observed route matches the behavior your provider documents for that client and server.
When should I retest?
Retest after changing VPN servers, enabling split tunneling, editing DNS settings, updating the VPN client or operating system, and switching between networks. Also retest after a VPN interruption, sleep/wake cycle or a change in IPv6 availability. Features and defaults can change, so a result from one date is not a permanent guarantee.
For routine use, run a quick DNS and public-IP check after a major configuration change and perform the full IPv6 and WebRTC set when your threat model includes those paths. If the provider changes its documented DNS or IPv6 design, use that documentation as the new expected reference.
Frequently Asked Questions
Can a VPN use a third-party DNS resolver without leaking?
Yes. A VPN may intentionally forward lookups to a public resolver or operate DNS on infrastructure whose address differs from the VPN exit. Treat it as expected only when the provider documents that design and the resolver appears consistently while the tunnel is active.
Why do DNS leak tests sometimes list several resolver locations?
Resolvers can be distributed across multiple servers or data centers, so one extended test may display more than one address. Compare the organizations and locations with the provider’s documented network rather than assuming that every additional entry is an exposure.
Should I test a VPN while connected to both Wi-Fi and cellular data?
If you move between those networks, yes. A tunnel can renegotiate during the handoff, so run the same checks after Wi-Fi-to-cellular and cellular-to-Wi-Fi transitions instead of relying only on a stationary result.
Does changing my computer’s DNS server fix a VPN leak?
Not necessarily. A manually selected resolver can still be reached outside the tunnel, and a custom global setting is itself a possible cause of escaped queries. First establish how the VPN client routes DNS, then remove or align custom settings and retest.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
