聊天应用里别人能看到你的 IP 吗？每一类观察者究竟知道什么

“我在和谁说话？”这句话里藏着两个问题。一个问的是写下这条消息的账号，另一个问的是你的客户端实际持有的那条网络连接另一端的机器。在中转式聊天里，这两者几乎从不是同一个实体，而这个区别解释了大部分困惑：VPN 到底能对你正在发消息的人隐藏什么、又不能隐藏什么。把拓扑搞对，隐私问题就从情绪化变成可以回答的问题。

你的客户端在和服务器说话，不是在和对方说话

设想一个文字聊天应用：每个参与者连接到服务，服务在账号之间投递消息。你的客户端持有一条到服务的连接；对方持有另一条到同一服务的连接。消息从他们的客户端到服务，再从服务到你的客户端，也就是说你的传输对端是服务的一个端点，而不是他们的设备。

Alex's client  ->  chat service  ->  your client

后面的一切都来自这一张图。看你自己的连接，识别出的是服务，而不是 Alex。看 Alex 的连接，识别出的是另一侧的服务。这两种观察本身都不是对他人设备的包级记录，无论你怎么检查自己的流量，也不会变成那种记录。

不同的观察者收集不同的证据

服务比任何参与者都处于更强的位置，因为它同时终结两条连接，还知道每条连接属于哪个账号。它保留什么、保留多久、关联哪些记录、向谁披露，都是各自独立的问题、各自独立的答案；而“应用是端到端加密的”这句话，一个也回答不了。

作为接收方，你在网络事实上很弱，但在内容事实上很强：消息文字、显示名称、发送方敲下或附上的一切。自己敲出地址的发送方等于自己披露了它，这种披露不是网络观察，尽管读起来像。

如果 Alex 通过 VPN 连接，服务看到的可能是那条连接的出口地址，而不是 Alex 的家庭地址。这是关于服务看到什么的陈述。它并不意味着出口地址会交给你，更不意味着你自己的连接因为 Alex 的传输选择而匿名化。

当应用真的是点对点的时候

中转模型只是模型，不是定律。有些消息功能会在客户端之间建立直连路径，例如通过信令服务器协商的浏览器数据通道，或为避免中转大量数据而把两台设备直接连起来的文件传输模式。在这些情况下，传输对端确实是对方的设备，观察者分析就完全变了。

应用友好的标签不足以告诉你处在哪种情况。“直接消息”描述的是谁读它，而不是它如何传输；同一个应用里的通话或屏幕共享功能，可能和旁边的文字会话使用不同的拓扑。请阅读厂商关于该具体功能的文档，或者观察你在使用它时客户端打开了哪些连接。

端到端加密的声明覆盖的是谁能读取受保护的内容。它完全没有说明哪些服务器接受连接、它们看到什么元数据、是否存在直连路径；RFC 6973 中关于观察者能力的讨论是一种有用的纪律：先点名观察者，再列出这个观察者实际能收集什么。

这对 VPN 意味着什么

VPN 改变的是服务对你这条连接所看到的内容。它不改变你的传输对端是谁，也不会让对方对你的地址产生新的看法。指望 VPN 把你对正在发消息的人隐藏起来，是范畴错误：他们的客户端从一开始就没有和你的客户端建立过连接。

VPN 能改变的，是直连路径类功能。如果应用本来会协商点对点连接，把你的流量送进隧道可能反而强制走中转，有些功能会表现不同或回退；这是真实的影响，但属于拓扑问题，而不是从对话中消失。

那么，在你写下的任何东西里都把两个问题分开。哪个账号发的，哪一端承载的。分别明确回答，注明每个答案谁能观察到，不要再把它们合并成一个“消息能否被追踪”的结论。