How to Test if Your VPN Is Working: A Step-by-Step Checklist

Why isn't a "connected" status in the app enough?

Every VPN app has some version of the same visual cue: a toggle switches to a different color, a padlock icon fills in, a label changes from "disconnected" to "connected," maybe with a server location and a timer counting up next to it. It's a reasonable thing to trust at a glance, and most of the time it's accurate. But that status indicator is reporting on one narrow thing: whether the app successfully negotiated an encrypted tunnel with a VPN server. It is not independently verifying that every category of your traffic — your general browsing, your DNS lookups, your browser's real-time communication features, your behavior if the tunnel drops mid-session — is actually flowing through that tunnel the way you'd expect.

Those are different questions, and the gap between them is exactly where the most common VPN problems live. A VPN can show "connected" while DNS requests still leak to your internet provider in the background. It can show "connected" while a browser feature quietly exposes your real IP address to a website. It can show "connected" one moment and then, if the tunnel drops unexpectedly and there's no working kill switch, silently let your device fall back to your normal, unprotected internet connection without any obvious warning. None of these failure modes necessarily change what the app's status indicator says, which is exactly why learning how to test if your VPN is working — rather than trusting the app's word for it — is worth doing at least once, and periodically after that.

None of the checks below require special tools, technical expertise, or more than about ten minutes combined. They're the same basic checks a careful user would run through after setting up any new VPN, and they're worth repeating any time something changes: a new device, a new network, a VPN app update, or simply the first time you're relying on the VPN for something that actually matters to you.

What should you check first: your IP address?

The most basic thing a VPN is supposed to do is replace your visible IP address with one belonging to the VPN server you're connected to. That makes an IP address check the simplest and most direct starting point for confirming a VPN connection is doing anything at all.

How do you actually run an IP address check?

1. Before connecting to your VPN, visit an IP-checking site. Any site that displays your current public IP address and its approximate location works for this — there are many free, ad-supported ones, and search engines themselves will often show your IP address directly if you search a phrase like "what is my IP." Note the IP address and the city or region it shows; this is your baseline, non-VPN connection.
2. Connect to your VPN, choosing whichever server location you plan to use normally. Wait for the app to show a stable connected state rather than checking immediately, since results can be unreliable in the few seconds right after a connection is established.
3. Reload the same IP-checking site (or visit a second one, to cross-check). The IP address shown should now be different from your baseline, and the listed location should correspond to the VPN server location you selected, not your actual physical location.
4. Confirm the two results genuinely differ. If the IP address and location shown while connected match what you saw before connecting, the VPN is not routing your traffic the way it should be, regardless of what the app's own status indicator says.

It's worth understanding what "location corresponds to the server" actually means in practice, too. VPN server location labels (a country and sometimes a city) are self-reported by the provider and generally accurate, but IP geolocation databases used by the checking site you're using aren't always perfectly precise — they can be off by a city or region within the same country, especially for smaller markets. A result that's in the right country but a slightly different city than expected usually isn't a red flag on its own; a result still showing your actual home country and city when you selected a server elsewhere is.

It's also worth checking whether the IP address shown is labeled as belonging to your VPN provider specifically, rather than just "a different location." Most IP-checking sites show an "ISP" or "organization" field alongside the address, and if a VPN is genuinely working, that field will typically name the VPN provider (or a hosting company the provider uses) rather than your actual home internet provider. Seeing your real ISP's name in that field, even alongside a changed IP address, is worth a second look — in rare cases it can indicate the VPN app is only partially routing traffic, or that the specific check you're using isn't reading the connection the way you'd expect.

One more distinction worth making explicitly: an IP address check tells you what a website sees when your device makes a standard web request. It doesn't tell you anything about DNS resolution, about a browser feature separately exposing your address, or about what happens if the connection drops — those are the three checks covered next, and none of them are optional if you actually want confidence that a VPN is doing everything it claims to, rather than just the most visible part of it.

How do you test if your VPN is working for DNS, specifically?

An IP address check confirms your general traffic is routed through the VPN. It doesn't, by itself, confirm that a separate and easy-to-overlook category of traffic — DNS lookups, the requests that translate a website's name into an IP address — is also staying inside the tunnel. A VPN can pass an IP address check cleanly while still leaking DNS requests to your ISP in the background, which is why a dedicated DNS check is a separate step rather than something an IP check already covers. (Our longer explainer on DNS leaks covers the underlying mechanics in more depth if you want the full picture; this section focuses on running the check itself.)

