How to Test If Your VPN Is Actually Working

Why "Connected" in the App Doesn't Mean What You Think

Every VPN app has some version of a green checkmark, a "Connected" label, or a status toggle that flips on when you tap connect. That indicator tells you the app successfully established a tunnel to a server — nothing more. It does not tell you whether every piece of software on your device is actually routing through that tunnel, whether your DNS queries are leaking out to your internet provider anyway, or whether a browser feature is quietly broadcasting your real IP address in parallel with the "protected" connection running underneath it. The app's status light is reporting on the tunnel's existence, not on whether the tunnel is doing its job for everything you care about.

This gap matters because the failure modes are almost always silent. A DNS leak doesn't pop up a warning — your browser just quietly asks your ISP's DNS server "where is netflix.com?" instead of asking the VPN's DNS server, and everything continues to look completely normal. A WebRTC leak doesn't interrupt your video call — it just lets the site on the other end see your real IP address in a background data channel your browser opened without asking. A kill switch that isn't actually enabled doesn't announce itself until the one moment you needed it, when your Wi-Fi hiccups for two seconds on public airport Wi-Fi and your device silently falls back to broadcasting everything unencrypted. None of these scenarios change the "Connected" label. That's exactly why testing matters — it converts an assumption into a checked, verified fact, and it takes under five minutes.

The Core Test VPN Working Check: Your IP Address

This is the starting point and the single most important check, because it directly answers the question a VPN exists to solve: is the outside world seeing your real IP address, or the VPN server's?

Step-by-step

1. With your VPN turned off, visit an IP-lookup site — ipleak.net, browserleaks.com/ip, or whatismyipaddress.com all work and none require an account. Note the IP address and the city or region it reports. That's your real, unprotected IP.
2. Turn your VPN on and connect to a server, ideally one in a specific country or city so you know what result to expect.
3. Reload the same IP-lookup page (a hard refresh, not a cached load) and check the result again.

What a pass looks like

The IP address shown after connecting should be completely different from your real one, and the reported location should match — roughly — the server location you selected in the app. "Roughly" is doing some work in that sentence: IP geolocation databases are not perfectly precise, so a server you picked in "New York" might occasionally geolocate to a nearby city or even show the country correctly but the city slightly off. That's normal and not a leak. What is a problem is if the IP address doesn't change at all, or if it changes but geolocates to your actual home country when you selected a server elsewhere — that indicates the VPN tunnel isn't actually carrying your traffic, even though the app says connected.

A second confirmation worth doing

Repeat the check from a different device on the same network, and separately, repeat it in a different browser on the same device. It's possible for a VPN to work correctly at the system level but for one specific browser to be misconfigured to bypass it (more on that in the browser-extension section below), so checking more than one surface catches problems a single test would miss.

How to Run a DNS Leak Test (and Why This Is the Check People Skip)

DNS — the system that translates a domain name like "example.com" into an IP address — is a separate data path from your regular web traffic, and it's the leak that catches the most people off guard, because your IP address can look perfectly hidden while your DNS queries are still going straight to your ISP's DNS servers behind the scenes. When that happens, your ISP can't see the content of what you're doing, but it can still see every domain you look up, in order, in real time — which is most of the browsing-history visibility a VPN is supposed to eliminate in the first place.

How to check it

Connect your VPN, then go to a dedicated DNS leak test tool — dnsleaktest.com and ipleak.net both offer one, usually as an "extended test" or "standard test" button. The test works by having your browser make a series of lookups and then reporting back which DNS servers actually answered them.

Reading the results

A clean result shows DNS servers belonging to your VPN provider (their name will often appear directly, or the results will show the same country/region as your VPN server, not your home ISP). A leak shows DNS servers registered to your actual internet provider — often recognizable by name, or by ISP-lookup services flagging them as belonging to your ISP's network rather than the VPN's. If you see your ISP's name anywhere in that results table while the VPN is connected, that's a DNS leak, and it's a meaningfully different problem from a leaking IP address — it needs a different fix (covered below), not just reconnecting the VPN.

Why this leak happens

