Does switching VPN servers log you out of a shop?
A new exit address does not empty the cookie jar. Decide whether you are testing the network path, the signed-in session or stored site data first.
Change the VPN exit while a shop is open in another tab and the basket is usually still there. That is not a VPN failure; it is the browser doing exactly what it was told. A cookie is sent by the browser, and a new network path does not change what the browser stores. Three different questions hide behind "the site still knows me", and the answer depends on which one you are actually asking.
Three questions, one symptom
First: is the site recognising a stored cookie? Second: is it recognising a signed-in account, which survives independently of any single cookie? Third: is it recognising something about the browser or device rather than stored state at all? Each has its own test and its own remedy.
| What you changed | What it actually tests |
|---|---|
| VPN exit address | Whether the site treats a different network origin differently |
| Cookie jar for one site | Whether a stored identifier was doing the recognition |
| Browser profile or account | Whether identity, rather than storage, links the visits |
Most confusion comes from changing the first and expecting the second to follow. A network address and a browser store are separate systems that happen to be used by the same page.
What a cookie actually carries
HTTP state management, specified in RFC 6265, is deliberately simple: the server sets a name and value with a scope, and the browser returns it for requests that match that scope. The value can be a session identifier, a preference, or an opaque token that the server maps to a cart record. Nothing in the mechanism mentions the client's address.
That design is why ordinary logins and baskets survive a network change, and it is also why they survive it for trackers. The same mechanism serves both purposes, and it does not distinguish between them. There is no field in the protocol for the client's address, so there is nothing for a new exit to invalidate. A site that wanted to tie a cookie to a network origin would have to add that logic itself.
When a site hands back a cookie, the server looks up whatever record that value points to. Changing the route the request took does not change the lookup, which is the entire explanation for the shopping-cart observation.
Decide what your test is measuring
Before changing anything, write down the state you are starting from: which browser profile, which account, which site data, which network path. Then change exactly one of them and observe. A test that changes the exit address and the browser profile at once proves nothing about either.
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' https://shop.example/cart
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' --interface 198.51.100.44 https://shop.example/cartBoth commands reuse the same cookie file, and the second forces a different local source address where the host allows it. The cart response is the same in both cases because the server never saw a different client identity, only a different path. That is the mechanism in one reproducible pair of requests.
If the goal is to see whether the site recognises you without stored state, clear that site's data and repeat. If it still recognises you, the next suspects are the signed-in account, a link you followed, or browser characteristics rather than a cookie.
Clear the right state, not the network
Removing one site's storage belongs in the browser's own controls, and it will often sign you out or reset preferences as a side effect. It does not delete the account or the records the service already holds; those need the service's own process.
Cross-site restrictions address a different part of the problem. Browsers can block or partition storage that embedded services would otherwise share across sites, while a first-party login keeps working. A successful login is therefore not evidence that cross-site tracking is functioning.
Private windows are another tool with a narrower scope than people expect. Sites can still set cookies during the session, and a login still identifies the account. Ending the private session is what discards the temporary state, which means closing every private window rather than one tab.
Finally, treat fingerprinting as a possibility rather than the first explanation. Device and browser characteristics can link visits without any stored cookie, and clearing storage will not touch them. Check the simple causes first, then widen the investigation, and keep a note of which state you changed so the next comparison is meaningful.