How to Test If Your VPN Is Actually Working: IP, DNS, WebRTC and Kill-Switch Checks

A VPN app showing "Connected" tells you almost nothing about whether it is actually protecting you. The real proof is four quick tests: an IP check, a DNS leak test, a WebRTC leak test and a kill-switch test. Together they take about five minutes and reveal whether your real address, your browsing lookups or your browser are quietly leaking around the tunnel.

Why "connected" is not the same as "protected"

The green status icon in your VPN app only means the app negotiated a session with a server. It does not confirm that every packet your device sends is travelling inside that encrypted tunnel. Several categories of traffic — DNS lookups, WebRTC requests, IPv6 packets — can slip out on a separate path while the icon still glows reassuringly green.

That gap matters because the whole point of a VPN is to replace one specific fact about you — your real IP address, and by extension your approximate location and your internet provider — with the address of a server somewhere else. If even one of these side channels exposes the original, the protection you paid for has a hole in it. The good news is that every one of those holes is testable in a browser tab.

Before you start, do two quick preparation steps. First, note your real IP address before connecting, so you have a baseline to compare against. Second, make sure any privacy features you rely on — a kill switch, DNS leak protection — are actually toggled on in the app's settings rather than assumed. Then connect to a server and run the four checks below in order.

Test 1: The IP address check

This is the foundational test and the one everything else builds on. The idea is simple: your public IP address should change the moment you connect, and it should keep showing the VPN server's location rather than your own for as long as you stay connected. If it doesn't change at all, nothing else is worth testing yet.

Run it as a before-and-after comparison. With the VPN off, open a "what is my IP" page and write down the address and the city or country it reports. Then connect to a server — ideally one in a different country — and reload the same page. You are looking for two things to change together:

• The IP address itself should be different from your baseline.
• The reported location should match the country of the server you chose, not the place you are physically sitting.

There is a subtle trap here called an IPv6 leak. Many networks now assign both an older IPv4 address and a newer IPv6 address, and some VPNs only route the IPv4 traffic while letting IPv6 escape untouched. A page that shows both addresses will reveal this: if your IPv4 changes to the server's but a real IPv6 address still appears, your true address is leaking through the second protocol. If you see that, either enable IPv6 handling in your VPN or disable IPv6 in your operating system's network settings. Our VPN speed-test tools point to reputable leak checkers that display both address types side by side.

One reassuring note: if you are checking a streaming use case rather than pure privacy, a changed IP that matches your chosen country is usually all you need to confirm before testing whether a service loads. Our can-I-watch checker and the broader streaming VPN guide cover that side of things.

Test 2: The DNS leak test

Every time you type a web address, your device asks a DNS server to translate that name into a numeric IP. A DNS leak happens when those lookups travel to your internet provider's DNS servers instead of the VPN's — which means your provider, or whoever runs those servers, can still see a list of every site you visit even though your traffic is otherwise encrypted.

The test works by having a website fire off several DNS queries from your browser and then report back which servers actually answered them. You do not need to install anything; it runs in a tab and finishes in seconds. Here is how to read what comes back:

• If the servers listed belong to your VPN provider (or a private resolver your VPN assigns), your DNS is protected. That is the result you want.
• If any of the servers listed belong to your own internet provider — or show your home city and ISP name — you have a DNS leak, even if your IP address looked correct in Test 1.

A leak here is sneaky precisely because the IP test can pass while the DNS test fails. Your traffic looks like it is coming from Amsterdam, but the record of which sites you asked for is still flowing to your provider at home. In 2026 this is increasingly caused by browser DNS-over-HTTPS settings that route lookups to a public resolver outside the tunnel, so the fix is usually to turn on the VPN's built-in DNS leak protection (sometimes labelled "use VPN DNS only") and re-run the test. If you want a fuller explanation of the mechanism, we keep a plain-language entry in the DNS leak glossary.

Test 3: The WebRTC leak test

WebRTC is the browser technology behind in-page video calls, voice chat and peer-to-peer file transfers. To set those connections up, your browser has to discover its own real network addresses and can share them with a third-party STUN server — and a website running the right few lines of JavaScript can read those addresses in a fraction of a second, sometimes straight past your VPN.