DNS leaks are most often caused by operating-system-level settings that override the VPN's DNS configuration, a VPN app that isn't forcing DNS traffic through its own tunnel by default, or (on some routers and smart TVs) a device that has a DNS server hardcoded outside of what the VPN controls. It's a configuration issue, not usually a sign the VPN provider is lying about their service — but it's one you have to actually test for, because nothing in the app's normal interface will surface it.

How to Run a WebRTC Leak Test

WebRTC is a browser technology that enables real-time features like video calls and file-sharing directly between browsers, and to do that job it sometimes needs to establish a direct connection between two devices — which can mean revealing your real IP address to the other end of that connection, even while your regular browsing traffic is correctly routed through a VPN. It's a browser-level leak, not a VPN-level one, which is exactly why it's so often missed: the VPN is doing its job perfectly, and the leak is happening one layer up, inside the browser itself.

How to check it

With your VPN connected, visit browserleaks.com/webrtc or the WebRTC section of ipleak.net. These pages actively probe your browser using the same mechanism a malicious or simply curious site could use, and display any IP addresses your browser discloses through that channel.

What you're looking for

The test typically lists a "public IP" and sometimes a "local IP" detected via WebRTC. The public IP shown should match your VPN's IP — the same one from your earlier IP-address test — not your real one. Some browsers also expose a local network IP (like a 192.168.x.x address) through WebRTC; that's normal and expected even with a VPN active, since it describes your device's position on your own home network rather than your identity to the outside world, and isn't something a VPN is designed to hide.

If it's leaking

Most reputable VPN browser extensions include a WebRTC-blocking option — check your VPN app's browser extension settings first, since this is frequently a toggle rather than something requiring a separate tool. If your VPN doesn't offer one, browser-level extensions built specifically to disable WebRTC are a common fix, as is disabling WebRTC directly in some browsers' advanced settings (the exact steps vary by browser and change over time, so check your specific browser's current documentation rather than following outdated instructions).

What About IPv6 Leaks? The One Most People Have Never Heard Of

Most of the internet still runs primarily on IPv4 addresses (the familiar four-number format like 203.0.113.1), but a growing share of networks and devices also support IPv6, a newer addressing system with a much larger address space. Here's the problem: a lot of VPN software was built primarily to tunnel and hide IPv4 traffic, and if your device and network also support IPv6, some of that traffic can bypass the VPN tunnel entirely and go out over your regular, unprotected IPv6 connection — even while your IPv4 traffic is correctly routed through the VPN. It's a genuinely different leak from a DNS or WebRTC leak, and it's one of the more overlooked checks because IPv6 support varies so much by device, home network, and mobile carrier that many people don't know whether it even applies to them.

How to check it

The same IP-lookup sites used for the core IP test — ipleak.net in particular — typically detect and display both an IPv4 and an IPv6 result if your connection has both. With your VPN connected, check whether an IPv6 address appears in the results at all, and if it does, whether it's the VPN's or your ISP's. If your real ISP-assigned IPv6 address shows up while connected, that's a leak, regardless of how clean your IPv4 results looked.

What to do about it

Many VPN apps address this by disabling IPv6 on your device system-wide while connected, or by tunneling IPv6 traffic the same way they tunnel IPv4 — check your app's settings for an IPv6-related toggle, often grouped near the DNS or leak-protection settings. If your provider's app doesn't handle it and the leak test confirms a real IPv6 address is exposed, manually disabling IPv6 at the operating-system or router level is a blunter but effective fallback, since a fully disabled IPv6 stack has nothing left to leak through.

Command-Line Ways to Test (For the Technically Inclined)

The browser-based tools above cover what almost everyone needs, but if you're comfortable with a terminal, a couple of command-line checks can confirm the same things without relying on a third-party website, and they're useful for scripting a repeatable check or troubleshooting a headless device without a browser.

Checking your public IP from the command line

On macOS, Linux, or Windows with curl available, running a command like curl ifconfig.me or curl ipinfo.io against a plain terminal returns your current public IP address as seen by the outside internet — run it once with the VPN off and once connected, exactly like the browser version, and compare.

