VPN leaks and disguise checks
A leak is any reading about you that escapes the tunnel a VPN builds: a value that still travels by its old route, or that a web page can ask your browser for directly, bypassing the tunnel altogether. A disguise check is the companion test: a site takes every reading it can collect — address, clock, language, hardware, resolver — and compares them against each other, looking not for secrets but for contradictions. A disguise rarely fails because one value looks wrong. It fails because two values that should agree do not. Run both halves yourself in the Browser Fingerprint Test, and read what websites know about you for the full inventory of readings a page can take before you change a single setting.
A VPN changes exactly one thing
A VPN does one mechanical job, and it does it well: it wraps your traffic in an encrypted tunnel to an exit server, and the sites you visit see that server instead of you. Your public IP address changes. The city and country attached to that address change with it. The network that owns the address — usually a hosting company or a VPN provider rather than a home broadband line — changes too. If your only question was “which address does this site think I am coming from?”, a working VPN answers it completely, and nothing in this article contradicts that.
Everything else stays exactly where it was. Your device does not move: its screen size, graphics chip, installed fonts, battery behaviour, audio stack and the dozens of small hardware and software readings that combine into a browser fingerprint are identical before and after the tunnel opens. Your clock does not move, so your system timezone still reports the place you actually are. Your browser and operating system languages do not move. Your cookies, your logged-in accounts and your browsing history do not move. The tunnel re-routes packets; it does not redecorate the machine at the end of them.
That split is why most “VPN detection” is badly named. In the common case nobody has detected a VPN protocol, a tunnel or an encrypted connection. They have detected a mismatch: the IP address claims one country while the clock claims another, the address belongs to a data centre while the fingerprint describes a home laptop, the language list describes a traveller who never travels. Sites score the gap between the layer that moved and the layers that did not. Understanding leaks, then, is not really about the tunnel at all — it is about auditing everything the tunnel left behind.
WebRTC: the address that walks around the tunnel
WebRTC is the browser technology behind in-page voice, video and peer-to-peer data. To connect two browsers directly it must first discover how each one can be reached, and that discovery process is called ICE. In plain terms, your browser gathers candidates — possible addresses for itself — and offers them to the other side. It learns some by asking itself, and others by asking a STUN server a simple question: “from where you sit, what address am I calling from?” The answers come back as different candidate types, and the difference between them is the whole leak story.
A host candidate is an address your machine holds directly: historically, your local network address, such as the 192.168 address your router gave you. A server-reflexive candidate is the public address the STUN server observed — the address the outside world sees. When WebRTC was new, pages could collect both freely, which produced two classic leaks: the LAN address escaped even though it was useless to the site, and worse, when a browser asked the STUN server outside or alongside the VPN tunnel, the reflexive candidate revealed the real public address behind the disguise. The VPN was working perfectly for web traffic while a side channel quietly published the thing it was hiding.
Modern browsers have narrowed this a great deal. Chrome and Firefox now commonly replace host addresses with random mDNS names — a rotating .local hostname instead of your real LAN IP — so a page sees a candidate it cannot map back to your router. Implementations differ by browser and version, some route WebRTC through the tunnel correctly, and corporate or extension-modified setups differ again, which is why two honest tests can disagree. Treat blunt fixes with care: disabling WebRTC entirely stops the leak and also breaks legitimate calls, while extensions that promise to “spoof” candidates often replace a plausible address with an implausible one — and an implausible candidate is itself a contradiction a disguise check can score.
DNS: the resolver that stayed home
Every name you visit has to be translated to an address before anything connects, and that translation is done by a resolver. If your browser or system keeps using the resolver your internet provider assigned — reached directly, outside the tunnel — then every lookup leaks in two ways at once. The queries themselves go to your ISP in the clear pattern of ordinary DNS traffic, revealing which names you resolve even though the pages that follow travel through the VPN. And any site that can observe which resolver asked on your behalf learns where you roughly are, because people overwhelmingly use a resolver near their real location.
That second leak is subtler than it sounds, and the standard test for it is elegant. A test page makes your browser look up a name that has never existed before — a long random subdomain under a domain the tester controls. Because the name is unique, no cache anywhere holds it, so your resolver is forced to ask the tester’s authoritative server directly. That server now sees the resolver’s address, and can report its network and its country back to the page. Variants using EDNS client-subnet information can narrow things further, because some resolvers helpfully forward part of your own address range along with the query. None of this requires breaking the tunnel; it only requires your lookups to take a different road from your pages.
The traps are mostly configuration, not malice. Split-tunnel setups deliberately send some traffic — often including DNS — outside the VPN for speed or local access. Routers that hand out the ISP resolver to every device keep doing so while the VPN runs on one of them. Browsers with their own encrypted-DNS settings may bypass both the system and the VPN provider’s resolver, fixing one leak while quietly creating a consistency problem if the new resolver sits in a different country from the exit. The working rule mirrors the rest of this article: the resolver should live where the exit claims to live, and it should be reached through the tunnel, and the only way to know either is true is to test it from the outside.
Contradictions: the disguise that argues with itself
Consider four readings a page can take in a second. Your IP address places you in Amsterdam. Your system timezone reports UTC−5 and a city in the Americas. Your browser’s language list is headed by a language rarely spoken in the Netherlands, with no Dutch anywhere in it. And your user agent claims a Windows desktop while your graphics renderer names a mobile chip. No single one of these values proves anything — travellers, expatriates, virtual machines and odd configurations produce each of them innocently every day. Taken together, they argue. A disguise check is simply a machine for listening to that argument and assigning it a weight.
Some contradictions recur so often they have become the standard battery. Timezone versus IP country is the loudest, because the clock is trivial for a page to read and most VPN users never think to change it. Language versus IP country is softer — people legitimately browse in a second language — but a complete absence of the exit country’s language still counts. User agent versus platform catches crude spoofing: a string claiming one operating system while touch support, screen shape or the GPU renderer describes another. Hosting ASN versus a residential story is the quietest and often the most decisive: the exit address belongs to a data-centre network, while everything else about the session describes an ordinary home user who, in reality, would be arriving from a broadband provider.
This is why consistency, not any single value, is what sites actually score. A fraud system, an abuse filter or a streaming catalogue rarely needs to prove a VPN exists; it needs a risk number, and contradictions are cheap, robust evidence to feed one. A session whose address, clock, language, resolver and hardware all tell the same story may still be a VPN session — but it presents no internal argument to score against, so it is processed like the story it tells. Conversely, a user with no VPN at all can score badly through sheer messiness: a work laptop imaged in another country, a browser left in a foreign language, a corporate resolver on another continent. The check measures coherence. It was never really measuring the tunnel.
A checklist for looking consistent
Work in the order a checker reads you. Choose the exit country first, deliberately, and let everything else follow it — consistency with a place you picked beats a random exit dressed up afterwards. Set the system timezone to match that country, not just the browser clock, because pages read the system zone. Align the browser language: put the exit country’s language first or at least present in the list, and browse in it where you can. Each step removes one argument between layers, and together they cover the contradictions sites check most.
Then close the side channels. Keep WebRTC inside the tunnel or, if you never use in-browser calls, off entirely — and re-check which behaviour your browser actually has rather than assuming. Make sure DNS resolves through the tunnel to a resolver that fits the exit story, and prefer a residential exit when the story you present is a residential one, because no clock setting fixes a data-centre ASN. After every single change, re-run the Browser Fingerprint Test and read it the way a site would: not hunting for one red flag, but asking whether the whole page tells one story. For why a test like this can be run without collecting the readings it shows you, see how a privacy test keeps no data.
End with the honest caveat, because a checklist that promises invisibility is lying to you. Consistency removes contradictions; it does not remove identity. Your browser fingerprint — the combination of hardware, fonts, graphics and settings that stayed put in section one — can still single out your device across visits and across addresses, and your behaviour, accounts and habits identify you more reliably than any network reading ever did. A coherent disguise raises the cost of casual detection and stops the easy, automated kind. Against a determined observer who can watch behaviour over time, it was never a guarantee, and any tool or provider that sells you one should be trusted less, not more.