切换 VPN 服务器会让你退出商店登录吗？
新的出口地址不会清空 Cookie 罐。先确认你在测试的是网络路径、已登录会话，还是站点存储的数据。
在另一个标签页开着商店时切换 VPN 出口，购物车通常还在。这不是 VPN 故障，而是浏览器在严格按照指令行事。Cookie 由浏览器发送，新的网络路径不会改变浏览器存储的内容。“站点还认得我”背后藏着三个不同的问题，答案取决于你实际在问哪一个。
三个问题，一个现象
第一：站点是否识别已存储的 Cookie？第二：它是否识别登录账户，而账户独立于任何单个 Cookie 而存在？第三：它识别的究竟是浏览器或设备的某些特征，而非存储状态？每个问题都有自己的测试方法和解决办法。
| 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 |
大部分困惑来自改变了第一个，却期待第二个随之改变。网络地址和浏览器存储是两个独立系统，只是恰好被同一个页面使用。
Cookie 实际承载的是什么
RFC 6265 规定的 HTTP 状态管理刻意保持简单：服务器设置带作用域的名称和值，浏览器在与该作用域匹配的请求中将其回传。该值可以是会话标识符、偏好设置，或是服务器映射到购物车记录的不透明令牌。整个机制中没有任何地方提到客户端地址。
正因如此，普通登录和购物车能挺过网络变化，也正因如此，它们对跟踪器同样能挺过去。同一套机制服务两种目的，并不加以区分。协议里没有为客户端地址预留字段，所以新出口没有任何东西可以使其失效。若站点想把 Cookie 绑定到网络来源，必须自行添加这套逻辑。
当站点回传 Cookie 时，服务器会查找该值所指向的记录。改变请求走过的路由并不会改变这次查找，这就是购物车观察现象的全部解释。
确定你的测试在测量什么
在改变任何东西之前，先写下起始状态：哪个浏览器配置文件、哪个账户、哪些站点数据、哪条网络路径。然后只改变其中一个并观察。同时改变出口地址和浏览器配置文件的测试，对两者都证明不了什么。
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/cart两条命令复用同一个 Cookie 文件，第二条在主机允许的地方强制使用不同的本地源地址。两种情况下购物车的响应相同，因为服务器从未看到不同的客户端身份，只看到了不同的路径。这就是一对可复现请求中的机制。
如果目的是看站点在没有存储状态时是否仍能认出你，就清除该站点的数据再重复一次。如果它仍然认出你，下一个嫌疑对象是登录账户、你跟随过的链接，或浏览器特征，而不是 Cookie。
清除正确的状态，而不是网络
移除某个站点的存储属于浏览器自身的控制范围，它常常会作为副作用让你退出登录或重置偏好设置。它不会删除账户或服务已持有的记录；那些需要服务自己的流程。
跨站限制处理的是问题的另一部分。浏览器可以阻止或分区那些嵌入式服务原本会在站点间共享的存储，而第一方登录仍然可用。因此，登录成功并不能证明跨站跟踪在起作用。
隐私窗口是另一种工具，其作用范围比人们预期的要窄。站点在会话期间仍可设置 Cookie，登录仍能识别账户。真正丢弃临时状态的是结束隐私会话，这意味着要关闭每一个隐私窗口，而不是一个标签页。
最后，把指纹识别当作一种可能性，而不是第一解释。设备和浏览器特征可以在没有任何存储 Cookie 的情况下关联访问，而清除存储不会触及它们。先检查简单原因，再扩大调查范围，并记下你改变了哪种状态，这样下一次比较才有意义。