Checking DNS resolution directly

The nslookup command (available on Windows, macOS, and most Linux systems) or dig on macOS/Linux can show which DNS server actually answered a lookup. Running nslookup example.com while connected to your VPN and checking the "Server" line in the output tells you which DNS server handled the request — if it's an address belonging to your ISP rather than your VPN provider's DNS infrastructure, that's the command-line equivalent of a failed browser-based DNS leak test.

Why bother with this over the browser tools

For most people, the browser-based tests are simpler and sufficient. The command-line approach is worth knowing if you're testing a router, a headless server, a smart-home hub without a browser, or if you want to script the IP/DNS check as part of a repeatable routine rather than manually visiting a website each time.

How to Test Your VPN's Kill Switch

A kill switch is meant to cut your device's internet access entirely the moment the VPN connection drops, so that instead of silently falling back to your normal, unprotected connection, you simply lose internet until the VPN reconnects. It's arguably the single most important feature to verify, because it's specifically designed for the moment you're not paying attention — a dropped connection while switching from Wi-Fi to mobile data, a brief server-side hiccup, your laptop waking from sleep. If the kill switch doesn't work, that's precisely the moment your real IP and unencrypted traffic get exposed, with nothing in the app telling you it happened.

Before you start: confirm it's turned on

Many VPN apps ship with the kill switch available but not enabled by default, tucked into a settings or security menu rather than the main screen. Check your app's settings first — testing a kill switch that was never switched on will just teach you the wrong lesson.

Two ways to test it

The simplest method: connect your VPN, open a page that auto-refreshes or streams something continuously (a live video, or just leave the IP-lookup page from earlier open), then manually turn off Wi-Fi on your device for a few seconds and turn it back on, or unplug your ethernet cable briefly. Watch what happens to your internet access during that gap — if the kill switch is working, everything should stop loading entirely until the VPN reconnects, rather than the page quietly continuing to load using your normal connection.

A more deliberate method on a computer: with the VPN connected, force-quit or kill the VPN application's process directly (Task Manager on Windows, Activity Monitor on Mac) rather than clicking "disconnect" in the app, since this more closely simulates an unexpected crash rather than a clean, expected disconnection. Immediately check whether your internet access is blocked or whether it keeps working normally — the latter means the kill switch didn't catch that failure mode.

What a working kill switch looks like

Internet access should stop completely — pages fail to load, apps show connection errors — until the VPN reconnects on its own or you manually reconnect it. That temporary inconvenience is the feature working correctly. If your internet kept working smoothly through the disconnection test, either the kill switch isn't enabled, isn't functioning, or the app doesn't offer one at all, and you should treat public-Wi-Fi use with that app as unprotected during any connection hiccup.

Testing on Mobile: What's Different on iOS and Android

The same core checks — IP address, DNS leak, kill switch — apply on phones, but a couple of mobile-specific quirks are worth knowing before you assume something is broken.

Switching networks mid-test

Phones move between Wi-Fi and cellular data far more often than laptops, and that transition is one of the more common real-world moments a VPN briefly drops and needs to reconnect. After running your IP and DNS leak tests on Wi-Fi, repeat them on cellular data specifically, since some carrier-level network configurations behave differently than home Wi-Fi and it's worth confirming the VPN performs the same way on both.

"Always-on VPN" settings

