PublicIPChecker

Guide

How to check if your VPN actually works

6 min read · Updated 2026-09-28

A connected VPN can still leak your real identity. Run the five-point test — IP change, IPv6, WebRTC, DNS and kill switch — and fix the specific failure you find.

The five-point test

"Connected" is a UI state, not a guarantee. The real question is whether your visible identity changed completely. Run this sequence, all from the home page where possible, so the checks live next to each other:

  1. IPv4 check — before and after connecting, the address, the ISP/organisation and the country must all differ.
  2. IPv6 check — the IPv6 row must show the VPN's address or "Not available". Your ISP's prefix there is a leak.
  3. WebRTC check — the browser panel must read "No leak detected".
  4. DNS check — a DNS-leak test page must show the VPN provider's resolver, not your ISP's.
  5. Kill-switch check — cut the network for ten seconds mid-session; the browser should fail to load, not fall back to your real connection.

Four out of five passing is not passing. Each failure has a name and a fix:

Failure 1: the IPv6 leak

Symptom: the IPv4 row changed, the IPv6 row still carries your ISP's prefix.
Why: the tunnel only carries IPv4 — a v4-only configuration, or a router that keeps sending v6 out the open line.
Fix: enable IPv6 handling in the VPN client (most do it now by default), or disable IPv6 on the interface while the tunnel is up. Details in IPv6 privacy extensions.

Failure 2: the WebRTC leak

Symptom: the WebRTC row shows your real public IP or a 192.168.x.x address.
Why: the browser's peer-to-peer candidate gathering reads your real network — the tunnel does not cover it.
Fix: restrict WebRTC in the browser (flags/policy on Chromium, an add-on, or a privacy-focused build). Full guide: what is a WebRTC leak.

Failure 3: the DNS leak

Symptom: the DNS-leak test names your ISP's resolver.
Why: the OS is still using the network profile's DNS servers instead of the tunnel's.
Fix: a VPN client that manages DNS, encrypted DNS (DoH/DoT) routed through the tunnel, or the per-app VPN mode on mobile. Guide: what is a DNS leak.

Failure 4: no kill switch

Symptom: you unplug the network, and pages keep loading — through your real IP.
Why: the client silently fell back to the open network when the tunnel dropped.
Fix: enable the kill switch in the client settings (or the OS network shield). Without it, every brief tunnel drop — and drops happen — exposes you mid-session.

Sanity note: after a clean test, your new IP is expected to be a datacenter IP — that is what a VPN exit is. "Verified datacentre" is the correct, healthy result, not a failure.

Expect re-tests after OS, browser and VPN updates, and after moving to a new network — leaks have a habit of returning quietly.

Frequently asked questions

Does the IP changing mean the VPN is working?

Necessary, not sufficient. The address can change while IPv6, WebRTC and DNS all still leak your real identity. Run the full five-point test.

My country didn't change after connecting. Is it broken?

Not necessarily — if you connected to a server in your own country (for speed), the country stays the same. Check that the IP, organisation and ASN changed, and pick another server if you want a different location.

How often should I re-test?

After VPN client updates, browser updates and OS updates, and whenever you change networks. A monthly spot check is a reasonable habit for heavy users.


Keep reading

Check any other IP address

Investigating a suspicious login, a spam email header or a server log entry? Run any IPv4 or IPv6 address through the same geolocation and proxy checks.