VPN before / after workflow

Is My VPN Working?

A VPN is working when four separately-routed signals agree: the public IP a site reads, the resolver that answers your name lookups, the candidates your browser offers over WebRTC, and whether IPv6 still reaches the open internet. They fail independently, which is why one of them looking right settles nothing.

Run VPN Leak Test Run full report

Visible signals Safe receipt Not a certification

Take the baseline first

Run the check with the VPN off and save it. Connect, then rerun in the same tab and the same browser profile, so the second reading is not also reporting a different extension set or a cold DNS cache.

Read the four signals together

Public IP route, DNS resolver ownership, WebRTC candidates and IPv6 visibility travel by four different mechanisms. Any one of them changing is not the answer; the four of them agreeing is.

Know what this cannot settle

This reads one browser session. It is not a provider audit, it says nothing about how a provider handles logs or legal requests, and MyIPScan does not rank providers.

The mechanism

Why the four signals fail independently

A VPN client redirects IP packets into an encrypted tunnel. Three of the four things you are checking do not travel as ordinary IP packets from that client's point of view, which is exactly why a tunnel can be up and working while one of them still reports your real network.

Public IP routeThe address a site reads off the connection itself. It changes the moment the tunnel carries your IPv4 traffic, which makes it the signal most likely to look correct while another one is wrong. It is a starting point, not a verdict.

DNS resolverName lookups leave through whichever resolver the operating system hands them to. On Windows, Smart Multi-Homed Name Resolution can put a query to several resolvers at once and take the first answer back, so a slower VPN resolver simply loses to your ISP's. What a DNS leak is.

WebRTC candidatesICE candidate gathering runs inside the browser process and asks the operating system directly for interface addresses. Those addresses travel inside the WebRTC negotiation rather than as ordinary packets, so a client that routes every packet correctly can still leave the browser free to volunteer the real one. What a WebRTC leak is.

IPv6 reachabilityMost consumer connections are dual stack. A client that tunnels IPv4 only leaves IPv6 traffic on the ISP path, so any IPv6-capable site sees your real address while every IPv4 check looks correct. The four leak types compared.

Reading the result

What each disagreement means

Compare the after-reading against your saved baseline and find the row that matches. The useful information is in which signals moved and which did not.

IPv4 changed, resolver still your ISPReview DNS. The usual causes are the Windows multi-homed fallback above, split tunneling that excludes the resolver, router-level DNS the client never overrides, and the unprotected gap while a dropped connection reconnects. DNS Leak Test.

IPv4 changed, WebRTC shows a public ISP candidateReview the browser rather than the client. Extensions, the WebRTC IP handling policy and the browser profile decide this one, and changing VPN server will not affect it. WebRTC Leak Test.

IPv4 changed, IPv6 still reaches the internetReview IPv6 handling. A client either carries IPv6 through the tunnel or blocks it outright; leaving it open on the ISP path is the failure mode. IPv6 Leak Test.

Nothing moved at allThe tunnel is not carrying this browser. Check whether what you connected is a browser extension or proxy rather than a system-wide tunnel, and whether split tunneling has the browser on the excluded list.

A .local hostname or a 192.168 address in WebRTCExpected, and not a public exposure. mDNS masking and private ranges describe the shape of your own network. The candidate worth reviewing is a public one that matches your ISP or carrier while a VPN is connected.

Everything moved but the country label looks wrongFrequently anycast routing or a stale geolocation database rather than a leak. Resolver ownership is the reliable signal here; a country mismatch on its own is weak evidence.

Scope

What these checks do not cover

Each of these is a real limit rather than boilerplate, and each one changes how much weight a result deserves.

The DNS check is resolver-signal, not packet captureIt queries public DNS-over-HTTPS resolver-signal endpoints together with a MyIPScan DNS Lookup API control. That surfaces resolver ownership clues; it is not authoritative capture of every query your device made.

One browser session, not the deviceOther applications, operating-system services and background updaters can route differently under split tunneling. A browser reading tells you about the browser.

Nothing about the providerMyIPScan does not test provider infrastructure, retention or handling of legal requests, and does not publish provider rankings. A result here describes your route today, not the company carrying it.

When you want all four signals plus browser context in one reading, the Public Exposure Report collects them into a single Safe Privacy Receipt. If the fingerprint traits are what you are actually trying to change, start from the browser privacy path instead.

Safe Receipt limits

Safe Copy keeps the comparison legible while removing the raw values: the IP addresses on both sides of the test, the exact city, raw DNS resolver addresses and raw WebRTC candidate strings. Use it when you send a before/after result to a provider's support desk.

Review the Safe Privacy Receipt model before sharing diagnostics.

FAQ

Questions this page answers

Why has my IP changed but DNS still shows my ISP?

Because name lookups do not follow the packets. The client redirects IP traffic into the tunnel, while the operating system decides separately which resolver answers a lookup. Windows multi-homed fallback, split tunneling, router DNS the client never overrode, and the gap during a reconnect all produce exactly this pattern.

Is a 192.168 address in a WebRTC result a leak?

No. Addresses in the private ranges, and mDNS-masked .local hostnames, describe your own local network and cannot be routed from outside it. The candidate that deserves review is a public address matching your ISP or mobile carrier while a VPN is connected.