A VPN app can say “connected” while a browser uses your regular DNS resolver, reaches a site over an unprotected IPv6 connection, or exposes your home IP through WebRTC. These are different failures, so one green check mark on a test site isn’t enough.
A useful VPN leak test starts with a comparison: record what your connection reveals before you turn on the VPN, then run the same checks while connected. Look for your actual public IP address or internet provider in the results—not just a location that seems wrong. VPN servers and their DNS resolvers don’t always share the same address or company name.
Set a baseline before testing
Disconnect the VPN and open an IP-check page, such as Mullvad’s connection check. Record the results you can see. These are your baseline results; keep them private rather than posting screenshots of them.
Connect the VPN, then refresh the page. The public address should change to one associated with the VPN connection. If the ordinary IP check still shows your baseline address, solve that problem first: the browser may be excluded by split tunneling, the VPN may be disconnected, or you may be using a browser-only extension in a different browser. A browser extension protects traffic within its configured browser, not necessarily other apps on the device.
Run the tests below in the browser you actually use. If you switch between browsers, test each one. For a clearer DNS comparison, temporarily connect to a VPN server in a different region from your home connection.
Check where your DNS requests go
DNS turns a site name into an address your device can connect to. A DNS leak occurs when lookups you expected to send through the VPN instead go to a resolver outside that arrangement—often one supplied by your internet provider. A test can identify the resolver handling its queries, but its results don’t, by themselves, show the entire route those queries took.
While connected to the VPN:
- Open DNSLeakTest and confirm that the public IP at the top is the VPN address, not your baseline address.
- Run the standard test. Use the extended test if you want to check more lookups.
- Compare the listed resolver addresses and organizations with your baseline results and your VPN provider’s DNS setup.
If your home ISP’s resolver appears, that’s a strong sign that DNS isn’t following the protection you intended. If the result shows your VPN provider or an infrastructure company it uses, the unfamiliar name alone isn’t a leak. Some VPNs use third-party data centers, so the DNS organization needn’t match the name on your subscription.
A public DNS service such as Cloudflare or Google needs a closer look. Your browser may be set to use DNS over HTTPS, or your device may have a custom DNS setting. That can send lookups to a resolver other than the VPN’s, but the resolver name alone does not prove the requests traveled outside the VPN tunnel. It does tell you that this resolver can handle those lookups instead of the VPN’s intended resolver.
If the DNS result looks wrong
Start in the VPN app: check that DNS leak protection is enabled, then disconnect and reconnect. If you’ve entered a custom DNS server in the app, remove it temporarily and test again. Next, check the browser’s DNS over HTTPS or “Secure DNS” setting and any DNS-changing extension. Firefox, Chrome, and Edge can use browser DNS settings that differ from the VPN’s; turning that setting off for a retest can isolate the cause.
Also check system-level custom DNS settings, including Android Private DNS if you’ve configured a provider there. Don’t change several settings at once. Make one change, reconnect, and rerun the test so you know what fixed it.
Test IPv6 separately from IPv4
A VPN can hide your IPv4 address yet let an IPv6 connection use your regular network. To check, first visit test-ipv6.com with the VPN off and note whether your connection has working IPv6 and which provider appears. Then connect the VPN and run the test again. The site tests IPv4 and IPv6 access separately and attempts to identify the provider used for each.
Three results are especially useful:
- No IPv6 with the VPN on: This is not automatically a leak. Your VPN may block IPv6 while protecting IPv4 traffic.
- An IPv6 address or provider associated with the VPN: IPv6 may be routed through the tunnel. Check the VPN app’s connection details if it provides them.
- Your baseline IPv6 address or home ISP, alongside a VPN IPv4 address: Treat this as a likely IPv6 leak. Your two address types appear to be taking different paths.
A “no IPv6” result also has limits: if you had no working IPv6 before connecting, this test cannot tell you how the VPN would behave on a network that offers it. Test again on an IPv6-capable connection if that matters to you.
The right fix depends on the VPN. Some providers tunnel IPv6; others block it. Some support it only on particular apps or servers. Proton VPN’s IPv6 guidance, for example, distinguishes between client, server, and platform support—so don’t assume a setting on one device applies to another. Look for an IPv6 support or leak-protection setting in your own VPN app, reconnect after changing it, and retest.
Avoid making “disable IPv6 everywhere” your first fix. Microsoft advises against disabling IPv6 components in Windows because some components may not function as expected. If your VPN cannot tunnel or reliably block IPv6, ask its support team for a supported fix or use a VPN that handles your connection correctly.
Check what WebRTC reveals to websites
WebRTC helps browsers set up real-time connections, including video calls. To find a workable connection, it can gather network addresses that a normal webpage request wouldn’t expose. The WebRTC IP-address standard specifically identifies the risk that a browser using a VPN or split tunnel could reveal both the VPN’s public address and the ISP’s public address.
With the VPN connected, open the BrowserLeaks WebRTC test. Compare its “Your Remote IP” result with “Your WebRTC IP,” especially the public IP field, and with the baseline you saved earlier.
If the WebRTC public IP matches the VPN address—or no public WebRTC address is reported—the test has not found your baseline public IP. If it shows your home ISP address, treat that as a leak even if the ordinary remote-IP field shows the VPN. A local address such as 192.168.x.x or 10.x.x.x is different: it describes a private network address, not your public home IP. It may still reveal information about your local setup, but it isn’t proof that your public traffic bypassed the VPN.
If WebRTC shows your real public IP
First, check split tunneling and make sure the browser isn’t excluded from the VPN. If you’re using only a browser extension, test with the provider’s full-device VPN app where possible; an extension and an operating-system VPN do not cover the same traffic.
Then look for a WebRTC leak-protection or IP-handling control in the VPN app or browser. Retest after each change. On desktop Firefox, a stronger option is to set media.peerconnection.enabled to false in about:config, as described in Mullvad’s WebRTC instructions. That disables WebRTC rather than merely changing which addresses it exposes, so browser-based calls and other WebRTC features may stop working. Use it if that trade-off suits you, and test again if you later turn it back on.
Retest after a reconnect—and know what the tests miss
A clean result on a stable connection is a useful snapshot, not a permanent guarantee. Repeat the IP, DNS, IPv6, and WebRTC checks after changing VPN protocols or servers, updating the app, or changing networks. Reconnecting after sleep is another sensible time to check if leaks are a particular concern.
Enable the VPN’s kill switch if it offers one. On Android, the system’s “Block connections without VPN” setting can block network traffic that would otherwise use a non-VPN connection when the configured VPN isn’t available. Check that the option is available for your VPN and that you’re comfortable losing connectivity until it reconnects.
Finally, remember the scope of these tests. They show what the test sites can observe from the browser at the moment you run them. They don’t audit every app, prove that all traffic stayed inside the tunnel, or tell you what a VPN provider does with traffic after it reaches its servers. For this check, the practical pass is narrower and clear: while the VPN is connected, none of the tests should reveal the public address or ISP you recorded before connecting.