A VPN changes the address your traffic comes from. It does not change the cookie your browser sends, the account you are signed into, or the identifier embedded in the link you clicked. That is why a site can greet you by name while your exit address sits in another country. The checks below separate network identity from everything else, in the order that finds the real cause fastest.

What the tunnel changes and what it does not

The tunnel replaces your source address at the exit and encrypts what the local network can see of your traffic. Both are useful, and both are narrow. Everything above the IP layer, meaning the HTTP request your browser actually constructs, arrives at the site unchanged.

That includes cookies, authorization headers, the URL and the TLS fingerprint of your client.

So the question is not whether the VPN works. It is which identifier the site used, and that is answerable by testing one layer at a time.

Step 1: separate account identity from network identity

Sign out everywhere, or use a browser profile that has never signed in, and repeat the visit through the tunnel. If the site no longer recognizes you, the identifier was a cookie or an account, and the VPN was never the relevant control. If it still does, look for another stored identifier before you reach for fingerprinting. A cart, a saved preference or a session token in local storage explains most of these cases.

A private window isolates the cookie jar for that window. It does not anonymize a login you perform inside it.

Step 2: look for identifiers inside the link

Newsletter links routinely carry a subscriber token, and campaign links carry parameters. Open one through any exit you like and the destination still receives the token, because the token is part of the request rather than part of the route. Remote images in email work the same way, tied to one specific message.

Strip the query string when you can, and turn off remote content in the mail client.

The same logic covers information you volunteer. A saved address, a phone number typed into a form or a support ticket reference identifies you after any IP change. Think about who receives the data, not only about the path it travelled.

Step 3: read the fingerprint surface honestly

Fingerprinting combines observable characteristics of the browser and device: user agent, screen geometry, installed fonts, timezone, canvas output. A conventional VPN does not standardize any of that, so clearing one cookie does not remove the other signals. It also does not follow that every recognition is a fingerprint. The common case is a stored identifier you forgot about.

Test with a fingerprinting checker and read the result as a sample rather than a certificate. Those tools measure a method against a dataset, and they cannot promise that no site will ever link two visits. Treat the score as a hint about which surfaces look unusual on your setup.

Reducing the surface is worth more than any single setting: fewer extensions, a current browser version, and profiles you keep separate on purpose.

Step 4: verify with a before-and-after test

Run the same check twice, once outside the tunnel and once inside, and compare the answers rather than your expectations.

curl -s https://ifconfig.me; echo
curl -s https://ipinfo.io/ip

The egress address should change, and the resolver the site sees should belong to the VPN when your DNS goes through the tunnel. If the address changes and the resolver does not, you have a split-DNS path leaking domain queries, which is a configuration fault rather than a tracking mechanism. Check WebRTC separately in the browser, because it can expose addresses in some configurations and the only honest answer is the one your own test returns.

Then repeat the account and link tests. A site that recognizes you after all four steps is using something you are still sending, and the next move is to find that thing rather than to change servers again.

Keep the two results side by side. A privacy check without a baseline is just a guess.

Mikanda mikatakata