How do you run a DNS leak test?

1. Connect to your VPN and confirm a stable connected state.
2. Visit a DNS leak testing site. Several free, browser-based tools exist specifically for this (independent sites built for exactly this check are common and any of them work similarly), and some VPN apps now include an equivalent check built directly into the app.
3. Run the test and read the list of DNS servers it reports. The result will show which server, or servers, actually answered the test's DNS queries, usually along with the name of whoever operates each one.
4. Check whether those servers belong to your VPN provider or to your ISP. If every server listed is operated by your VPN provider, that's a clean result. If any server matches your ISP's name or known IP ranges, that's a DNS leak — some or all of your DNS requests are reaching your internet provider directly, bypassing the tunnel, no matter what the VPN app's connection status shows.
5. Run the "extended" version of the test if the tool offers one. A standard test is a quick single check; an extended test typically sends more DNS queries over a longer window and can catch intermittent leaks — ones that only show up part of the time — that a single quick check can miss.

A DNS leak isn't automatically a sign that a VPN provider is acting in bad faith — it's often a technical gap involving IPv6 handling, a device's network configuration, or a custom DNS setting overriding the VPN's own. But regardless of the cause, the practical effect is the same: whoever operates the leaking DNS server can see which sites you're looking up, which is exactly the kind of visibility a VPN is generally expected to prevent.

How do you check for a WebRTC leak?

WebRTC leaks are a separate issue from DNS leaks, though the two get mentioned together often enough that it's worth being clear on the difference. WebRTC is a browser technology used for real-time features like video calls directly in a browser tab, and under some circumstances it can reveal a device's real IP address directly to a website, through a mechanism that has nothing to do with DNS resolution and can bypass a VPN entirely.

How do you actually test for it?

1. Connect to your VPN.
2. Visit a browser-based leak testing tool that specifically checks for WebRTC. Many of the same sites used for DNS leak testing include a WebRTC check on the same page, usually clearly labeled.
3. Compare any IP address shown in the WebRTC section against your real, non-VPN IP address. If your actual IP address — the one you noted before connecting to the VPN, or the one your ISP assigned you — shows up anywhere in the WebRTC result, that's a leak, even if the rest of the page (your general connection IP, your DNS servers) looks completely clean.

Because this is a browser-level behavior rather than a network-level one, the fix is usually different from a DNS leak fix, too: disabling WebRTC in your browser's settings, or using a browser extension built for this specifically, rather than adjusting anything in the VPN app itself. It's also worth testing in each browser you use regularly, since WebRTC behavior and settings can differ from one browser to the next even on the same device and the same VPN connection.

Should you trust your VPN provider's own built-in checker, or use an independent site?

A growing number of VPN apps now include some version of these checks built directly into the app itself — an IP display, a "DNS leak protection: on" indicator, sometimes even a one-tap leak test. These built-in checks are convenient, and there's no reason to assume a reputable provider is being dishonest by including one. But it's worth understanding a basic limitation: a check that's built and run entirely by the same company whose product it's checking isn't the same thing as an independent check, in the same way that a company reporting its own uptime is different from a third party independently monitoring it.

In practice, the more useful approach is to use both, for different reasons. A provider's own built-in indicator is a reasonable quick glance for everyday reassurance — if it flags a problem, that's worth taking seriously immediately. But for a genuine, independent confirmation, running the checks in this guide through separate, independent websites (ones with no relationship to your VPN provider) gives you a result that isn't shaped by the same company's incentives around how its own product's status is displayed. This matters most the first time you're verifying a new VPN, and any time you're about to rely on it for something where being wrong actually costs you something.

It's also reasonable to cross-check between two or more independent testing sites rather than relying on just one, since occasionally a specific testing tool has its own bugs, outages, or geolocation database quirks that produce a misleading result unrelated to your VPN at all. If two independent sites agree, that's a meaningfully more trustworthy result than either one alone; if they disagree, that disagreement itself is worth investigating rather than picking whichever result you'd prefer to believe.

Does a VPN speed test tell you whether it's working?

Not directly, and it's worth being clear about what a speed test can and can't tell you. Running a standard internet speed test while connected to a VPN will show you a download and upload number, and comparing that against your normal, non-VPN speed gives you a sense of how much overhead the VPN is adding — some slowdown is normal and expected, since encrypting traffic and routing it through an extra server always costs something. But a speed test on its own doesn't confirm your traffic is actually private, that DNS isn't leaking, or that a kill switch will work — a VPN can produce a perfectly reasonable speed test result while still failing every one of the other checks in this guide, because a speed test only measures throughput between your device and the test server, not what path your traffic actually took to get there or what happens to it along the way.

