Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Original editorial illustration of a laptop on a desk at night, its screen showing a simple padlock over a world map, with one thin beam of light escaping sideways from behind the screen and landing on a small paper map on the desk, amber and teal grade

How to Test Your VPN for Leaks: DNS, WebRTC, IPv6 (15-Minute Check)

by

How to Test Your VPN for Leaks: DNS, WebRTC, IPv6 (15-Minute Check)

In brief

  • Run a 15-minute VPN leak test before your refund window closes: check IP, DNS, WebRTC, IPv6, torrent IP, and kill switch, with a fix for each failure.
  • Start with the VPN off and write down your real IP address, location, and DNS servers. Every later result is judged against that baseline, not against what you hope to see.
  • A leak is any result that shows your real location, your internet provider, or your real IP address while the VPN is connected. One failed check is enough to act on.
  • Most leaks have a one-setting fix: change the DNS setting, disable WebRTC, turn off IPv6, or switch protocols. If two or more checks fail after the fixes, use the refund window instead of troubleshooting further.

Baseline first: record the unprotected state

A leak test without a baseline proves nothing. Screenshots of a VPN server location look reassuring, but you cannot tell whether a result is leaked or correct unless you know what your connection looks like with the VPN off.

Disconnect the VPN completely, not just pause it. Open ipleak.net and write down four things: your IP address, the city and country it maps to, the name of your internet provider, and the DNS servers listed. Then open dnsleaktest.com and run the standard test, noting which provider owns the DNS servers shown. Finally, open browserleaks.com/webrtc and note whether any local or public IP address appears.

Close those tabs. Do not reuse them for the connected test: a stale tab can show cached results and hand you a false pass. Fresh tabs, fresh results. The whole baseline takes about three minutes, and it is the part most guides skip. Without it, you are comparing your VPN connection against a guess.

One more baseline note: run the test on the network you actually worry about. A VPN that passes at home can fail on a hotel or airport network, where captive portals and forced DNS behave differently. If public Wi-Fi is your reason for having a VPN, test on public Wi-Fi. Our guide to VPNs that will not connect on public Wi-Fi covers the captive-portal side of that problem.

The 15-minute protocol

Connect the VPN to the server you normally use, not a hand-picked fast one. Testing a server you never use tells you nothing about your daily setup. Then work through the six checks in order. The order matters: each check isolates a different path your traffic can escape through.

Minutes 0–2: IP and location. Open a fresh tab at ipleak.net. The IP address, city, and country should all match the VPN server, and the provider name should belong to the VPN company or its hosting provider, never your home internet provider. If you see your real city or your real provider, stop here: the VPN is not routing your traffic at all, and the remaining checks will only confirm it. Switch servers once, then switch protocols (see the fix table) before concluding the app is broken.

Minutes 2–5: DNS. DNS is the most common leak, and the most invisible. Your browser asks a DNS server to turn a domain name into an address, and if that request goes to your provider’s resolver instead of the VPN’s, your provider sees every site you visit even though your traffic is encrypted. Run the standard test at dnsleaktest.com, then the extended test. Every server listed should belong to the VPN provider or a privacy-focused resolver it names. If your home provider appears anywhere in the list, you have a DNS leak. Privacy Guides’ DNS overview explains why the resolver choice matters as much as the tunnel itself: whoever answers DNS queries learns your browsing destinations.

Minutes 5–8: WebRTC. WebRTC is the browser feature behind video calls, and it can reveal your real IP address even when the VPN is working correctly, because it gathers network addresses directly from your device. Open browserleaks.com/webrtc with the VPN connected. The page should show only the VPN server’s address, or nothing at all. If your real public IP or your local network address appears, you have a WebRTC leak. This one is browser-specific: a leak in one browser does not mean every browser leaks, so test the browser you actually use, and test it again after any fix.

Minutes 8–10: IPv6. Many VPNs still tunnel IPv4 only. If your connection and your provider both support IPv6, traffic can slip out over IPv6 while the IPv4 tunnel looks perfect. At ipleak.net, check whether an IPv6 address is shown and, if so, whether it belongs to the VPN or to your provider. No IPv6 address at all is a pass: it usually means your connection has no IPv6 route to leak through. A provider-owned IPv6 address is also a pass. Your real IPv6 address is a fail. This check is easy to skip because most people never think about IPv6, which is exactly why it still catches providers out.

Minutes 10–13: Torrent IP. If you use torrents, the torrent client is a separate leak path from the browser. A browser test that passes says nothing about what your torrent client announces. Use ipleak.net’s torrent detection: add the magnet link it generates to your torrent client, wait for the peer list to populate, and check which IP address the tracker sees. It must be the VPN server’s address. If your real IP appears, your torrent traffic is outside the tunnel, and binding the client to the VPN interface (see the fix table) is the fix, not a different server.

Minutes 13–15: Kill switch. The kill switch is the feature that decides what happens when the VPN connection drops, and describing it is not testing it. Our dedicated guide explains what a VPN kill switch does and how to test it, but the short version belongs here: with the VPN connected, confirm the kill switch is enabled in the app, then force a disconnect by switching servers, toggling airplane mode, or briefly dropping Wi-Fi. While the VPN is down, try loading a page. If anything loads, the kill switch failed or is not actually on. Reconnect, check the setting again, and repeat. A kill switch that only works in the app’s marketing page is not a kill switch.