This is the leak that surprises people most, because it is a browser behaviour rather than a VPN failure, and it can expose your genuine public IP while every other test passes cleanly. It most often bites browser-extension VPNs and improperly configured system VPNs that don't intercept the STUN request. Run a WebRTC leak test with your VPN connected and read the results carefully, because they are easy to misinterpret:

• Local addresses are normal. If the test shows something starting with 10.x, 192.168.x, or a long alphanumeric IPv6 string marked as local, that is just your device's address on your own home network. It is not a leak and it cannot identify you.
• A real public IP is the problem. If the WebRTC section displays your actual public IPv4 or IPv6 — the same one you noted before connecting — that is a genuine WebRTC leak, and websites can see it regardless of your VPN.

How you fix it depends on your browser. Firefox lets you disable WebRTC directly by setting the media.peerconnection.enabled flag to false in about:config. Chrome is best handled with a reputable extension rather than manual tinkering, since editing the wrong setting can break other sites. Safari and Brave largely handle this themselves and rarely leak by default. We keep the technical detail in the WebRTC leak glossary for anyone who wants to go deeper.

Test 4: The kill-switch test

A kill switch is the safety net that cuts your internet the instant the VPN connection drops, so your real IP is never exposed during the gap while the app reconnects. It is the one feature you hope never activates — which is exactly why it is worth confirming it actually works before you rely on it. Testing it means deliberately forcing a disconnect and watching what happens.

First make sure the kill switch is enabled in your app's settings; it is often off by default. One caveat worth knowing: some vendors design the kill switch to trigger only on accidental drops, not on disconnects you initiate yourself — so a graceful disconnect may not test it faithfully. Use one of these approaches to force a drop while watching a live IP page:

1. 1Connect to the VPN, open an IP-check page and confirm it shows the server's address. Then toggle airplane mode on and off, or briefly disable your network adapter, to simulate a dropped connection.
2. 2For a stricter test, force-quit the VPN process from your task manager rather than using the app's Disconnect button — a graceful disconnect can mask problems that a real crash would expose.

Now read the outcome. A working kill switch means that during the gap you see no internet at all — a blank page, a "no connection" error, or a DNS failure — and when the VPN reconnects, the page reloads showing the server's IP without your real address ever appearing. If, even for a second, your true IP flashes up on the page, the kill switch is not doing its job and you should not trust that setup for anything sensitive.

When your leaks are really about who can watch you

For a lot of readers these tests are a chore before something fun — confirming a server works before a match or a show. But if your reason for using a VPN is privacy rather than access, the DNS and WebRTC tests are the ones that matter most, because they are where a technically "connected" VPN most often betrays you without any visible sign.

If you fall into that camp, it is worth running these checks after every major browser update and after switching networks, not just once. Browser vendors change WebRTC behaviour regularly, and a resolver that was private on your home Wi-Fi can behave differently on a café or office network. For the wider picture on choosing a genuinely leak-resistant provider, our privacy-focused VPN guide walks through what to prioritise, and the main VPN rankings factor these audits into their scoring.

It is also worth remembering that a free VPN is more likely to leak, log or throttle than a paid one, simply because the economics push it that way. If you are weighing that trade-off, read our honest take in the free VPN guide before you commit any real browsing to one.

Putting it all together: reading your full result set

None of these four tests is meaningful in isolation. A VPN can pass the IP check and still fail the DNS test; it can pass both and still leak through WebRTC; and it can pass all three while a broken kill switch leaves you exposed the moment the connection wobbles. Only a clean sweep across all four tells you the tunnel is genuinely watertight.

Here is the quick summary of what a fully passing setup looks like:

• IP check: your address and location both changed to the server's, with no stray real IPv6 showing.
• DNS test: only VPN or private resolvers answered — none belonging to your internet provider.
• WebRTC test: only local (10.x / 192.168.x) addresses appear; no real public IP.
• Kill-switch test: forcing a disconnect killed your internet entirely, with your real IP never surfacing.

If every line above is true, your VPN is doing what it promises. If any one fails, you now know exactly which setting to change — and you can re-run just that test in under a minute to confirm the fix. Bookmark the four checks and re-run them whenever you install a new VPN, switch to a new device or update your browser, and you will never have to take that green "Connected" icon on faith again.