Where a speed test is genuinely useful is as an indirect signal: a connection that's dramatically slower than expected, or one where speed fluctuates wildly between two otherwise identical tests a minute apart, can be a sign that the VPN connection itself is unstable — which is worth knowing, because an unstable tunnel is more likely to drop unexpectedly, which is precisely the scenario a kill switch test is meant to check. Treat a speed test as a useful secondary data point about connection quality, not as evidence about privacy or security on its own.

What are the most common mistakes people make when testing a VPN?

A handful of avoidable mistakes account for a lot of the confusing or misleading test results people run into.

Testing immediately after connecting, before the tunnel has fully stabilized. Some VPN apps show a "connected" state a second or two before the underlying tunnel and DNS routing have fully settled, especially right after switching servers. Waiting ten or fifteen seconds after the app reports a connected state, before running any of the checks above, avoids a false negative caused purely by timing.

Using a browser tab that was already open before connecting. Some browsers cache DNS results and connection information per tab or per session. Opening a fresh browser tab — or, to be extra sure, a private/incognito window — for each check after connecting to the VPN avoids a stale cached result being mistaken for a live one.

Only testing once and assuming the result applies forever. A single clean IP, DNS, and kill switch check confirms your setup was working at that specific moment, on that specific network, with that specific app version. It doesn't automatically extend to a different server, a different network, or a future app update, which is why the "how often should you re-test" guidance later in this guide matters as much as the initial test itself.

Confusing "the app looks fine" with "I ran a check." This is the core confusion this whole guide is addressing: a visual status indicator and an actual test are not the same thing, no matter how confident the app's interface looks. If you haven't actually visited an IP-checking site, a DNS leak testing site, and deliberately forced a disconnection at least once, you haven't actually tested the VPN yet, regardless of how long it's been showing "connected."

Testing only on one device and assuming every device behaves identically. A VPN app can behave differently across a phone, a laptop, and a router-level setup, particularly around DNS and kill switch handling. A clean result on a laptop doesn't guarantee the same result on a phone using the same VPN account, so it's worth running at least the IP and DNS checks separately on each device you actually rely on the VPN with.

How do you test a VPN configured at the router level?

Running a VPN at the router level — so every device on a home network is covered automatically — is a setup covered in more depth in our guide on VPN use at the router level. Testing it follows the same core logic as testing a normal VPN app, with a couple of adjustments worth knowing.

Run the IP address and DNS leak checks from a device connected through the router — a laptop or phone on that network's Wi-Fi — rather than assuming router-level coverage automatically means every connected device is protected. Because the VPN connection lives on the router itself rather than in an app on each device, there's no per-device "connected" indicator to glance at, which makes running the actual IP and DNS checks more important, not less, since it's the only direct confirmation available. It's also worth testing more than one device on the network, particularly devices like smart TVs or streaming boxes that can't run a VPN app of their own and rely entirely on the router-level connection — a device with its own hardcoded DNS settings can sometimes bypass a router's VPN configuration in ways a standard laptop or phone wouldn't.

