How to Check If Your VPN Is Actually Working (3-Minute Test)

To verify a VPN is working: check your public IP shows the VPN location (not your city), run a DNS leak test to confirm lookups go through the tunnel, and run a WebRTC leak test to make sure your browser is not exposing your real IP directly. All three checks are free and take about three minutes total.

"Connected" in the app does not mean protected. A VPN can be up while your DNS queries still go to your ISP, or while your browser hands out your real IP through WebRTC. Three checks prove the tunnel end to end.

Check 1: Does the internet see the right IP? (30 seconds)

Open our What is my IP tool with the VPN connected. It should show:

  • The VPN server's location (the country you picked), not your city.
  • An IP that changes when you switch VPN locations.

If it shows your real city, the tunnel is not carrying your traffic at all — reconnect, or switch protocols. If it shows something odd like your mobile carrier's city while on Wi-Fi, you are probably behind carrier-grade NAT and the VPN is off.

Check 2: Are your DNS lookups leaking? (1 minute)

Every site you visit starts with a DNS lookup. If those lookups bypass the tunnel, your ISP still records every domain — while the padlock in your VPN app glows green.

Run the DNS leak test with the VPN on. The location it reports should match your VPN exit. The classic leak causes:

  • Manually configured DNS (e.g. your router pushing the ISP resolver) overriding the tunnel DNS.
  • Windows smart multi-homed resolution racing queries out of every interface — disable it via group policy or let your VPN client do it.
  • IPv6 lookups escaping a v4-only tunnel. Either your VPN handles IPv6 or it should disable it.

A well-behaved client pushes tunnel-internal DNS on connect — ours does on all three protocols — so there is nothing to configure.

Check 3: Is WebRTC exposing you anyway? (1 minute)

WebRTC — the browser tech behind video calls — gathers your device's IP addresses so peers can connect directly, and a website can trigger that gathering silently. It works below the VPN's browser-visible layer, so it deserves its own check.

Run the WebRTC leak test. You want to see either anonymized .local mDNS names or only your VPN exit IP. Seeing a different public IP than the VPN's means your browser is leaking around the tunnel:

  • Easiest fix: use a VPN whose app routes all traffic, WebRTC included (any full-device tunnel does).
  • Browser-level: Firefox lets you disable WebRTC (media.peerconnection.enabled); Chromium browsers need an extension to restrict it.

Bonus: the kill-switch test (30 seconds)

With the VPN on, toggle your Wi-Fi off and on. During the reconnect window, try to load a page. With a working kill switch, nothing loads until the tunnel is back — your traffic never falls back to the naked connection. If pages load instantly during the gap, your kill switch is off or broken.

What if a check fails?

  1. Reconnect the VPN and re-test — transient route races happen.
  2. Switch protocols (WireGuard ↔ OpenVPN ↔ IKEv2) — each behaves differently on unusual networks.
  3. Update the VPN app; leak fixes ship constantly.
  4. If it still fails, your provider's support should treat it as a bug — we do.

Frequently asked questions

My VPN says connected but my IP has not changed — why?

The tunnel came up but your routes did not — usually a split-tunneling setting, a second network interface, or a client bug. Reconnect, and if it persists switch protocols (e.g. WireGuard → OpenVPN).

How often should I re-test my VPN?

After every OS update, VPN app update, or browser change — and any time you join a new untrusted network. Leaks are almost always introduced by changes, not spontaneous.

Do these tests send my data anywhere?

Our tools run the checks against our own servers and store nothing. The WebRTC test runs entirely inside your browser.

Keep reading