A user writes to support: \u201cThe VPN is connected, the icon is on, the app says Germany. Yet the site still shows my city and offers delivery to my address. Did you mix up the servers?\u201d<\/p>\n
No mix-up. The tunnel is one pipe, but your data can leak through several other paths, and three of them have nothing to do with the tunnel itself. For someone who paid for a VPN, that sounds ridiculous, but that is how it works. DNS, WebRTC and IPv6. Three holes through which your real address can escape even when the VPN appears to be working perfectly. Clicking \u201cconnect\u201d does not fix any of them. The good news: you can test everything in five minutes and fix it in ten.<\/p>\n
One disclosure first: I work for a VPN service, so take what I say with a grain of salt. Everything described here can be tested the same way on any service, including mine: if it leaks, you will see it with the same five tests.<\/p>\n
Opening a website is not one action but a chain of actions. First, the device asks DNS which address belongs to a name. Then it establishes a connection. Meanwhile, the browser makes its own requests that you did not ask for and probably do not even know about. On top of that, a system often has two independent address stacks, IPv4 and IPv6, each with its own routing and its own idea of where traffic should go. A VPN handles only the second step: it takes packets and puts them into a tunnel. DNS requests, browser-initiated traffic and the entire IPv6 stack can still take another route. That is the answer to \u201cwhy can my IP be seen while the VPN is on?\u201d More precisely, it is not necessarily because the VPN is bad, but because something outside what the VPN protects is leaking.<\/p>\n
The analogy is crude but useful, and I have been using it for years: you leave home wearing a mask and dark glasses, but before leaving you loudly ask the concierge for directions, leave a note with your phone number on the door, and exit through a second entrance you forgot about. The mask is still on. It does not help much.<\/p>\n
By the way, there is a separate guide<\/a> on what can be learned from an IP address alone.<\/p>\n [Image: a diagram of three leaks in one illustration \u2014 a DNS request goes to the ISP, WebRTC exposes the address directly to the site, and IPv6 traffic bypasses the tunnel]<\/em><\/p>\n The most common one and, in my opinion, the most underestimated.<\/p>\n DNS is the internet\u2019s phone book. Before connecting to a website, the device asks a DNS server which address belongs to a given name. This is where things get interesting. When the VPN is configured correctly, the request goes inside the tunnel \u2014 to the VPN provider\u2019s resolver or to a third-party resolver reached through the encrypted tunnel. When it is configured incorrectly, the request goes directly to the ISP\u2019s DNS server, bypassing the encryption. You may never notice because the internet works just as well. What is the problem? Your ISP cannot see the page contents because they are protected by HTTPS. But it can see the complete list of domains you request, often with timestamps accurate to the minute, and build a profile from it: what you are interested in, what services you use and where you work. In other words, a DNS leak exposes the table of contents, not the contents. Sometimes that is more than enough.<\/p>\n Here are the four causes I encounter most often:<\/p>\n What English-language tools call a DNS leak test is built into our connection test page<\/a>. Open it with the VPN connected and check the DNS section. Seeing your home ISP\u2019s name means you have found the first leak.<\/p>\n This leak is particularly frustrating because the VPN has nothing to do with it, yet the service still gets the blame. WebRTC is a technology for direct browser-to-browser communication: video calls without installing software, voice chats in a tab, file transfers. It is useful, built into all major browsers and enabled by default. To connect two browsers directly, each one needs to know how to reach the other, and that is where STUN comes in: the browser contacts an external server and asks, in effect, \u201cWhat do I look like from the outside?\u201d It also reveals local addresses. The problem is that these requests can bypass the normal network stack and may not enter the VPN tunnel. A page with a few lines of JavaScript can then obtain both the local address and the real public address. That is a WebRTC leak. Quietly, without a prompt, icon or notification.<\/p>\n An unpleasant bonus is correlation. The site can see the VPN server address in the connection data and your real address from WebRTC. The conclusion is obvious: here is a person using a VPN, and here is their real IP. For anti-fraud systems, that is a ready-made signal. In my experience, this is behind many stories of \u201cI was banned even though I did nothing.\u201d<\/p>\n This is becoming more common as ISPs provide IPv6 addresses. A device can have two addresses at once: the familiar IPv4 and IPv6. They work in parallel over different routes, and the system decides which one to use, usually preferring IPv6. Now imagine that the tunnel handles only IPv4 \u2014 this is common in many configurations, especially custom ones; I have seen dozens of them. All traffic to IPv6-enabled sites can bypass the tunnel. Directly. With your real address, which, unlike a dynamic IPv4 address, is often tied to the device for much longer. The tunnel itself looks perfectly healthy: no disconnects, no errors, green icon.<\/p>\n There are two solutions: either the tunnel supports IPv6 and routes it through the tunnel as well, or IPv6 is disabled on the device or router. The first option is better; the second is simpler. I use the second one myself, I admit it.<\/p>\n Should everyone disable IPv6? No. If your ISP does not provide it, there is nothing to disable. You can check who owns your address and whether it appears on blocklists on the IP check page<\/a>.<\/p>\n A fourth scenario is different. The tunnel drops for a second or three, or while switching between Wi-Fi and a mobile network. The system restores the default route through the normal interface, and traffic immediately goes out unprotected. You may not notice because reconnecting is faster than looking at the screen. This is what Kill Switch is for: it blocks network access until the tunnel comes back. It is essential, and our Kill Switch guide<\/a> explains how to verify that it is actually working. But there is a distinction people constantly confuse \u2014 I used to confuse it too. Kill Switch closes one of the four holes: the one caused by a tunnel disconnect. It does not stop DNS from going to your ISP, prevent the browser from revealing an address through STUN, or route IPv6 through the tunnel.<\/p>\n An enabled Kill Switch does not mean \u201cI am protected\u201d; it means \u201cone of four problems is solved.\u201d<\/p>\n Now for the practical part. A VPN leak test \u2014 and the answer to whether the VPN is working properly at all \u2014 can be done manually and takes me less time than it will take you to read this section.<\/p>\n Run the tests on every device and in every browser. Results can differ dramatically: Chrome leaks while Firefox does not, a phone is clean while a laptop is not.<\/p>\n [Image: two test results side by side \u2014 the \u201cbad\u201d result on the left shows the real IP in the WebRTC section and the ISP\u2019s DNS, while the \u201cgood\u201d result on the right shows VPN server addresses in all three sections]<\/em><\/p>\n Deal with each leak separately. This is my order; you can use another one.<\/p>\n Start with the client settings: almost all VPN clients have an option such as \u201cUse VPN DNS\u201d or \u201cDNS leak protection\u201d. Enable it. In half of the cases, that is enough \u2014 and, honestly, I always feel a little bad when someone spends half a day digging through routes only to find this checkbox. If it does not help, set DNS manually in the adapter settings and use servers reachable only through the tunnel. Do the same on the router if it handles DNS for the network. Also check the browser: Chrome and Firefox have their own secure DNS settings that live separately and can bypass the system. Disable them or point them to the same resolver.<\/p>\n Firefox.<\/strong> The most direct approach. Enter Chrome.<\/strong> There is no built-in switch and none is planned. To disable WebRTC in Chrome, use an extension that limits address exposure or, on a managed workstation, a browser management policy. Use extensions only from the official store and with a solid reputation; otherwise the cure can be worse than the disease.<\/p>\n Edge.<\/strong> It uses the same engine as Chrome, so the approach is the same: an extension or an enterprise policy. Some builds let you limit local address exposure through experimental flags, but I would not rely on them because those flags change between versions.<\/p>\n Safari.<\/strong> Things are calmer here, which I like: the browser masks local addresses by default and asks for permission to access media devices. You can fully disable the mechanism through the Develop menu, which must first be enabled in the settings. Most people do not need this.<\/p>\n The ideal option is a tunnel that supports IPv6 and routes it together with IPv4. By the way, this is a good question to ask any provider\u2019s support team: is IPv6 supported?<\/p>\n The simple option is to disable it. On Windows, this is a checkbox in the adapter properties; on macOS, set IPv6 to \u201cOff\u201d; on a router, use the relevant option in the ISP connection settings. The router option is better because it solves the problem for every device in the home at once.<\/p>\n [Image: step-by-step screenshots for disabling WebRTC \u2014 about:config in Firefox and an extension window in Chrome]<\/em><\/p>\n You have run the test; now you need to understand what you are seeing. Let\u2019s sort it by traffic-light status.<\/p>\nDNS Leak: Your ISP Can See All the Domains You Visit<\/h2>\n
\n
WebRTC Leak: The Browser Reveals Your Address<\/h2>\n
IPv6 Leak: The Second Door Everyone Forgot About<\/h2>\n
Leaks During Disconnects: Why Kill Switch Is Not a Cure-All<\/h2>\n
Five Tests in Five Minutes<\/h2>\n
\n
192.168.x.x<\/code> are not considered a critical leak.<\/li>\nHow to Fix It<\/h2>\n
DNS<\/h3>\n
WebRTC<\/h3>\n
about:config<\/code> in the address bar, accept the warning, find media.peerconnection.enabled<\/code> and set it to false<\/code>. Browser-based video calls will stop working, so keep that in mind.<\/p>\nIPv6<\/h3>\n
How to Read the Result: What Is Normal and What Is Concerning<\/h2>\n