A router-level kill switch test works a little differently, too: instead of toggling Wi-Fi or ending an app process on a single device, you'd typically need to interrupt the router's VPN connection itself (through the router's admin interface, if it exposes a way to do that) and then check whether connected devices lose internet access entirely or quietly fall back to an unprotected connection — the same pass/fail logic as the device-level kill switch test, just applied at the network level instead.

How do you test whether your VPN's kill switch actually works?

A kill switch is a VPN feature meant to block all internet traffic automatically if the encrypted tunnel drops unexpectedly, rather than silently letting your device fall back to your normal, unprotected connection. It addresses a different failure mode than the checks above: not "is the VPN working right now," but "what happens the moment it stops working." A kill switch is also one of the few VPN features that's genuinely hard to verify passively — you generally have to force a disconnection on purpose to see what actually happens.

How do you run this test?

1. Turn on the kill switch setting in your VPN app, if it isn't already on. Not every VPN app enables this by default, and some require it to be turned on explicitly in the settings menu.
2. Connect to your VPN as normal, and open something that will clearly show if your internet connection stays alive — a page that auto-refreshes, a video call, or simply an IP-checking site you can reload.
3. Force the VPN connection to drop. There are a few reasonable ways to do this: turn off Wi-Fi briefly and turn it back on before the VPN has a chance to reconnect, disconnect from your network entirely for a moment, or — on a desktop system, if you're comfortable doing so — end the VPN app's process directly through your system's task manager or activity monitor rather than closing it through the app's own interface.
4. Watch what happens to your internet access in that moment. With a working kill switch, your internet access should stop entirely until the VPN reconnects or you manually restore your regular connection — pages should fail to load, calls should drop, and reloading the IP-checking site should simply fail rather than show your real IP address.
5. If your internet keeps working smoothly through the disruption, reload the IP-checking site immediately and check whether it shows your real IP address rather than the VPN's. If it does, the kill switch didn't engage, and your device briefly (or not so briefly) fell back to an unprotected connection without any clear warning.

This is one of the more overlooked checks precisely because it only matters in a moment most people never deliberately create — a sudden disconnection. For anyone relying on a VPN somewhere the gap matters, such as on public Wi-Fi covered in our guide to VPNs for public Wi-Fi, or in a higher-stakes context like the ones discussed in our guide for journalists, confirming the kill switch actually does what it claims — rather than assuming a setting labeled "kill switch" automatically works as described — is worth the two minutes of deliberate testing.

How do you test if your VPN is working on a phone or tablet specifically?

The core checks above — IP address, DNS, and kill switch — apply the same way on mobile as on a desktop or laptop, but a couple of things are worth knowing specifically for phones and tablets.

Run the IP and DNS checks in your phone's browser, not just on a desktop. A VPN app can behave slightly differently on mobile than on desktop, particularly around how aggressively the operating system manages background network connections, so a clean result on one device type doesn't automatically guarantee the same result on the other. It's worth running the same IP-checking and DNS leak testing sites directly in your phone's browser while connected to the VPN.

Watch for the VPN silently disconnecting when switching between Wi-Fi and mobile data. Phones and tablets switch network types more often than most desktop devices — moving from home Wi-Fi to mobile data when you leave the house, for instance — and a VPN connection can sometimes drop during that switch without a clear notification, especially if the app doesn't have a reliable auto-reconnect feature. If you rely on a VPN on mobile in situations where a silent drop matters, it's worth deliberately testing what happens to the VPN's connected status when switching between Wi-Fi and mobile data, similar to the kill switch test above.

Confirm whether your phone's kill switch equivalent is actually enabled. Mobile operating systems sometimes implement VPN kill switch functionality slightly differently than desktop apps do, occasionally as a separate operating-system-level setting (sometimes labeled something like "block connections without VPN") in addition to, or instead of, a setting inside the VPN app itself. It's worth checking both places rather than assuming the in-app toggle is the only place this is controlled.

Does testing a browser-extension VPN differ from testing a full VPN app?

It does, in a way that's worth knowing before you assume a browser extension is covered by the same checks as a full VPN app. Our guide comparing browser extension VPNs and full VPN apps goes into the broader tradeoffs; the testing-specific point is narrower: a browser extension VPN generally only protects traffic inside that one browser, not your device's other apps, background processes, or other browsers you might have installed.

That changes how you should interpret a test result. Running an IP address check in the same browser the extension is installed in will usually show the VPN's IP correctly, which is a valid result for that browser specifically — but it tells you nothing about whether your device's other traffic (a separate browser, a desktop app, a background sync service) is protected, because a browser extension was never routing that traffic through the VPN in the first place. If you're testing a browser extension VPN, it's worth deliberately checking a second browser you haven't installed the extension in, and confirming that traffic there shows your real IP address as expected — not as a failure, but as confirmation you understand the actual scope of what's being protected.

Kill switch testing is also different, and often more limited, for browser extensions. Many browser-extension VPNs don't offer a true kill switch at all, or offer one that only blocks traffic within that browser rather than the whole device, since the extension has no visibility into or control over traffic outside the browser it's installed in. Checking the extension's own documentation for whether it claims kill switch functionality — and, if so, exactly what scope it covers — is worth doing before assuming the device-level kill switch test described earlier applies the same way.

What other signs suggest your VPN might not actually be working?

Beyond the deliberate checks above, a few everyday signals are worth paying attention to, even though none of them are proof on their own the way a direct IP, DNS, or kill switch check is.

Streaming or shopping sites showing your actual local region. If you connect to a VPN server in one country but a website consistently shows you pricing, language, or content tied to your real location instead, that can indicate the site is detecting your real IP through some path other than the VPN, though it can also simply mean the site is using signals besides IP address (like account settings or a stored cookie) to determine your region — it's a signal worth investigating with a direct IP check rather than a conclusive result by itself.

Emails or account logins triggering unexpected "new location" security alerts, or, conversely, security alerts stopping when they normally wouldn't. Some online services send alerts when they detect a login from an unfamiliar location. Getting one immediately after connecting to a VPN server in a new country is actually a mildly reassuring sign that the service is seeing your VPN IP rather than your real one; never getting this kind of alert despite connecting from genuinely new VPN locations could mean the opposite.

A VPN app that reconnects unusually often, or briefly shows a disconnected state without you noticing until later. Frequent silent reconnections are exactly the kind of moment a kill switch is meant to cover, and they're also a reasonable prompt to re-run the IP and DNS checks, since a connection that's dropping and reconnecting often is more likely to have briefly exposed your real traffic during one of those gaps.

A noticeably higher volume of ads, or oddly specific location-targeted ads, right after connecting. This one is more anecdotal than diagnostic, but some users notice ad targeting shifting to match their VPN server's location shortly after connecting, and staying shifted to their real location if something's off. It's a soft, unreliable signal on its own — ad networks use many signals besides IP address — but it can be a prompt to run a direct check if you notice a pattern over time.

None of these everyday signals substitute for the direct checks earlier in this guide — they're reasons to go run those checks again, not conclusions on their own.

How often should you actually re-test your VPN?

There's no single schedule that fits everyone, since how much this matters depends on why you're using a VPN in the first place. A reasonable baseline: run the full set of checks once after first setting up a new VPN app, again after any major app or operating system update (an update can change how DNS or kill switch handling behaves, for better or worse), and again any time you're connecting from an unfamiliar network — a hotel, an airport, a new office — where you're leaning on the VPN more than usual.

For everyday, lower-stakes use, an occasional spot-check is mostly about peace of mind rather than a strict necessity. For higher-stakes use — protecting sensitive work, or any situation where exposure carries a real personal cost, along the lines of what's discussed in our guide to VPNs for activists — testing more deliberately, and specifically before any session where it matters most, is worth the small amount of extra time it takes.

What should you do if a test shows your VPN isn't working correctly?

Finding a problem with one of these checks isn't a reason to panic, but it is a reason to stop treating the VPN as protective until it's fixed. A few sensible next steps, depending on what the test revealed:

If your IP address didn't change at all, start with the basics: confirm the app genuinely shows a connected state (not just "connecting"), try disconnecting and reconnecting fully, and try a different server location to rule out an issue with one specific server. If the problem persists across servers, checking for an app update, or reinstalling the app, is a reasonable next step.

If you found a DNS leak, check for a DNS leak protection setting in the app's settings menu specifically (some apps expose it as an explicit toggle rather than assuming it's always on), and consider whether IPv6 or a custom DNS service you've configured separately could be overriding the VPN's DNS assignment. Our DNS leaks guide covers the specific causes and fixes in more depth.

