Site Blocks You Only With the VPN On? Here's What It Sees

The shop loads fine at home and shows a wall of "unusual traffic" the moment the tunnel is up. A forum refuses to log you in, and a streaming page insists you are in a country you have never visited. None of that requires spyware. A site sees the address your packets arrive from, and with a VPN that address belongs to a datacentre rather than to a home line. Most of what gets called VPN detection starts and ends with that one fact, and the rest is inference with a predictable failure rate.

The block starts with where your packets appear to come from

Every request carries a source address, and the receiving server can look it up in public data: which network announces it, whether that network is a hosting provider, whether it has appeared in abuse lists, and which country the registry assigns. None of that identifies you, and all of it is enough to sort you into a bucket.

Look at your own traffic the way a stranger would. Two commands cover most of the surface, and the second one is the one people forget:

curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com

The first returns the exit address, its organisation and its country. The second returns the address of the resolver that reached Google's nameserver, which is often a different network from your exit, and is the address a site sees if it logs resolver-side data. When those two belong to different countries, some sites treat the mismatch as suspicious even though nothing is wrong with your setup.

When the refusal starts only after the tunnel comes up, suspect the exit address before anything else. Switch servers and retry before touching the browser. A block that follows you across three exits from the same provider is about the provider's ranges; a block that disappears on a different server is about that single address.

Time zone, language and clock disagree with the address

Page code can read your time zone, your language preferences and your screen settings without any permission prompt. A browser reporting Central European time while the connection arrives from a Singapore datacentre is a stronger signal than the address alone, and it is the kind of mismatch that fraud scoring is built to notice.

Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().locale

Those three lines in the developer console tell you what your browser volunteers. A VPN client can change your route and nothing else, so the profile you carry stays domestic while your exit is not. Consistency is what matters here: a laptop set to the same region as the exit looks ordinary, and a laptop that disagrees with itself does not.

This is also why the failure is intermittent. Plenty of sites do not care, a few score it, and one membership site decides you are a fraudster. The client is working correctly in all three cases, which is why the usual support answer, "it must be your browser", is both annoying and partly true.

What page code actually knows about your machine

JavaScript has no API that enumerates network interfaces. A page cannot ask which addresses your laptop holds, so the old claim that a script reads your LAN address is mostly a memory of the plugin era, when ActiveX controls, Java applets and other native code could do exactly that.

WebRTC is the honest exception to "no local address leaks". Its candidate gathering once exposed local addresses to any page that asked, and the fix was to replace host candidates with random mDNS names. That default holds in current browsers, but it is a browser decision rather than a protocol guarantee, so an outdated build or a hardened configuration that re-enables local candidates can still leak. Updating the browser does more for you here than any extension.

Your provider sees the names, not the contents

HTTPS protects the contents of a page end to end, and the tunnel operator forwarding those bytes cannot read them. The operator can still see which address you contacted, and in most deployments the server name in the handshake, because the name has to be readable for the connection to be routed to the right site. Encrypted client hello exists precisely to hide that field, and it only helps when both the client and the site support it.

Name resolution is the other half. If your provider also supplies the resolver, it sees every name you look up before any connection exists. If your device uses a public resolver over HTTPS, the provider sees a connection to that resolver and nothing else, while the resolver itself sees the list.

An unencrypted HTTP request is legible to the operator for the same reason it is legible to the hotel network: nothing inside it is encrypted. A tunnel never claimed otherwise, and it does not repair the application's choice.

Separate "this is a VPN" from "this is me"

Detection is cheap, probabilistic and frequently wrong. Shared exit addresses are flagged because someone else abused them, corporate ranges get classified as hosting, and mobile carriers produce geo results that surprise everyone. Identification is a different problem: it needs a persistent link such as an account you signed into, a cookie, a payment detail, or two observers comparing notes.

Decide which one you are actually fighting. If the goal is to read a page, HTTPS already does that work and the tunnel changes little. If the goal is to stop the site from knowing which city you are in, the exit and the resolver are what matter. If the goal is to break the link to your real identity, the account is the weak point, and changing servers does nothing about the login you just used.

A fresh exit does not log you out of anything, and it cannot delete what a site already stored about the account you used. The practical sequence is therefore unglamorous: pick an exit whose network looks ordinary, keep the browser profile consistent with it, update the browser so the leak-prone features use their modern defaults, and accept that a small number of sites will still guess wrong about you.