Read your public address before connecting and again after: it should change to the VPN server's. Then test for DNS, IPv6 and WebRTC leaks, because any of the three can carry your real details outside the tunnel while the app still says connected. A green icon in the client proves the tunnel opened, nothing more.
"Connected" means the app believes it opened a tunnel. It does not mean everything your device sends is going through it. Leaks are ordinary rather than exotic, they produce no warning of any kind, and the only way to find one is to look for it deliberately - which is how people spend months protected in theory and exposed in practice.
Five checks, in the order that makes sense, plus what each failure actually means and what to change when one of them fails. None of it takes longer than a few minutes.
What Does It Mean for a VPN to Be Working?
Four things have to be true at the same time, and they are independent of each other. Your public address has to be the VPN's rather than yours. Your DNS lookups, the requests that turn a name into an address, have to travel inside the tunnel rather than going straight to your provider's resolver. If your connection has IPv6, that has to be tunnelled too rather than slipping out alongside. And your browser has to not hand over an address on its own through WebRTC.
A VPN can get the first one right and fail the other three. That is precisely what "connected but leaking" is, and none of it is visible in the client, which reports on the tunnel it opened and nothing about what is bypassing it.
Step 1: Read Your Address Before and After Connecting
With the VPN off, open the MyIPShow homepage and note three things: the address, the provider name and the location. Connect, reload, and all three should have changed - the address to the server's, the provider to a hosting company, the location to wherever you picked. If you want to check a specific address rather than your own, the IP Lookup tool reads any address you paste in, and the VPN Checker says whether what you are presenting looks like a VPN or an ordinary line.
When nothing changes, there are three usual explanations before you start suspecting the provider. Split tunnelling may be on, which routes only chosen apps through the VPN and leaves your browser outside it - easy to enable by accident and easy to forget. You may be using a browser extension rather than the desktop client, and an extension is a proxy for that browser alone, so everything else on the device is untouched. Or the tunnel never established and the client fell back to your normal connection without saying so.
Step 2: Check for a DNS Leak
A DNS leak is your device asking your provider's resolver to look up the names of the sites you visit, while the traffic itself goes through the tunnel (source: Fortinet). Your address stays hidden and the list of everywhere you went stays visible to the one company you were trying to keep it from. It is the most common of these failures and the least obvious.
This is the one check you cannot do from a page that only reads your address, and it is worth knowing why: a leak test works by asking your device to look up unique hostnames and then reporting which resolvers came asking for them. That needs a service watching its own authoritative nameservers, so use a dedicated DNS leak test - most VPN providers host one, and there are independent ones. What you want to see is only your provider's own resolvers, or ones you deliberately configured. Seeing your ISP's name in that list is the leak.
The usual causes are your operating system deciding to query the resolver it already had, a router that intercepts all DNS traffic regardless of what the device asks, or IPv6 lookups escaping while IPv4 ones behave - which is the next check.
Step 3: Check for an IPv6 Leak
This is the check almost every guide on this subject leaves out, and it is a real failure with a simple shape. Plenty of VPN clients tunnel IPv4 and ignore IPv6 entirely. If your provider has given you IPv6 as well, and the site you are visiting can be reached over it, your device may take the direct IPv6 route while everything else obediently goes through the tunnel. Your real address goes out in the open, and every IPv4 check you ran passes.
Reading it is straightforward: with the VPN connected, look at what the MyIPShow homepage reports. If the address is an IPv6 one and the provider beside it is yours rather than the VPN's, you have found the leak. A test page that reports both address families side by side is the more thorough version of the same check.
Three fixes, in order of preference: use a client that tunnels IPv6 properly, turn on the client's option to block IPv6 while connected, or disable IPv6 on the adapter as a last resort - last, because it degrades a connection that is increasingly the normal one. IPv4 vs IPv6 covers why you probably have both.
Step 4: Check for a WebRTC Leak
WebRTC is what browsers use for video calls and other real-time features, and to make a direct connection work it collects the addresses your device can be reached on. For years that collection was handed to any page that asked, which is how a browser could give away a real address the tunnel was covering.
The honest current position is narrower than most articles admit. Browsers have tightened this considerably - local addresses are now replaced by a generated hostname by default in the major ones, precisely because of this problem - so the classic leak is largely closed rather than wide open. What remains is setup-specific: split tunnelling, a browser-only proxy with the rest of the device outside it, an older browser, an extension reaching around the tunnel. Which is the argument for running a browser-based WebRTC test with the VPN connected rather than assuming either way. Connected, it should report the VPN's address and nothing of yours.
Step 5: Confirm the Kill Switch Actually Cuts Traffic
A kill switch is supposed to block traffic if the tunnel drops unexpectedly, closing the window where you carry on browsing exposed without noticing. Testing it properly matters, because the obvious test does not test it.
Clicking Disconnect in the client tells you nothing: that is an intentional disconnect, and most clients deliberately restore normal traffic afterwards. Turning off your Wi-Fi tells you nothing either, since you have no connection either way. What you want is an abrupt failure - force-quit the VPN process from Task Manager, Activity Monitor or your system's process manager while a page is loading or a download is running. A working kill switch stops it dead. If the page finishes loading, traffic fell back to your ordinary connection and the switch did not fire.
Worth checking which of the two your client offers while you are in there: blocking only on an unexpected drop, or blocking whenever the VPN is not connected at all. The second is stricter and is the one you want if the point is that nothing should ever leave untunnelled.
All five have to pass. A setup that only passes the first is hiding your address from the site you are visiting while your provider keeps a list of everywhere you went.
What Are the Signs Your VPN Is Not Protecting You?
- The address or the provider name does not change after connecting - the tunnel is not carrying your browser, whether because of split tunnelling, an extension-only setup or a connection that never established.
- A leak test lists your ISP's resolvers while you are connected - a DNS leak, usually your operating system or your router querying the resolver it already knew about.
- Your reading shows an IPv6 address that belongs to you - the client is tunnelling IPv4 only and IPv6 is going out beside it.
- A WebRTC test reports your own address in a browser tab - the tunnel is fine and the browser is reaching around it.
- Sites still show your real country's language, currency or prices - a soft signal rather than proof, since an account preference or a stored cookie can do the same thing, but worth a proper check when you see it.
Separately, and often confused with the above: streaming services and shops that block you while everything reads as connected are not evidence of a leak. That is the opposite problem - your VPN is working, and the address it gave you is a catalogued hosting range they have chosen to refuse. The Proxy Check tool shows whether the address you are on is one of those, and a different server usually settles it.
What Do You Do When a Check Fails?
Most failures are a setting rather than a broken product, and they have standard fixes. An address that does not change: turn off split tunnelling, use the desktop client instead of the browser extension, try the other protocol the client offers, then try a different server. A DNS leak: most clients have their own DNS handling or leak-protection option and it is not always on by default, so enable it before changing anything at the operating system level - and if your router is intercepting every lookup regardless, that is a router setting, not a VPN one. An IPv6 leak: tunnel it, block it, or as a last resort disable it on the adapter.
A WebRTC leak is the one with a real cost attached. It can be switched off in Firefox through its configuration editor, and in Chrome it takes an extension because there is no built-in toggle - but turning WebRTC off breaks video calls and anything else built on it, so decide whether you want it off permanently or only in the browser you use for things that matter. Fixing the underlying setup, so the browser has no untunnelled route to reach for, is the better answer where it is available.
Re-run the check after every change rather than assuming the setting did what it says, and remember that none of this carries between devices. Then, if several checks keep failing with everything configured properly, the honest conclusion is that the client is the problem. How to hide your IP address covers what to look for in a replacement, and what the alternatives to a VPN actually trade away.
How Often Should You Check?
Not often, but at specific moments. Anything that touches networking can quietly undo a working setup, so run the address and DNS checks after a VPN client update, after an operating system update, after changing router or Wi-Fi network, and the first time you use a new browser. Beyond those triggers, once every month or two is plenty if privacy is the point of the connection for you, and the full five-step run is worth repeating whenever you change server, protocol or provider.
The VPN Checker is the thirty-second version of the first check when you just want reassurance that something is still in front of you.
Frequently Asked Questions
My VPN app says it is connected. Is that proof it is working?
No. That confirms the tunnel established and nothing else. It says nothing about lookups going to your provider's resolver, IPv6 traffic going out alongside the tunnel, or your browser handing over an address through WebRTC, all of which happen with the client showing connected. Each one has to be tested separately.
Why would my IP change but I still have a DNS leak?
Because they are separate systems. Your general traffic can route through the tunnel correctly, changing the address a site sees, while name lookups are handled by whatever resolver your operating system or router insists on. The two failures are independent, which is why passing the address check tells you nothing about the DNS one.
Do I need to test on every device separately?
Yes. Client configuration, browser behaviour and operating system defaults all differ, so a clean result on a laptop says nothing about a phone, and a clean result in one browser says nothing about another one on the same machine.
Does incognito or private browsing mode fix a WebRTC leak?
No. Private browsing clears cookies and history locally when you close the window, and it does not change how the browser handles network connections, so WebRTC behaves exactly as it does in an ordinary window.
Can my ISP still see that I am using a VPN?
Generally yes. They cannot read what is inside the tunnel or which sites you open, but they can see that a steady stream of encrypted traffic is going to one address, and that address often belongs to a known VPN operator. Hiding the fact that you use a VPN is a different problem from hiding what you do with it.
If everything passes, am I completely anonymous online?
No, and the gap is worth being clear about. Passing all five checks means your address and your lookups are not escaping the tunnel, which is real protection. It does nothing about browser fingerprinting, cookies or the accounts you sign into, and those recognise you without needing your address at all.
Final Words
A VPN that leaks quietly is worse than no VPN at all, because you behave as though you are covered. The five checks here turn an assumption into a fact, and four of them take under a minute once you know what you are looking at. Run them after you set a client up, run them again after any update, and treat the client's own status light as what it is - a report on the tunnel, not on your traffic. Reading your address is where every one of these checks starts, and MyIPShow shows it as a site sees it.