You hit Connect on your VPN app. The icon goes green, the status reads "Connected — London", and you load a site that shows your IP. The address it reports back is still your real one. Or — slightly worse — it's the VPN's address, but a second tool on the same page reveals your real IP anyway.
Both outcomes are common, and they have different causes. A VPN's job description sounds simple: "hide my IP". The reality is that there are at least four separate channels through which your real address can leak even when the tunnel itself is up and encrypting traffic correctly. This is the field guide to all of them.
What "VPN connected" actually means
A connected VPN means one specific thing: the client app has established an encrypted tunnel to the VPN provider's server. Bytes that go into the tunnel come out at the provider's exit, with the provider's IP as the source address. So far so good.
What "connected" does not mean is that all of your traffic is going through the tunnel. The operating system has a routing table. The VPN client tries to install rules that send everything through the tunnel. Whether those rules cover everything is configuration-dependent. Split tunneling, per-app rules, IPv6 settings, DNS resolver configuration — each is a separate decision the VPN client has to get right.
The four leaks below are the four ways those decisions go wrong.
Leak 1 — DNS
When you type a domain name into the address bar, the OS has to resolve it to an IP address. That lookup goes to whichever DNS resolver the OS is configured to use. If the VPN client doesn't push its own DNS settings, the lookup goes to whoever the OS was using before — usually the local ISP.
From the ISP's perspective, the encrypted VPN tunnel is a black box. They can't see what's inside it. But the DNS queries are a separate conversation that happens outside the tunnel, and those queries reveal every domain you visit. The ISP also sees them coming from your real IP, so they can tie the activity to your account.
The symptom: the VPN reports as connected, websites see the VPN's IP, but your ISP's logs (or a DNS leak test) show queries coming from your real address. The fix is to configure the VPN client to push its own resolvers — most reputable providers run their own — or to set the OS-level DNS to a service unrelated to the ISP (Cloudflare's 1.1.1.1, Google's 8.8.8.8, Quad9's 9.9.9.9).
Leak 2 — WebRTC
WebRTC is the browser API that powers video calls running inside a tab (Meet, browser-Zoom, Discord). To establish a peer-to-peer connection, it needs to know all of the addresses the local machine has. It learns those by asking a STUN server.
The catch is that this discovery happens at the OS level, not the browser's HTTP stack. The VPN tunnel routes HTTP traffic through the exit, but WebRTC's STUN request goes through whichever interface the OS thinks is appropriate — and the answer often includes the machine's real local LAN address and, in some cases, the real public IP behind it.
Browsers have been hardening this since 2019. Chrome applies a policy called mDNS hostnames that replaces raw IPs with anonymised tokens for most pages. Firefox added similar mitigations. But it's not uniformly fixed: a page can still request "all host candidates" with permission, certain VPN apps disable the protections, and older browsers expose the addresses by default.
The browser diagnostic on this site enumerates the WebRTC IPs your browser is willing to surface. If your real LAN address shows up with the VPN on, that's the leak.
The fix: in Chrome and Firefox, disable WebRTC IP handling for the default network interface, or install an extension that does. Some VPN apps have a "prevent WebRTC leaks" toggle that handles this automatically.
Leak 3 — IPv6 bypass
Plenty of VPN clients still only tunnel IPv4. They install routing rules for the v4 internet, leave the v6 stack alone, and hope nobody notices.
On a dual-stack connection (most modern home and mobile networks), that's a problem. The OS prefers IPv6 when it's available. So a request to a dual-stack server goes out over the unencrypted IPv6 link, bypassing the VPN entirely, while the VPN log shows zero traffic. The server sees your real IPv6 address.
The symptom: visit an IPv4-only test site and you see the VPN's address. Visit an IPv6-capable site and you see your real one. The what-is-my-ip page shows both stacks separately so you can spot the mismatch at a glance.
The fix: disable IPv6 on the OS while the VPN is running, or switch to a VPN provider that handles both stacks. Disabling v6 is the safer fallback if the provider isn't trustworthy; some clients do it automatically.
Leak 4 — VPN silently disconnected
The VPN tunnel drops. The client tries to reconnect. Meanwhile, your traffic keeps flowing — but now over the regular interface, with your real IP as the source. By the time you notice the icon has changed colour, minutes' worth of traffic has gone out unencrypted.
The defence is called a kill switch or network lock: the client installs firewall rules that block all non-VPN traffic when the tunnel is down, and removes them only after reconnection. With it off, the VPN "fails open" — the kindest outcome is that the page loads with your real IP visible to the server. With it on, the VPN "fails closed" — the page doesn't load at all until the tunnel is back, which is the safer default for most use cases.
The setting is almost always optional. Almost as often, it's off by default.
How to check, step by step
- Open what-is-my-ip with the VPN on. The IP shown should be the VPN's, not yours. If both IPv4 and IPv6 are listed, both should be the VPN's.
- Open browser diagnostic on the same connection. Look for WebRTC entries. If your real LAN IP or real public IP appears there, WebRTC is leaking.
- Run a DNS leak test (most VPN providers operate one, or use a third-party site). If the queries are answered by your ISP, fix the DNS configuration.
- Turn the VPN off and reload each page. The addresses should all change. If any of them stayed the same with the VPN on, that's a leak.
- If your VPN client has a kill-switch or fail-closed setting, enable it.
Practical takeaways
- Enable the kill-switch / fail-closed setting in your VPN client. The default is usually off and shouldn't be.
- Test with this site's tools after every VPN config change. A change that looks cosmetic can re-enable a leak you'd previously fixed.
- If you genuinely need anonymity (not just geo-shifting), use Tor. VPNs are designed to defeat casual ISP-level snooping, not a determined adversary who can correlate the VPN provider's logs.
Related reading
The what-your-IP-reveals guide covers what someone learns from seeing your address — useful background for understanding what a leak actually exposes. The public-vs-private-IP guide explains the local vs public address distinction that WebRTC discovery exploits. The what-is-my-ip and browser diagnostic tools are the two checks to run before trusting a VPN configuration.