Tools · Leak test

Leak test

We verify that all traffic keeps to one protected route: IPv4 and IPv6 addresses, what WebRTC discloses, whether the time zone lines up.

Addresses our server sees you under

Main address Checking…

The address is resolved on our server against a local database and is not shared with third-party services.

Time zone

checking

Comparing the device clock with the zone by address.

DNS

Site-name lookups travel a separate channel and are checked on a separate page — on our own DNS server, no third-party services.

Check DNS

Where leaks come from

A VPN sends traffic out through its server, and sites see the server's address. A leak is when part of the requests goes out directly, bypassing the tunnel, and the real address shows anyway. The cause is almost always the same: one of the protocols was left unredirected.

The three usual suspects: IPv6 — the tunnel is up for IPv4 while the provider's IPv6 walks on its own; WebRTC — the browser's calling machinery, which learns your external address from an outside server; DNS — the “what address does this name have” lookups going to the provider's resolver.

How to read the verdicts

The “Addresses” block shows which addresses your requests reached us from — main, over IPv4 and over IPv6. With a working VPN all three should belong to the VPN server's network, not your provider's.

The verdicts below: “in order” — no bypass found; “leak” — an address was disclosed that shouldn't be in the connection; “inconclusive” — the comparison didn't happen, e.g. an address of a protocol we have no counter-measurement for. We don't turn inconclusiveness into alarm: scaring without data is a dishonest trick.

If a leak is confirmed

An IPv6 bypass closes in two ways: enable IPv6 support in the VPN client itself — or switch IPv6 off entirely in the network adapter settings. The second way is cruder but always works. If the client has a kill-switch for traffic outside the tunnel, turn it on.

WebRTC is fixed in the browser: Firefox — the media.peerconnection.enabled switch in about:config; Chromium browsers — an extension limiting WebRTC. Disabling it completely has a price: in-browser calls and conferences stop working.

Why everything is computed on our side

A leak test by definition handles a visitor's most sensitive datum — their real address. Forwarding it to somebody's API for a pretty city line would be odd for a privacy service, so geolocation is done by a local database on our server.

The WebRTC probe also runs through our own server: the browser needs an external peer, and most testers plug in a big corporation's public server. Ours is our own — a page about leaks must not create them. Results are not stored.

Questions and answers

It works, but doesn't cover part of the traffic. A leak means a specific protocol walks around the tunnel — usually IPv6 or WebRTC. The rest stays protected; what needs fixing is the bypass found.

On its own page. An honest DNS check needs our own authoritative zone server — we have one, and the “DNS check” page runs on it rather than on someone else's service.

That the comparison didn't happen. For example, the browser disclosed an IPv6 address and we have no IPv6 counter-measurement. In fact it may be a leak or may be normal — we won't claim either without data.

Not necessarily. If you make calls from the browser, you need WebRTC. It's enough that it shows the VPN server's address outward instead of yours — exactly what this page verifies.

A guarantee that the three main bypass channels are closed. The list isn't exhaustive: apps outside the browser live their own network lives, and this page cannot see their behaviour.

A connection without side doors

MeerGuard White covers traffic end to end, and this page will always show honestly if something goes wrong.

Open the Telegram botif Telegram opens for you

See my IP