Both iOS and Android offer a system-level "always-on VPN" or similar setting (separate from the VPN app's own kill switch toggle) that can enforce VPN routing at the operating-system level and block non-VPN traffic if the connection drops. Where available, enabling this alongside your VPN app's own kill switch is a reasonable belt-and-suspenders approach, though the exact menu location varies by device and OS version.

Background app refresh and leaks

Some apps on mobile devices are permitted to bypass VPN routing for background tasks depending on the OS and app-specific settings, which is a narrower and more app-specific issue than the browser-based leaks covered above. If you're specifically concerned about one app's traffic, checking that app's own network permissions is a more targeted approach than the general leak tests, which are primarily browser-focused.

Testing a VPN on a Router (Whole-Network Setups)

If you've configured a VPN directly on your home router rather than through an app on each device, the testing approach is largely the same but needs a small adjustment: run your IP address, DNS leak, and WebRTC checks from a device connected to that router's network, without a separate VPN app also running on the device itself, so you're specifically confirming the router-level tunnel rather than double-testing an app you may have running as well.

One router-specific thing worth checking: confirm that every device on the network is actually routed through the VPN, not just the ones you've tested. Smart TVs, game consoles, and IoT devices sometimes get excluded from router-level VPN routing depending on how the router is configured (deliberately, for compatibility reasons, or by accident), so it's worth spot-checking one of those devices too if privacy across your whole household network is the goal, rather than assuming router-level coverage is automatically all-or-nothing.

Browser Extensions vs. the Full App: A Common Source of Confusion

Many VPN providers offer both a full desktop/mobile app and a separate browser extension, and it's a genuinely common mix-up to have one running and assume it covers everything. A browser extension typically only protects traffic inside that specific browser — it does nothing for a different browser you also have open, for apps outside the browser entirely (email clients, game launchers, other software making its own network connections), or for your operating system's own background traffic. The full desktop or mobile app, by contrast, is generally built to route your device's entire internet connection.

If your goal is comprehensive protection — the kind the tests in this article are checking for — running only a browser extension and assuming it covers your whole device is a common way to end up with a false sense of security. Check specifically which one you have running before testing, and if you want full-device coverage, use the full app rather than (or in addition to) the extension.

Speed and Latency: Not a Leak, But Worth Checking Too

Testing whether a VPN is "working" isn't only about leaks — a connection that's technically secure but unusably slow is also, practically speaking, not working for you. After confirming the security checks above pass, it's reasonable to also run a basic speed test (any standard speed-test site works) with the VPN off, then again with it connected to a nearby server and a distant one, to get a feel for the real-world trade-off on your specific connection. Some slowdown from a VPN is normal and expected — you're adding encryption overhead and an extra hop — but a dramatic, unusable drop on a nearby server may indicate a server-load issue worth switching away from, rather than something wrong with your setup specifically.

What to Do If a Test Fails

Finding a leak isn't a sign you need to panic, but it does mean treating the VPN as not fully protective until it's fixed — don't rely on it for anything sensitive (banking on public Wi-Fi, for example) until you've re-tested and confirmed a clean result. A practical order of operations:

1. Update the app

Leak-fixing patches are common, ordinary VPN app updates — an outdated app version is one of the more frequent, least dramatic causes of a leak that's already been fixed upstream. Check for an update before troubleshooting further.

2. Check for a dedicated leak-protection setting

Many apps bundle DNS leak protection, WebRTC blocking, and the kill switch as togglable settings that aren't always on by default. Dig into the app's security or advanced settings menu specifically, rather than assuming default settings are the most protective ones.

3. Try a different protocol

If your app lets you choose between protocols (WireGuard, OpenVPN, IKEv2), switching to a different one and re-running the test can sometimes resolve a leak tied to how a specific protocol implementation handles DNS routing on your particular device or OS version.

4. Restart networking, not just the app

A stale system-level network configuration can occasionally override a VPN's settings even after reconnecting. Fully disconnecting the VPN, restarting your device's networking (or the device itself), and reconnecting clears out state that a simple app-level reconnect sometimes doesn't.

5. Check your operating system's own DNS settings

On some systems, a manually configured DNS server (set for reasons unrelated to the VPN — ad-blocking DNS services are a common culprit) can override what the VPN app is trying to enforce. Confirm your device's network settings aren't hardcoded to a specific DNS server outside the VPN app's control.

6. If nothing fixes it, contact support or reconsider the provider

A persistent, unfixable leak after trying the above is worth raising directly with the provider's support team, since it may be a known issue with a fix in progress, or in rare cases, a signal to evaluate a different provider if the issue can't be resolved.

Free Testing Tools Worth Knowing (and What Each One Is Best At)

Several free sites get referenced throughout this article, and they overlap in places but aren't identical — knowing what each one is specifically good at saves time.

ipleak.net

Probably the single most useful one-stop option, since a single page shows your IPv4 address, IPv6 address (if applicable), DNS servers in use, and a WebRTC detection result together, rather than requiring separate visits to separate tools.

dnsleaktest.com

Focused specifically on DNS, with a "standard" test (faster, fewer queries) and an "extended" test (slower, more thorough, better at catching an intermittent leak that only shows up on some queries rather than every single one).

browserleaks.com

A broader toolkit that includes IP lookup and WebRTC detection like the others, but also separate pages for checking browser fingerprinting, canvas fingerprinting, and other tracking vectors that exist independently of whether your VPN is leaking — useful if you're thinking about browser privacy more broadly, beyond just the VPN-specific checks in this article.

Your VPN provider's own test page

Some providers publish their own connection-check or leak-test page specifically calibrated to their own service. These can be a useful quick reference, but running an independent, third-party test — rather than only the provider's own — is worth doing at least once, since a provider-run test has less incentive to surface an embarrassing result than a neutral third party does.

What's Actually at Risk If a Leak Goes Unnoticed

It's worth being concrete about why any of this matters, rather than treating leak-testing as an abstract technical exercise. An unnoticed DNS leak means your internet provider can still build an accurate, timestamped record of every domain you visit, even while you believe that visibility has been eliminated — which defeats one of the most common reasons people pay for a VPN in the first place. An unnoticed IP or WebRTC leak means any site you visit, including ones actively trying to identify or block VPN users, can see your real location and internet provider, undermining both privacy and any region-specific access you were relying on the VPN for. A kill switch that silently fails means the one moment you most needed protection — an unexpected disconnection on an untrusted network — is exactly the moment you got none, without any indication it happened.

None of these are catastrophic in the way a headline-grabbing data breach is, but they're each a quiet, complete failure of the specific thing you were paying for. That gap between "believed protected" and "actually protected" is precisely what a five-minute testing routine closes, and it's a far more reliable way to know your VPN is doing its job than trusting an app's status indicator alone.

A Simple Repeatable Testing Routine

Once you've done the full walkthrough above once, a lighter version is worth repeating periodically — after any app update, after switching to a new server or provider, and roughly every few months as a general habit, since leaks can be reintroduced by an update just as easily as they can be fixed by one.

1. Connect the VPN, visit an IP-lookup site, confirm your IP and location changed from your real one.
2. Run a DNS leak test on the same visit, confirm no ISP DNS servers appear.
3. Run a WebRTC leak test if you rely on browser-based use, confirm no real IP is exposed.
4. Once every so often (not necessary every single time), deliberately drop your connection to confirm the kill switch still blocks traffic.

The whole routine takes a few minutes and is the only way to move from "the app says connected" to actually knowing your traffic, DNS, and IP address are handled the way you expect.

Choosing a VPN With Testing in Mind

Not every provider makes leak protection equally easy to verify or equally robust by default, and if you're choosing between providers, it's reasonable to factor that in. NordVPN and Proton VPN both build DNS leak protection and a kill switch into their apps as standard, documented features rather than obscure settings, which tends to make the testing process above straightforward. PureVPN and FastestVPN also include kill switch functionality in their apps; as with any provider, it's worth locating the specific toggle in the app's settings and running the tests in this article yourself after connecting, rather than assuming a feature is on by default. None of the specific pricing, plan tiers, or ratings for any of these providers are claimed here — check each provider's own current site for that, and use the tests above, not marketing copy, to confirm the protection itself.

The Bottom Line

A VPN app's "Connected" status is a starting point, not a guarantee. The only way to actually confirm a VPN is working is to test it directly: check that your IP address and location genuinely change, run a DNS leak test to confirm your ISP isn't still seeing your lookups, run a WebRTC leak test if you use a browser for anything sensitive, and deliberately trigger a disconnection to confirm the kill switch actually blocks traffic instead of silently falling back. Each test takes under a minute, all the tools involved are free, and running through them once after setup — then again after any app update or provider switch — is the difference between assuming your VPN protects you and actually knowing it does.