VPN 并没有泄露你的旧 IP：是它记住了这个值

VPN 建立之后在服务报告里看到旧公网地址，本身并不构成 泄露的证据。实际连接可能正走隧道出口，而应用提交的是它在隧道存在之前就学到的值。这是两种不同的证据，只有一种描述当前的数据包。另一种是重新连接后仍然残留的值，因为网络路径上没有任何东西拥有它。

同一个地址背后的两种解释

人们想象的顺序是：VPN 本应生效时，数据包却从物理网卡离开。更能解释这份报告的常见顺序更短也更平淡：某个应用早就知道了一个地址，并且一直留着它。把事件按顺序摆开，就能把两者分开。

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

在那个顺序里，没有任何一步需要来自第一个地址的真实连接。被记住的值在消息体内传输，而头部携带的是当前路由所选的出口。同时记录两个字段的服务会把它们并排显示，看上去自相矛盾。

这是一种可能的解释，而不是针对某个特定客户端的指控。口碑不是证据：可阅读的代码库、你信任的品牌或另一个出口，都不能说明某个程序保留或发送了什么。

应用记忆比重新连接活得更久

连接 VPN 改变的是新连接所走的路径。它不碰应用状态，也无法收回远程服务已经保存的信息。程序可能提交账户标识、保存的位置、设备名称或此前获得的另一个值，加密只保护这段载荷在途中的内容，并不会从中删掉任何东西。重新连接是网络事件；被保留的值是应用事件。

这个区别很重要，因为两者住在不同的地方。应用状态属于程序，能熬过重启；路由属于操作系统，每次连接都会重建。清理其中一个对另一个没有影响。

服务也可能保存着你几个月前交给它的值，这种情况下任何本地改动都无法删除它。那是保留，它完全在隧道之外。

先读源地址头，再读载荷

先弄清地址是在哪里出现的。服务器的连接日志描述的是实时来源，而消息字段、账户资料或本地诊断界面描述的可能是很久以前提交或保存的值。这些观察回答的是不同的问题。

也比较一下时间。如果旧地址出现在早于 VPN 连接的字段里，载荷解释就更成立。如果隧道开启时服务器记录到来自旧地址的直连，那是路由问题，需要另一种排查。先把观察类型分清楚，才能避免把一个地址硬说成三件事件的证据。

在笔记里把它们分开：连接来源、消息字段、账户显示、本地诊断。一个地址写在四个地方，仍然只是一个地址。

保留是与传输不同的阶段

RFC 6973 中的隐私指引把收集、使用、披露和保留视为不同阶段，并警告重复使用的标识符会让关联变得容易。新的网络路径只改变传输阶段，别的不变。接收方已经持有的记录不受影响，入口处保存过该值的任何资料也一样。这就是为什么在传输正常工作时，重新连接仍可能让人觉得失败。

任何包过滤器都无法从接收方的记录里删掉一个值，重新连接也不会清空每个程序保存的历史。这些是数据所有者的问题，不是隧道的问题，需要另一种解决办法。在请求网络把它藏起来之前，先问清服务保留什么、保留多久。

在责怪隧道之前该检查什么

检查应用有文档说明的收集方式和账户控制，判断它可以提交哪些字段、服务保留多久、账户能否清除或更正。然后做那个能分开两种解释的测试：新账户或干净的应用配置。如果旧值消失了，说明涉及保留或缓存状态。如果干净配置下它仍然存在，在断定 VPN 失败之前，先看看实际的请求字段。

如果确实存在直连，就把它当作网络路径上的发现。按各自的规则去查路由、分离隧道和客户端策略，不要把那个结果和一个只是熬过重连的载荷值混在一起。两种故障在截图里看起来一样，在抓包里却表现得完全不同。