KovraA connected VPN icon means one thing: a tunnel was established. It does not mean every packet is using it. The four checks below take about five minutes and cover the ways traffic escapes an active tunnel — each one a documented way people have been identified while believing they were protected.
Before you start
Record your real values first, with the VPN off: your public IP address and the DNS resolvers your system uses. Every test below is a comparison against those two values, and without them you are guessing whether an unfamiliar address belongs to your provider or your ISP.
Test 1: the public IP
Connect the VPN and load any "what is my IP" service. Expected: the VPN server's address, and a location matching the server region.
- Still your real IP: the tunnel is not carrying browser traffic. Check split tunnelling and per-app rules first.
- Right IP, wrong country: harmless in itself — geolocation databases lag behind IP reassignments — but worth knowing if you are using the VPN for regional access.
- Use a private window. Cached pages produce a surprising share of false alarms.
Test 2: DNS
This is the leak that matters most, because it defeats the purpose of the tunnel without breaking anything visible. Run a DNS leak test with the VPN connected and read the list of resolvers that answered.
- Resolvers belong to your VPN provider or a neutral public resolver: correct.
- Resolvers belong to your ISP: leaking. Your ISP holds an ordered, timestamped list of every domain you visited.
- Mixed results: also leaking. One query out of ten is enough to build the same list, more slowly.
Common causes: a client that does not force DNS through the tunnel, a manually configured resolver left over from a previous setup, Windows' parallel query behaviour across interfaces, or a router that intercepts port 53 regardless of client settings. Fix by enabling the client's "use provider DNS" or "block DNS outside tunnel" option, then re-testing.
Test 3: IPv6
Many networks now provide IPv6 by default while some VPN configurations tunnel only IPv4. The result is quietly severe: any site reachable over IPv6 gets your real, globally routable address — which, unlike a shared IPv4 address, often identifies a single device.
- Load an IPv6 test page with the VPN connected.
- "No IPv6 detected": good. Either your network has none, or the client is blocking it correctly.
- An address is shown: compare it against your pre-test value. If it matches, that is a full leak.
Fix by enabling IPv6 support in the client if the provider offers it, turning on "block IPv6", or disabling IPv6 on the network adapter as a last resort.
Test 4: WebRTC
WebRTC lets browsers open direct peer connections for calls and screen sharing, and to do that it asks the operating system for candidate addresses. Historically this exposed the local and sometimes the public IP to any page that asked, without a permission prompt. Modern browsers have narrowed it, but the API is still worth checking.
- Run a WebRTC leak test with the VPN connected.
- Private addresses such as
192.168.x.xare not a privacy problem on their own. - Your real public IP appearing there is the leak.
Fix by disabling WebRTC where the browser allows it, using an extension that restricts candidate gathering, or switching browsers for sensitive sessions.
Test 5: the kill switch
The one nobody runs, and the one that matters during real use. Start a continuous download or a ping, then forcibly stop the VPN — quit the client, or disable the network adapter it uses. Correct behaviour: all traffic stops immediately. Incorrect: the transfer continues, which means it continued from your real address.
This is decisive for peer-to-peer traffic, where a two-second reconnect is enough for the swarm to record your address.
Reading the results
| Symptom | Likely cause | Fix |
|---|---|---|
| Real IP visible in browser | Split tunnelling or cached page | Private window; check per-app rules |
| ISP resolvers answering | DNS not forced through tunnel | Enable provider DNS / block outside DNS |
| IPv6 address matches pre-test value | IPv4-only tunnel | Enable IPv6 in client or block it |
| Public IP in WebRTC results | Browser candidate gathering | Restrict or disable WebRTC |
| Traffic continues after tunnel drops | Kill switch off or ineffective | Enable it, then retest |
What a clean test does not prove
It proves your traffic is leaving through the tunnel. It says nothing about what the provider does with it at the other end — that is a separate question with its own method, in verifying no-logs claims. It also says nothing about identity: logged-in accounts, cookies and browser fingerprints survive any tunnel, as covered in the anonymity guide. And on networks that block VPNs outright, a passing leak test on a connection that keeps dropping is not much comfort — that is a protocol problem, discussed in the protocol comparison.
Run it after every change
Client updates reset options. Operating system updates re-enable IPv6. New servers behave differently. Five minutes after any change is the difference between a VPN that works and a VPN that appears to.