Connecting to a VPN changes the route your traffic takes, but it does not guarantee that every application, name lookup, or browser feature uses the encrypted tunnel. A device may send DNS requests to a local resolver, prefer an IPv6 path outside the VPN, or expose local network candidates through WebRTC. In these cases, a public IP checker can show the expected VPN address while another test still reveals useful network information.
This guide provides a practical privacy leak check for Windows, macOS, Android, iOS, and Linux. It also applies when you use a compatible client such as Clash Verge, sing-box, or Shadowrocket. The objective is not to promise perfect anonymity. Instead, the goal is to identify which traffic is outside the tunnel, correct the setting responsible, and repeat the test from a clean starting point.
What can leak outside a VPN
A VPN normally creates an encrypted connection between the device and a remote VPN endpoint. Depending on the protocol and client, the system then sends selected or all traffic through a virtual interface. The exact behavior depends on routing rules, DNS configuration, application proxy support, and whether IPv4 and IPv6 are handled consistently.
DNS
Name-resolution path
IPv6
Alternate address family
WebRTC
Browser candidate exposure
Kill switch
Disconnect protection
DNS request exposure
When you enter a domain name, an application must translate it into an address before connecting. If the VPN client does not provide DNS handling, the operating system may continue using the resolver supplied by the local router or internet provider. The website itself may see the VPN exit address, while the resolver can still observe the domains being requested.
DNS exposure can also happen when a browser uses its own encrypted DNS feature. DoH or DoT may protect a query from the local network, but it can still bypass the VPN’s intended DNS policy if the browser connects directly to a resolver. Encrypted does not always mean routed through the VPN; route and resolver ownership must be checked separately.
IPv6 routing exposure
Many leak reports focus on IPv4 because it is commonly displayed by basic IP-checking pages. However, a device can have both IPv4 and IPv6 connectivity. If the VPN tunnel carries only IPv4 and the operating system keeps a native IPv6 route, applications may prefer IPv6 and reach a destination outside the tunnel. The result can be an IPv6 address associated with the local connection even though the IPv4 result looks correct.
WebRTC candidate exposure
WebRTC allows browsers to establish real-time audio, video, and data connections. During connection setup, the browser gathers network candidates so that peers can discover a workable path. Depending on browser behavior and permissions, a page may learn local interface information, private addresses, or a public server-reflexive address. A WebRTC result is not identical to a DNS leak, and it does not necessarily mean that ordinary page requests bypass the VPN, but it can reveal more network detail than expected.
Prepare a clean baseline before testing
Leak tests are easy to misread when several network tools are active at once. Start by closing other VPN clients, system-wide proxies, traffic accelerators, virtual machines, and applications that create their own tunnels. If a browser extension provides proxy routing, temporarily disable it so that the browser’s result can be related to the operating system’s actual route.
Record the network state before connecting. Note whether the device is using Wi-Fi, wired Ethernet, or mobile data; whether IPv6 is enabled; and whether the browser has custom DNS settings. You do not need to publish this information. It simply helps explain why a result changes after a setting is adjusted.
- ✅ Use one VPN client or one compatible proxy client at a time.
- ✅ Close sensitive tabs before changing network settings.
- ✅ Test both before and after the VPN connection.
- ✅ Repeat tests after changing from Wi-Fi to mobile data or another network.
- ❌ Do not treat a single green result as proof that every application is covered.
- ❌ Do not install unknown “leak test” applications that request unnecessary permissions.
For a meaningful comparison, use the same browser profile and the same test sequence. A browser may cache DNS results, retain an old WebRTC permission, or keep a connection open between tests. Clear the page, close the tab, and reopen it after the VPN connection is established. If a test page offers multiple checks, record the categories rather than focusing only on the headline result.
Run the leak check step by step
The following order separates the main exposure surfaces. Perform the steps after the VPN reports that it is connected, then repeat them after briefly disconnecting so you can compare the expected change. Do not use private credentials or sensitive accounts during testing; an ordinary public test page is sufficient.
Step one: check the public exit address
Open a reputable public IP checker and note the displayed IPv4 and IPv6 results, if both are shown. The result should correspond to the VPN exit rather than the local connection. Location labels are approximate and can be wrong, so concentrate on the address, autonomous system information, and whether the result changes when you connect or disconnect.
If the address never changes, the client may be connected only for selected applications, the browser may be outside the proxy rules, or the VPN connection may have failed despite showing a connected state. A manual proxy configuration can create a similar result: the browser may use the proxy while other applications use the normal route, or the reverse.
Step two: check DNS resolvers
Use a DNS leak test that lists the resolvers responding to the browser’s queries. Compare the resolver organization and general region with the expected VPN configuration. A local resolver appearing in the result is a warning sign, but a foreign or unfamiliar resolver is not automatically a leak; some VPN services operate their own resolvers or use a third-party provider.
Run both a standard lookup and an extended lookup if the test offers them. Modern browsers and operating systems can cache answers, distribute queries across resolvers, or use encrypted DNS. If the result is inconsistent, restart the browser, reconnect the VPN, and test again. Then inspect the client’s DNS mode instead of repeatedly refreshing the same page.
Step three: check IPv6 separately
Choose a test page that explicitly reports IPv4 and IPv6. If IPv6 appears when the VPN documentation or client configuration does not support IPv6 tunneling, treat that as an incomplete route rather than assuming the connection is safe. On Windows, inspect the active adapter and route information with the built-in network tools. On macOS and Linux, review the active interfaces and routes using the system’s network settings or terminal utilities.
There are two sensible fixes. The first is to use a VPN configuration that supports IPv6 through the tunnel and provides a clear policy for IPv6 DNS. The second is to disable IPv6 on the relevant adapter when you do not need it and the VPN does not handle it. Disabling IPv6 is a device-level trade-off, not a universal recommendation; some networks and services depend on it. Apply the change deliberately and test again.
Step four: check WebRTC
Open a browser-based WebRTC test and inspect the listed candidates. The exact labels differ between browsers and test pages. A private address may describe a local interface rather than your public identity, while a public candidate can reveal the route used for peer discovery. The key question is whether the browser exposes a local or non-VPN public candidate that your privacy model does not accept.
Browser controls vary. Some browsers provide WebRTC privacy options, while others rely on extensions or enterprise policies. A browser extension may reduce candidate exposure but can also change how calls, screen sharing, or real-time applications work. On mobile platforms, browser behavior may be limited by the operating system, so do not assume that a desktop setting exists on Android or iOS.
| Check | What a concerning result may indicate | Practical response |
|---|---|---|
| Public IP | The browser or application is using the ordinary network route | Review client mode, proxy rules, and tunnel status |
| DNS | Queries are sent to a local or unintended resolver | Review VPN DNS mode, browser DoH, and system resolver settings |
| IPv6 | IPv6 traffic has no matching VPN route | Enable tunneled IPv6 or disable it where appropriate |
| WebRTC | The browser exposes candidates outside the expected privacy boundary | Adjust browser controls and retest real-time features |
Fix DNS and routing settings
After identifying a leak, change one setting at a time. This makes it possible to identify the effective fix and prevents a temporary improvement from being confused with a complete solution. Begin inside the VPN client because its DNS and routing options usually take priority while the tunnel is active.
VPN and compatible client settings
Look for settings named DNS protection, private DNS, prevent DNS leaks, full tunnel, global mode, route all traffic, IPv6 handling, and kill switch. Names vary among official clients, Clash Verge, sing-box, and Shadowrocket. In rule-based clients, a rule may send browser traffic through the proxy while allowing DNS, system services, or selected applications to use a direct path. Read the mode and rule behavior together.
Protocol choice also matters. WireGuard, OpenVPN, IKEv2, Shadowsocks, VMess, Trojan, and Hysteria2 are not interchangeable implementations, and the client may handle DNS differently for each profile. Do not infer privacy behavior from a protocol name alone. Confirm whether the profile installs a system route, whether it configures DNS, and whether it has a fallback or direct rule.
On desktop systems, enable the kill switch when the client provides one. A kill switch should block traffic if the tunnel drops, but its scope varies. Some implementations cover all system traffic; others cover only applications routed through a particular interface. Test by connecting, confirming the tunnel, then temporarily stopping the VPN connection and checking whether ordinary browsing is blocked. Restore the connection immediately after this controlled test.
Browser and system settings
Check whether the browser has enabled secure DNS, proxy auto-configuration, or an extension that creates a separate route. Secure DNS can be useful, but decide whether the chosen resolver should be reached through the VPN or directly. If the browser’s resolver bypasses the client’s DNS policy, either configure the VPN and browser consistently or disable the browser override.
On Windows, inspect the DNS server assigned to the active adapter and review proxy settings in the operating system and browser. On macOS, compare the active network service’s DNS entries with the VPN client’s configuration. On Linux, check whether NetworkManager, systemd-resolved, a desktop environment, or the client itself controls DNS. Android may expose Private DNS as a system setting, while iOS applications can use platform-specific network extensions and may not expose the same controls as desktop software.
Do not change a router’s DNS settings as the only fix when the device has its own resolver configuration. A router can advertise one resolver while a browser, application, or VPN profile uses another. Test the device that carries the sensitive traffic, then test other devices separately.
Verify the fix with real use
Repeat the public IP, DNS, IPv6, and WebRTC checks after each meaningful change. First reconnect the VPN, then reopen the browser, because an existing tab may preserve a resolver result or peer connection. If the client has separate profiles for different protocols, test the profile you actually use rather than assuming that one profile’s behavior applies to all of them.
Next, verify applications that matter to you. Open a normal website, start a video call if that is part of your routine, use a file transfer, and check an application that does not respect system proxy settings. A browser-only test cannot confirm coverage for every application. Conversely, a successful system route does not guarantee that a browser extension or WebRTC session follows the same path.
- ✅ Confirm the expected exit address for both IPv4 and IPv6.
- ✅ Confirm that DNS results no longer identify an unintended local resolver.
- ✅ Check WebRTC after browser permissions and extensions are settled.
- ✅ Test after sleep, wake, network changes, and VPN reconnection.
- ✅ Confirm that the kill switch blocks traffic during an intentional disconnect test.
- ❌ Do not assume that a clean browser test covers games, messaging apps, or background services.
A leak that appears only after changing networks may be caused by a route metric, captive portal, IPv6 advertisement, or delayed client reconnection. A leak that appears only after sleep may indicate that the operating system restored the physical interface before the VPN reapplied its rules. Document the condition, then report the reproducible sequence to the client provider instead of relying on a one-time workaround.
Common misreadings and privacy limits
Not every unfamiliar address is evidence of a privacy failure. A VPN may use multiple DNS resolvers, a content delivery network may show a nearby location, and a WebRTC page may label a private interface without exposing it to the public internet. Interpret the result according to the type of data shown, how it was obtained, and whether it belongs to the network you intended to hide.
A VPN also does not remove account identity, cookies, browser fingerprinting, application telemetry, or information you voluntarily submit to a website. If you sign in to a personal account, the service can associate activity with that account regardless of the network exit. Leak prevention reduces unintended network exposure; it is not a promise of complete anonymity.
Be cautious with security claims that use absolute language. “No leak” may refer only to the vendor’s own test conditions. A strong privacy practice explains the tunnel mode, DNS behavior, IPv6 policy, WebRTC limitations, and kill-switch scope. It also acknowledges that operating system updates, browser changes, client versions, and network environments can alter behavior.
FAQ: VPN privacy leak checks
My IP address changed, but the DNS test still shows my local provider. Is the VPN working?
The tunnel may be carrying web traffic while DNS continues to use the local resolver. Review the client’s DNS protection setting, system resolver, browser secure DNS option, and any direct DNS rule in a compatible client. Reconnect and repeat the test after closing the browser tab.
Should I disable IPv6 whenever I use a VPN?
Not automatically. Prefer a VPN profile that supports IPv6 through the tunnel and applies a clear DNS policy. If the VPN does not support IPv6 and the device has a native IPv6 route, disabling IPv6 on the relevant adapter can prevent an unintended path, but it may affect networks or applications that depend on IPv6.
Does a WebRTC candidate always mean that my VPN is leaking?
No. WebRTC can display local interface information or a public candidate used for peer discovery, and the meaning depends on the browser and test page. Treat an unexpected non-VPN public candidate as a reason to review browser controls, then test whether ordinary browsing and real-time applications still work as intended.
Are Android and iOS leak fixes the same as desktop fixes?
No. Mobile operating systems restrict system-wide network controls and may handle VPN extensions, Private DNS, background activity, and browser behavior differently. Use the official client or a compatible mobile client, review its routing and DNS options, and test the applications you actually use instead of copying desktop instructions blindly.