What a VPN Actually Hides, and From Whom
It changes who can see your traffic. It doesn't make you anonymous

Contents
A friend asked me recently whether her VPN “made her invisible online” because an advert had used more or less that phrase. It doesn’t, and understanding exactly what it does instead is more useful than the marketing promise it replaces. A VPN relocates who can see your traffic. It does not delete the fact that your traffic exists, and it does nothing at all to the parts of your online life that were never hidden in the first place. The gap between the two framings is exactly where a genuinely useful piece of networking technology gets sold as something closer to a cloak of invisibility, and where the actual protection on offer ends up misunderstood by the people who most need to rely on it correctly.
The One Thing a VPN Actually Does
A VPN creates an encrypted tunnel between your device and a server operated by the VPN provider, and routes all your internet traffic through that tunnel before it continues on to its real destination. Two consequences follow directly from that one mechanism. First, anyone positioned between your device and the VPN server — your home ISP, the operator of a café Wi-Fi network, anyone else sharing that local network — sees only encrypted traffic heading to the VPN server’s address, and cannot see which websites or services you’re actually visiting beyond that point. Second, the website or service you’re actually visiting sees the VPN server’s IP address as the source of the connection, not your own, so from its side the traffic appears to originate from wherever the VPN provider’s server happens to be.
That’s genuinely useful, and it’s the whole reason VPNs became a mainstream consumer product rather than a niche corporate tool: the threat of an untrusted local network, whether a café, an airport, or an ISP you don’t fully trust, is common and the fix is simple to deploy. It’s also the entire mechanism. Nothing about a VPN removes your traffic from existence, encrypts anything beyond the tunnel’s endpoint, or prevents the sites you visit from identifying you by other means entirely unrelated to your IP address.
Who Loses Visibility, and Who Simply Gains It
The honest way to think about a VPN is as a relocation of trust rather than a removal of it. Before the VPN, your ISP could see every domain you connect to and, on unencrypted connections, potentially more. After the VPN, your ISP sees only an encrypted tunnel to a single address — the VPN provider’s server — and loses visibility into everything you do inside that tunnel. That’s a real privacy gain if your ISP is the party you were most worried about, which for most home users on public or semi-trusted networks it reasonably is.
But that visibility didn’t vanish. It moved. The VPN provider now sits exactly where your ISP used to sit, and can see the same things your ISP could have seen before: which sites you’re connecting to, when, and how much data is flowing, unless the provider has specifically committed — and been independently audited — to not logging that information. “No-logs” is a policy, not a law of physics, and choosing a VPN provider is, in the most literal sense, choosing who you trust with the exact visibility you just took away from your ISP. A provider with a poor no-logs record, or one required by its jurisdiction to retain connection logs, hasn’t removed the surveillance risk; it’s just handed it to a different, possibly less accountable, party.
It’s also worth being clear-eyed about the VPN provider’s own visibility into who you are, separate from what you do once connected. Most commercial VPN services require payment, and payment methods — even ones marketed as privacy-friendly — routinely leave a trail linking a subscription to a real identity, which matters if the provider itself is ever compelled to hand over account information, even absent any traffic logs at all. A provider can have a genuinely audited no-logs policy for your browsing activity and still know, from billing records alone, exactly which subscriber a given account belongs to. That’s a different exposure than traffic logging, and it’s one no-logs marketing rarely addresses directly.
The Same Tool, Different Jobs
Part of the confusion around VPNs comes from the fact that “VPN” covers several genuinely distinct use cases that only share a mechanism, not a purpose. Someone connecting to a corporate VPN to reach internal systems is using the tunnel to gain access to a private network, not to hide anything — the whole point is that the company’s servers recognise the connection as coming from inside, which is close to the opposite of anonymity. Someone using a commercial VPN on public café Wi-Fi is protecting against a genuinely local threat: whoever else is on that same network, or whoever operates it. Someone using a VPN to appear to be browsing from a different country for the purposes of catalogue or pricing differences is exploiting the “sites see the VPN server’s address” property specifically, and neither privacy nor security is really the point of that use case at all — it’s geography spoofing, and it works or doesn’t work per site, independent of any privacy benefit. Conflating these three is where a lot of the marketing muddiness comes from: the mechanism is identical in each case, but what it’s actually protecting against, and from whom, is completely different depending on which job you’re using it for.
What a VPN Never Touches
Beyond the tunnel, your traffic reaches its actual destination looking exactly like traffic from the VPN server rather than from you, but the website itself doesn’t need your IP address to recognise you. A cookie set the last time you logged in identifies your browser regardless of which address the request comes from. An account you’re logged into identifies you directly, VPN or not — logging into a personal email account through a VPN doesn’t make that session anonymous, it just changes which network address the login request appears to originate from. Browser and device fingerprinting — screen resolution, installed fonts, timezone, a dozen other quietly observable details — can re-identify a specific browser across sessions with unsettling accuracy, entirely independent of IP address.
This is the gap between “hides my traffic from my ISP” and “makes me anonymous,” and it’s exactly where a lot of VPN marketing quietly overstates the product. A VPN is a genuinely effective tool against network-level observation. It is not a tool against being recognised by the sites you’re logged into, the trackers embedded in the pages you visit, or the unique fingerprint your specific browser and device present regardless of which IP address is attached to the request.
A Real Handshake, Genericised
Modern VPN protocols like WireGuard make the actual mechanics reasonably transparent to inspect. A minimal client configuration looks something like this:
| |
The AllowedIPs = 0.0.0.0/0, ::/0 line is doing the work that matters for this discussion: it tells your device to route all IPv4 and IPv6 traffic through the tunnel, rather than only traffic bound for specific destinations. That’s a deliberate, visible configuration choice, and it’s worth understanding because a misconfigured or partial routing setup is one of the most common ways a VPN quietly fails to protect what people assume it’s protecting.
Troubleshooting: The Leaks That Undermine the Whole Point
A DNS leak is the single most common way a VPN’s protection quietly fails without anyone noticing, and it’s worth checking for on every new VPN setup rather than trusting the marketing claim that DNS is “automatically protected.” If your device’s DNS queries are still being sent to your normal, non-VPN resolver — often because the VPN client didn’t override the system’s DNS settings, or because an app is configured to use a specific resolver directly — then anyone watching that DNS traffic can see every domain you’re resolving, tunnel or no tunnel, because DNS queries and the actual traffic they precede are handled by entirely separate parts of the operating system’s network stack. Testing for this is straightforward: connect to the VPN, then check a DNS leak test site or simply run a lookup and inspect which resolver actually answered it.
An IPv6 leak is the same failure mode wearing a different hat, and it’s become more common rather than less as ISPs have rolled out IPv6 by default over the last several years while plenty of VPN clients still treat it as an afterthought. Plenty of VPN setups route IPv4 traffic through the tunnel correctly while leaving IPv6 traffic to travel over the ordinary, unprotected connection, because the tunnel or its configuration only accounted for one protocol. If your network has IPv6 enabled — increasingly the default — and your VPN configuration doesn’t explicitly handle it, you may be leaking a parallel, unencrypted path for exactly the traffic you thought was fully tunnelled.
A kill switch, or its absence, matters for a related reason: if the VPN connection drops unexpectedly — and it does, from time to time — a client without a kill switch will typically fall back to your ordinary, unprotected connection silently, rather than blocking traffic until the tunnel comes back. For anything where the VPN’s protection is actually load-bearing rather than incidental, confirm the client has this feature enabled rather than assuming it does, and test it deliberately by killing the tunnel process while a background download or browser tab is active, watching whether traffic actually stops rather than silently continuing over your normal connection.
Finally, remember that logging into any account through a VPN doesn’t retroactively anonymise that account’s history, and it won’t prevent the same account from being linked across sessions regardless of which IP address each session came from. If the goal is separating an identity from your real network location, a VPN is necessary but nowhere near sufficient on its own.
Split tunnelling is a related setting worth understanding rather than toggling blindly. Some VPN clients let you exclude specific apps or destinations from the tunnel deliberately, for good reasons — routing local network traffic to a printer or NAS directly rather than pointlessly through a remote VPN server, for instance. The trouble is that a split-tunnelling rule you set up for one purpose and forgot about will quietly exempt whatever it covers from every protection this piece has described, indefinitely, until you go looking for it. If you’re not certain whether split tunnelling is active, check the client’s configuration explicitly rather than assuming “connected” means “everything is tunnelled” — the two aren’t automatically the same thing once any exclusion rule exists.
Is a VPN Worth Running?
For its actual job — keeping your ISP and anyone sharing your local network from seeing which sites you visit, and presenting a shared address rather than your own to those sites — yes, a well-chosen VPN is straightforward, effective, and worth running, particularly on networks you don’t control. Just be precise about what “well-chosen” means: a provider whose no-logs claims have been independently audited, whose jurisdiction isn’t one that compels retention, and whose client correctly handles DNS, IPv6, and connection drops rather than leaking around the tunnel it’s supposed to be providing. What it will never do is anonymise you against the sites you’re logged into, defeat browser fingerprinting, or erase the fact that traffic between you and somewhere is happening at all — it only changes who’s positioned to see where that traffic actually goes. Treat it as one deliberate layer in a wider privacy and security posture, not as a single switch that solves the whole problem, and it earns its place; treat it as a magic cloak and the first fingerprinted login will quietly prove the marketing wrong. If you’re weighing running your own tunnel rather than trusting a commercial provider with that visibility, Tailscale: a zero-config mesh VPN and WireGuard site-to-site between two homes both cover the self-hosted alternative, where the trust question above gets answered by “you,” rather than by a provider’s privacy policy.