If you found a WebRTC leak, the fix is generally in your browser rather than the VPN app: check your browser's settings for a WebRTC-related option, or use a browser extension built to disable or restrict it, then re-run the test in that browser specifically.

If your kill switch didn't engage, confirm it's actually turned on in the app's settings (this is easy to assume rather than verify), and check whether your VPN app has more than one kill switch mode — some offer a stricter, more aggressive setting alongside a lighter default one.

If a problem persists after trying the obvious fixes, that's worth treating as a real signal about that specific provider's app on your specific device and network, rather than something to keep working around indefinitely. Our individual provider reviews — including our NordVPN review, Proton VPN review, PureVPN review, and FastestVPN review — are a reasonable starting point if you're weighing whether to stick with a provider or look elsewhere.

Practical takeaway

A VPN app's "connected" indicator is a useful at-a-glance signal, but it only confirms that the app itself believes a tunnel is up — it isn't independent proof that your IP address, DNS requests, browser traffic, and behavior during an unexpected disconnection are all actually handled the way you'd expect. Testing whether your VPN is working means checking those things directly: an IP address check to confirm your visible IP and location actually change, a DNS leak test to confirm DNS requests are staying inside the tunnel, a WebRTC check to rule out a separate browser-level exposure, and a deliberate kill switch test to see what genuinely happens if the connection drops. None of these take more than a couple of minutes individually, and together they take less time than most people spend deciding which VPN server to pick. Run them once after setting up a new VPN, and again after any meaningful change — a new device, a new network, an app update — rather than treating a single clean result as a permanent guarantee.