Before testing anonymity, confirm the VPN is actually connected in the first place — if you're not sure the tunnel is even up, start with how to check that a VPN is working. This guide is the next step: even a working VPN connection can have a hidden leak that exposes real data anyway. You can check the current app build with verified leak protection on the LiMP VPN features page.
\n\nWhat a full VPN anonymity check includes
A full anonymity check isn't one test — it's a set of six independent checks, each catching a different kind of leak. Skipping any one of them leaves a gap a website or a network observer can use to identify you.
- IP address and exit country — shows which address and location websites actually see instead of your real one.
- WebRTC leak — a browser technology that can expose your real IP even while a VPN is active.
- DNS leak — checks whether domain-name lookups travel through the tunnel or bypass it to your ISP.
- IPv6 leak — a separate protocol that a VPN sometimes doesn't intercept, leaving a parallel unprotected channel.
- Browser fingerprint — a set of device and browser characteristics that can identify you with no IP address at all.
- Kill Switch — blocks internet access the moment a VPN connection drops, so traffic never reaches the open network.
- No-logs policy — whether the VPN provider itself stores data that could later de-anonymize you.
| Test | What it checks | Where to see the result |
|---|---|---|
| IP address & geo | Whether sites see your real IP and country | An IP-lookup service, before and after connecting the VPN |
| WebRTC | Whether the browser exposes your real IP via a WebRTC request | An online WebRTC leak test in the browser |
| DNS | Whether DNS queries travel through the VPN tunnel or go to your ISP directly | A DNS leak test, with the list of resolvers in the result |
| IPv6 | Whether a parallel IPv6 channel stays outside the tunnel | A dedicated IPv6 check, run separately from the IPv4 test |
| Browser fingerprint | How unique your device/browser profile is | A browser fingerprint testing service |
| Kill Switch | Whether internet access is blocked when the VPN connection drops | Manual — kill the VPN process and check network access |
Checking your IP address and exit country
The first and most basic test is comparing the IP address and location that websites see against your real one. If, after connecting the VPN, a site shows the VPN server's country instead of your actual location, the basic masking is working. If the geolocation still matches your real one, or the address doesn't change at all, the VPN either isn't connected or traffic is bypassing the tunnel.
How to compare your IP with and without VPN
Open any IP-lookup service in your browser while the VPN is off, and note (or screenshot) the IP and city it shows. Then turn the VPN on, connect to a server in the country you want, and reload the test page in a new tab — reloading matters, since a cached result tells you nothing. The IP address should change completely, and the geolocation should match the connected VPN server's country, not your real one.
\n\nHow to check for a WebRTC leak
WebRTC is a built-in browser technology for video calls and real-time data exchange that, by design, can exchange IP addresses directly between devices, bypassing system-level network settings — including a VPN. That's exactly why WebRTC is one of the most common reasons a VPN shows one IP in the address bar while a hidden browser request leaks a completely different, real one.
To check for the leak, open a dedicated online WebRTC leak test while the VPN is on. If your real public IP address shows up in the results — not just the VPN server's address — the leak is confirmed.
What to do if your real IP is visible through WebRTC
The first step is disabling WebRTC in your browser settings or via an extension that blocks it; in Firefox this is done through the media.peerconnection.enabled flag in about:config, while Chromium-based browsers need a dedicated extension since there's no built-in toggle. The second step is making sure the VPN client itself intercepts WebRTC requests at the system level, rather than leaving it entirely to the browser. A full breakdown of this leak's mechanics and step-by-step fixes for different browsers is in WebRTC leak: how a browser exposes your real IP.
\n\nHow to check for a DNS leak
A DNS query is a request to a server that turns a site's name (like example.com) into an IP address. If the VPN encrypts only your main traffic but doesn't route DNS queries through its own tunnel, those queries keep going straight to your ISP's DNS server. In that case, your ISP sees the full list of domains you visit, even if the page content itself is hidden by the VPN.
The check is simple: open a dedicated DNS leak test while the VPN is on and run the extended test. The results should show DNS servers belonging to the VPN provider itself (or its partners), not the servers of your home or mobile ISP.
How a DNS leak differs from a WebRTC leak
Both leaks expose data outside the VPN tunnel, but in different ways. WebRTC directly reveals your IP address through a real-time browser protocol. A DNS leak doesn't show an IP at all — instead, your ISP or an outside DNS server sees the list of domains you're requesting, which also exposes activity, but through a different channel with different privacy consequences. The full breakdown of causes and fixes specifically for DNS leaks is in DNS leak: how to check and fix it.
\n\nIPv6 leak — the separate test people often forget
Many VPN clients tunnel only IPv4 traffic, leaving the parallel IPv6 protocol completely unprotected — and if your device and network support IPv6 (most modern operating systems and ISPs do), some requests can travel directly over IPv6, bypassing the VPN tunnel entirely. This isn't a special case of a DNS or WebRTC leak — it's a separate data channel with its own address.
This is checked with a dedicated online IPv6 address test, specifically a separate one, because a standard IP checker often shows only the IPv4 result by default and creates a false sense of full protection. If the test shows your real IPv6 address while the VPN is on, protection is incomplete. The most reliable fix is disabling IPv6 entirely at the network adapter level, or confirming the VPN client you use blocks IPv6 traffic outright rather than simply ignoring it. A detailed walkthrough for different operating systems is in IPv6 leak: how to check and disable it.
\n\nBrowser fingerprint: can sites tell you're using a VPN
Even with a perfectly hidden IP address, a site can still identify you by your digital fingerprint — a unique combination of browser and device characteristics: version and fonts, screen resolution, time zone, installed extensions, graphics rendering parameters. This combination is specific enough that, for most users, the fingerprint stays practically unique even with zero cookies, and even if the IP address is different every time.
You can check your own fingerprint through a dedicated browser fingerprinting service — it shows how unique your specific parameter combination is among all visitors. A VPN doesn't reduce this uniqueness: it hides your network address, not your browser's parameters. What exactly builds the fingerprint and how to reduce its uniqueness is covered in browser fingerprint: what it is and how to check it.
\n\nKill Switch — does it trigger when the VPN drops
Kill Switch is a feature that automatically blocks all internet access on the device the moment a VPN connection drops unexpectedly, without waiting for the app to reconnect. Without it, when a VPN drops, traffic instantly and invisibly falls back to the open network directly — right at the moment protection matters most, since drops usually happen exactly when switching networks, Wi-Fi, or servers.
How to manually test Kill Switch
The test takes a couple of minutes and needs no special tools — just the VPN client itself and an open tab with an online IP test.
- Connect to the VPNOpen the app, pick any server, wait for "connected" status, then open an IP-lookup service in your browser and note the address shown — it should be the VPN server's address.
- Break the connectionForce-quit the VPN client process via task manager, or disable the network adapter for a few seconds, without using the app's own "Disconnect" button — this simulates a genuine unexpected drop rather than a clean disconnect.
- Check network accessTry to load any website right after the drop. If Kill Switch works, internet access should be completely blocked until the VPN connection is restored — no site should load.
- Check your IP at the moment of the dropIf network access still worked (say, a page partially loaded), refresh the IP-lookup tab. If your real address shows up instead of the VPN server's, Kill Switch didn't trigger and traffic briefly reached the open network unprotected.
A deeper look at how this feature is implemented technically, and why even a reliable VPN doesn't guarantee continuous anonymity without it, is in what is VPN Kill Switch.
\n\nChecking the no-logs policy
No-logs means the VPN provider itself doesn't store data about your activity: which sites you visited, what your real IP was at the time of connecting, how long a session lasted. Even if all five technical tests above pass perfectly, trust in a VPN still rests on the provider not keeping its own log that could theoretically be requested, or that could leak if its servers were breached.
You can't verify a no-logs policy directly through a technical test — it's not a technical leak, it's a matter of trusting the provider, its jurisdiction, and its public privacy policy. Indirect signs of a provider taking no-logs seriously: an independent third-party audit of the logging policy, a jurisdiction without mandatory data handover to regulators, and clear, specific wording in the privacy policy about exactly what data isn't collected at all — rather than vague language. How to actually verify a VPN's good faith on this criterion is covered in no-logs VPN: how to verify it in practice.
\n\nSpeed and latency — are they part of the anonymity test too?
Connection speed has no direct effect on anonymity: a slow VPN tunnel protects you exactly as well as a fast one, as long as all six tests above pass. But in practice, speed and latency determine whether you stay protected by the VPN all the time, or end up turning it off "just for a minute" now and then — and those exact minutes without a VPN are usually where real data actually leaks.
If a connection noticeably slows down video or calls, the temptation to manually disconnect the VPN hits hardest exactly during active internet use — when privacy matters most. So stable speed isn't the goal in itself; it's the practical condition for protection staying on all the time, not just during tests. How to measure your actual VPN speed and what numbers to expect is in how to check VPN speed.
\n\nWhat to do if your VPN fails the anonymity test
If at least one of the six tests reveals a leak, the next steps are the same regardless of which test failed — the goal is fixing the cause, not just re-running the check and hoping for a different result.
- Switch the connection protocolIn the app's settings, switch to a different available protocol — some protocol implementations in a given client intercept system traffic worse than others.
- Switch serversIndividual servers in a provider's infrastructure can be misconfigured for DNS or IPv6 while the rest of the network works fine.
- Turn on Kill Switch and leak protection in settingsMost modern clients have separate toggles for blocking WebRTC, DNS, and IPv6 leaks — check that they're actually turned on rather than assuming they are.
- Change DNS manuallyIf built-in DNS leak protection doesn't help, set the VPN provider's DNS servers (or a trusted public third-party DNS) directly in the device's network settings.
- Contact the provider's supportA leak that repeats across different servers and protocols is a reason to write to support with your test results, rather than writing off the VPN entirely.
If leaks keep happening systematically regardless of settings, it's worth reconsidering the VPN provider itself — criteria for reliability from a leak-protection standpoint are covered in the safest VPN: how to choose one.
\n\nHow often should you check VPN anonymity
Not on every single connection — but after three specific events, a check is a must. First: after updating the VPN app or the operating system, since an update can reset leak-protection settings back to defaults. Second: after switching servers or protocols — different servers and protocols from the same provider can behave differently. Third: if you use a VPN constantly as your main privacy tool, a monthly preventive check is worth doing even with no visible changes to your settings.
\n\n
