VPN Leak Testing Guide: IP, DNS, WebRTC and Kill Switch

A VPN leak test checks whether your public IP address or DNS activity is escaping the protection you expected. A connected badge is useful, but it does not show which route every app, browser or protocol is using.

This VPN leak testing guide keeps the checks separate: public IPv4 and IPv6, DNS resolvers, browser WebRTC and the kill switch. Record a baseline, compare the connected result, then investigate the actual address or route that changed. A location label or a green result alone cannot certify the whole device.

How to run a VPN leak test

1. Close sensitive browsing and pause uploads before testing. Use your own unmanaged device; do not alter an employer’s VPN or network policy.
2. With the VPN disconnected, record the public IPv4 address, any public IPv6 address and the DNS resolver names shown by a reputable checker. Keep these results private.
3. Connect the official VPN app to the server you intend to use. Note the device, operating system, app version, protocol and whether split tunnelling is enabled.
4. Reload the checker rather than reading the previous result. Compare exact public addresses and network owners with the baseline.
5. Run a dedicated DNS check and a WebRTC check in each browser you use. Repeat on a second device or browser only when you need to investigate a difference.
6. Retest after changing networks, server, protocol, VPN or browser settings. Wi-Fi and mobile data can produce different results.

A browser extension may protect only supported browser traffic. A full VPN app is the appropriate starting point when you want device traffic routed through a tunnel. Split tunnelling can intentionally exclude selected apps or destinations; that exception must match your expectations. Our VPN setup guide explains the initial configuration.

Read the result before calling it a leak

Check	Result worth investigating	Important distinction
Public IP	Your baseline ISP public address remains visible while the tested traffic should use the VPN.	A different city label is not proof of a leak; compare addresses and network ownership.
DNS	The checker reports an ISP resolver or another resolver you did not intend to use.	A third-party resolver name alone does not reveal the path the request took.
WebRTC	The browser exposes a baseline public ISP address outside the expected VPN route.	A private LAN address or a local .local identifier is different from an exposed public ISP address.
IPv6	A baseline public IPv6 address remains reachable outside the expected tunnel.	No IPv6 connectivity can be an intentional VPN block rather than a failed VPN.

Public IPv4 and IPv6: compare the actual address

Start with the public address seen by the checker. If it matches the baseline ISP address when the browser is supposed to be tunnelled, check split-tunnel exclusions and whether the VPN app has actually finished connecting. An IP owned by a data centre is compatible with a VPN exit, but it does not prove every app uses that exit.

Test IPv6 separately when your normal network provides it. A VPN may tunnel IPv6 or block it to prevent traffic using an unprotected route. The concerning case is an ISP public IPv6 address still exposed alongside a VPN IPv4 address. If your baseline has no IPv6, that connection cannot establish how the app behaves on another IPv6-enabled network.

DNS: resolver ownership and request routing differ

DNS translates a domain name into an address. A DNS checker identifies resolvers that answered its test queries; it does not capture every packet sent by the operating system. If an ISP resolver appears unexpectedly, review the VPN’s DNS configuration and provider guidance before calling the connection clean.

Browser DNS-over-HTTPS can use a separately selected encrypted resolver. Seeing Cloudflare or Google therefore needs interpretation: the browser may be using that resolver through the VPN, or an excluded route may be involved. The result still identifies an additional party handling DNS, but the name alone cannot establish an unencrypted ISP leak. Compare browser and system settings; avoid changing several settings at once.

WebRTC: public addresses are the key comparison

WebRTC supports browser calls and other real-time connections. It can discover addresses through multiple network interfaces, which matters when a VPN has split routes. Compare any public WebRTC address with your disconnected baseline and connected browser address. A private address such as 192.168.x.x describes a local network; it is not the same finding as exposing your ISP’s public address.

Modern browsers can mask local address candidates with mDNS names. A .local entry should not automatically be labelled a public IP leak. Do not disable WebRTC solely because a checker lists a local candidate: that can break calling tools. Investigate a genuinely unexpected public route and the browser’s supported privacy controls first.

Useful checkers and their limits

• Mullvad Connection Check: public connection, DNS and WebRTC checks. Its “using Mullvad” status identifies that provider; it is not a universal failure verdict for someone using another VPN.
• DNSLeakTest: compare standard or extended resolver results. More queries can reveal additional resolvers, but neither mode audits all device traffic.
• BrowserLeaks WebRTC Test: inspect the browser’s remote, local and public WebRTC address fields. A result applies to that browser and its current permissions/settings.
• Test-IPv6: check IPv6 reachability and network information. It is a connectivity diagnostic, not a blanket privacy or forensic certification.

Most checks need JavaScript and fresh requests. A blocked script, empty result or cached page is inconclusive. The checker receives connection information to perform its job; do not post result URLs or unredacted screenshots containing your public IP address on a public forum.

Test the kill switch as a separate behaviour

An IP check while the tunnel is stable says nothing about what happens when it fails. Read the kill-switch documentation for your exact app and platform. Some controls cover unexpected disconnection; an always-on or lockdown setting may also block internet access when you deliberately disconnect. Those are different promises.

1. Enable the documented protection and note any exclusions. Use a non-sensitive test page rather than an active payment, work upload or private conversation.
2. Use the provider’s supported interruption test. Observe whether new requests stop during the loss and resume only after the protected connection returns.
3. Check again after moving between Wi-Fi and mobile data or waking the device, where applicable. Record which transition you tested.
4. If behaviour differs from the documented setting, collect app/version details and contact support. A page continuing to display cached content does not demonstrate that new traffic escaped.

Do not treat pressing Disconnect as the only test of an unexpected tunnel failure. Likewise, disabling Wi-Fi proves little if the device has no alternative route available. Browser tests can miss brief or non-browser traffic; a repeatable unexpected address change needs further investigation.

Fix the cause, then repeat the same check

• Unexpected public IP: check the app’s connection status and split-tunnel rules. Confirm that the tested browser is included, reconnect and repeat the baseline comparison.
• Unexpected DNS: use the provider’s documented DNS setting; review browser Secure DNS and conflicting VPN/filter profiles. Retest after one controlled change.
• Unexpected IPv6: use documented IPv6 tunnelling or leak blocking. Do not disable IPv6 across every device as a default solution; follow the provider’s platform-specific guidance.
• Unexpected WebRTC public address: investigate browser privacy controls and split routes. Avoid an unverified extension that asks for broad access merely to hide a checker field.
• Failed interruption protection: verify that the kill switch is supported and enabled for the current client. Reinstalling or changing providers is a later decision, after checking configuration and support evidence.

An encrypted DNS setting is not a substitute for a VPN tunnel. A change of VPN protocol is also not a universal leak fix: routing, exclusions and platform controls still matter. Keep work-managed profiles intact and use our VPN troubleshooting guide for connection conflicts.

What a clean test can and cannot tell you

A clean result gives useful evidence for the tested browser, connection and moment. It does not prove a provider never logs data, every app is included, the kill switch works in all failures or the device is free of malware. Website logins, cookies and permitted location access can still identify you even when the public IP changes.

If you need to investigate a recurring issue, keep a private record of the baseline, connected result, network, browser, VPN version, protocol and the exact change that triggered it. Repeat the same check after the fix. That is more useful to support than a screenshot containing only a green badge. See what a VPN protects and where that protection ends.

Frequently asked questions

Sources

Technical sources checked 8 October 2026 UTC: IETF WebRTC IP-address handling requirements; DNSLeakTest’s DNS explanation; Mozilla DNS-over-HTTPS guidance; the checker documentation linked above.

Share this article

WhatsAppLinkedInRedditFacebookX