Is My VPN Working?

A VPN test checks that your traffic really leaves through the VPN server. A complete one covers five things: the IP address and location websites see belong to the VPN server; WebRTC exposes no other public address; your device timezone doesn't contradict the server's location; DNS lookups go to the VPN's resolvers, not your ISP's; and the kill switch blocks traffic when the tunnel drops. The test above runs the first three in under a minute. The last two are not run here: vpnrank.io has no DNS leak test, and the kill switch has its own tool. Speed is a separate question, answered by our benchmark.

The first check is the fatal one. If websites can see your real IP address, nothing else the VPN does matters — encryption of a tunnel your traffic isn't using protects nobody. That's why the checker above starts there, and why our What Is My IP tool is the single most useful bookmark for any VPN user. Checks two and four are sneakier: your main connection is masked, but a side channel — the browser's WebRTC stack, or the operating system's DNS resolver — quietly reports back to your real network. A DNS leak matters because the resolver that answers your lookups sees which sites you use (RFC 9076). IPv6 is the other side door: if your VPN neither carries IPv6 nor blocks it, the IP in check 1 may be an IPv6 address from your own ISP, so look at whose address it is. When this test passes, finish with the DNS check and the kill switch test.

A VPN can look perfectly healthy — app open, button green, "Connected" in the menu bar — while protecting nothing. The status only tells you the software thinks a tunnel exists; it says nothing about what your traffic is actually doing. Here is where each system shows VPN status:

Every one of these confirms that a tunnel is up on that device. None of them shows what websites see, whether WebRTC or DNS leak around the tunnel, or whether split tunneling has left your browser outside it. That is the gap an outside check fills: the test above looks at your connection the way a website does, which is why it can say NOT CONNECTED while your app says Connected.

The verdict comes from two things: your answer to check 1 and the WebRTC result. The timezone check adds an advisory note but never changes the verdict, and a browser with no WebRTC at all counts as a pass, since it can't leak that way. Here is exactly what each verdict means and what to do next:

One honest caveat: no browser-based test can prove a VPN is perfect. We can see what your browser exposes to websites — which is what matters most — but we can't see inside your operating system's routing table or watch what happens when your Wi-Fi blips at 2 a.m. A WORKING verdict means you pass the checks any website could run against you right now. For the full picture of how a VPN behaves under stress, that's what our lab methodology is for, and our step-by-step guide to testing your VPN walks through every manual check in depth.

Check 1: IP and location — why we ask you

The first check fetches the public IP address your connection presents to every website, plus the city and country it geolocates to. Then it asks you a question no algorithm can answer: is that where you really are? Geolocation databases are accurate at country level but fuzzy at city level, and we have no way of knowing your true location — nor should we. You do, instantly. If the page says Amsterdam and you're on a sofa in Manchester, your VPN is masking you; if it names your actual city, it isn't. This human-in-the-loop step is more reliable than any datacenter-name heuristic, because some VPN exits deliberately use residential-looking addresses. To dig into any specific address — yours or a server's — use the IP address lookup.

Check 2: the WebRTC quick check

WebRTC is the browser technology behind in-page video calls. To connect two peers directly, it asks a STUN server "what address do I appear from?" — and historically, browsers would hand the answer, including your real IP, to any webpage that asked, even with a VPN connected. RFC 8828 names the VPN case directly: with a split-tunnel VPN, WebRTC can discover both the VPN's public address and the ISP address the VPN runs over. Our check runs the same request a malicious page would: it asks Google's public STUN server (stun.l.google.com) for your browser's WebRTC candidate addresses, waits up to 5 seconds, and compares any public ones against the IP from check 1. Private, link-local and carrier-grade NAT ranges (RFC 1918, RFC 6598) and anonymized .local mDNS names are ignored, because they identify nobody; a public address that matches check 1 is no leak either. Modern browsers use those mDNS names for local addresses, so most people pass — but a VPN misconfiguration can still expose the real address. If this check fails, the full WebRTC leak test shows every candidate address and the exact fix for your browser, and our WebRTC leak glossary entry explains the mechanism in depth.

Check 3: timezone consistency

Any website can read your device's timezone with a single line of JavaScript — Intl.DateTimeFormat().resolvedOptions().timeZone returns an IANA name such as Europe/Rome, with no permission prompt and no warning. Check 3 reads it and compares it with the timezone of the place your IP geolocates to. If your IP says New York but your device says Europe/Rome, a site fingerprinting its visitors knows something doesn't add up. This won't unmask your identity by itself, and it never changes your verdict — but it's exactly the kind of signal streaming platforms and payment processors use to flag VPN users. If passing as local matters for what you do, set your device timezone to match your VPN server's region before you browse.

Everything this page tests is a snapshot: your VPN's state right now. But VPN connections drop — when your laptop wakes from sleep, when you switch from Wi-Fi to mobile data, when a server restarts. In that gap, your operating system helpfully falls back to the regular connection, and every open app continues talking with your real IP. You usually notice nothing.

A kill switch closes that gap: it blocks all internet traffic the instant the tunnel dies, so nothing escapes unprotected while the VPN reconnects. It's the difference between a VPN that works when conditions are perfect and one that protects you when they aren't. Every provider we recommend ships one, but defaults vary — some enable it out of the box, others hide it behind a settings toggle. Turn it on, then verify it actually fires with our step-by-step VPN kill switch test. A kill switch you've never tested is a hypothesis, not a safety net.

If you leave this page with one habit, make it this: treat "VPN on" as a claim to verify, not a fact. The full routine is IP, WebRTC, timezone, DNS and kill switch. This page automates the IP, WebRTC and timezone checks; the DNS check and the kill switch test are the two extra steps in the five-check table near the top of this page.

Work through these in order — most failures resolve at step one or two:

1. Reconnect properly. Fully disconnect in the VPN app, wait five seconds, reconnect to a different server, then run this check again. Transient drops and half-dead connections cause most NOT CONNECTED verdicts.
2. Check split tunneling. If your VPN has a split tunneling or "bypass" list, make sure your browser isn't on it — a browser routed outside the tunnel shows your real IP no matter how healthy the VPN is.
3. Fix WebRTC. For a LEAKING verdict, install your provider's browser extension (most include WebRTC protection) or disable WebRTC in your browser's settings, then confirm with the full WebRTC leak test.
4. Enable the kill switch so the next silent drop doesn't expose you for minutes before you notice.
5. If it keeps failing, change providers. A VPN that repeatedly fails basic exposure checks is not worth troubleshooting forever. In our lab testing, NordVPN, ExpressVPN, and Surfshark passed every leak and kill switch test we threw at them; the complete comparison is in our best VPN rankings. All of our top picks offer 30-day money-back guarantees, so you can run this exact page against a new provider risk-free.