How to read each result

Pass and fail are binary, and that is a feature. Do not grade leaks on a curve.

  • IP and location: pass if every field shows the VPN server. Fail if your real city, country, or provider appears.
  • DNS: pass if all resolvers belong to the VPN provider or its named resolver. Fail if your home provider appears, even once, even in the extended test only.
  • WebRTC: pass if only the VPN address shows, or nothing shows. Fail if your real public or local address appears.
  • IPv6: pass if no IPv6 address shows, or the address shown belongs to the VPN. Fail if your real IPv6 address shows.
  • Torrent IP: pass if the tracker sees only the VPN address. Fail if your real address appears.
  • Kill switch: pass if nothing loads while the VPN is down. Fail if any page, message, or torrent traffic gets through.

A single fail means the VPN is not protecting you the way you think it is. That does not automatically mean the provider is bad: some fails are settings, some are browser quirks, and some are the provider’s architecture. The fix table separates those cases.

Fix table: one fix per failure

Failure First fix If it still fails
Real IP or location shows Switch VPN servers, then switch protocols (WireGuard to OpenVPN or the reverse) Reinstall the app; if the leak follows the account across devices, the provider’s routing is at fault
DNS leak Turn on the VPN’s own DNS (sometimes called private DNS or DNS leak protection) in the app settings; disable any custom DNS you set on the device Set the device DNS to the VPN’s resolver manually, or switch providers: a VPN that cannot keep DNS inside the tunnel has a design problem
WebRTC leak Disable WebRTC in the browser, or install a WebRTC-control extension and set it to disable non-proxied UDP Use a browser with WebRTC disabled by default for sensitive sessions; do not rely on an extension you have not re-tested
IPv6 leak Disable IPv6 on the device, or enable the VPN’s IPv6 leak protection if it offers one Switch to a provider that tunnels IPv6 properly; disabling IPv6 is a workaround, not a fix, and it is an acceptable one
Torrent IP leak Bind the torrent client to the VPN network interface so it cannot send anything when the tunnel is down Use a client that supports interface binding; if yours does not, that is a reason to change clients
Kill switch fails Confirm the setting is actually on (system-wide, not app-level, where the app offers the choice) and re-test Switch providers: a kill switch is a safety feature, and a safety feature that fails its own test is not a feature

Two protocol notes belong here. First, protocol choice changes leak behavior: our VPN protocols comparison covers when OpenVPN’s TCP fallback or WireGuard’s speed matters, and a protocol switch is the cheapest fix to try before blaming the provider. Second, re-test after every fix, from a fresh tab. A fix you have not re-tested is a hope, not a result.

The mobile gaps most guides miss

Desktop guides assume a desktop, and mobile VPNs fail in different places. On phones, the biggest gap is the browser: mobile browsers vary widely in WebRTC handling, and some offer no way to disable it at all. Test the exact mobile browser you use, not the desktop version of the same brand.

The second mobile gap is the always-on setting. Both major mobile platforms offer an always-on VPN option and a block-connections-without-VPN option, and they are separate toggles on some devices. An app kill switch plus the system always-on setting together is the combination that actually holds during a drop; either one alone leaves a window. After enabling both, repeat the forced-disconnect test from the protocol above on mobile data, not just Wi-Fi: a phone that leaks during a Wi-Fi-to-mobile handover leaks exactly when you are moving through the world.

The third gap is split tunneling. If you exclude any app from the VPN, that app’s traffic is unprotected by design, and its DNS queries may also escape. Split tunneling is legitimate for banking apps that block VPNs, but every excluded app should be a deliberate choice you can list, not a default you forgot. If you are weighing a free VPN at all, read our free VPN safety guide first: the leak problem is worse there, because the business model, not just the settings, works against you.

When to refund instead of fixing

Troubleshooting has a stopping point, and the refund window sets it. If two or more checks still fail after you have applied the fix table, or if the kill switch fails twice, stop fixing and use the refund. A provider can have one rough edge; a provider that leaks on several paths at once has an architecture you cannot patch from the settings screen.

Before you refund, keep your evidence: the baseline screenshot, the failed results, and the fixes you tried. Support desks ask for them, and a clear report gets a faster answer than “it leaks.” And if you are still deciding whether a VPN is worth paying for at all, our two-minute check for whether your VPN is working is the lighter version of this protocol for a first pass.

One last discipline: re-run this protocol after every app update and every server change you rely on. VPN apps update silently, and an update can reset a DNS setting or change kill-switch behavior without telling you. Fifteen minutes, once a month, is the cheapest privacy habit a VPN user can have.

Sources

  • ipleak.net — IP, DNS, WebRTC, and torrent-IP leak testing (verified live 2026-10-29)
  • dnsleaktest.com — standard and extended DNS leak tests (verified live 2026-10-29)
  • browserleaks.com/webrtc — WebRTC leak testing (verified live 2026-10-29)
  • Privacy Guides, DNS overview — why resolver choice matters (verified live 2026-10-29)

Related reading: 50+ VPN Statistics for 2026: Usage, Market Size & Risks

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment