TCP 重置并不能证明你的 VPN 被封

客户端日志里出现“连接被重置，正在重启”，而结论往往先于证据到达。有人断定网络在封锁 VPN，或者证书有误，或者某个国家在干预。重置是一个终止连接的 TCP 数据包，日志行只记录你的客户端收到了一个。它既没有指出发送方设备，也没有说明原因。

重置是一个数据包，不是判决

TCP 定义了重置的处理方式：带 RST 标志的报文段会立即终止连接。接收方既不协商，也不重试，更不问原因。它只是报告重置，然后继续。

客户端能知道的就只有这些。RST 可能来自服务器、代理、防火墙，也可能来自丢失了状态的负载均衡器。

归因是另一回事。抓包中看似存在的源地址并不证明物理来源，也无从说明背后的策略决定。中间设备可以伪造地址，有状态设备也可能因超时而非蓄意发起重置。把重置当成判决，就跳过了真正查明真相的那一步。

确认是哪条连接被重置

先检查当前使用的配置文件是否真的走 TCP。UDP 隧道上的重置毫无意义，而 HTTP 代理的日志也可能涉及与 VPN 本身不同的另一段 TCP。

记录目标地址、端口、尝试时间，以及客户端当时已经到达的阶段。

阶段是最有用的字段。TLS 握手期间的重置指向一组嫌疑对象；认证之后的重置指向另一组。没有阶段，任何理论都能自圆其说。

对比路径的两端

如果你管理服务器，就对比同一一次尝试在服务器上的事件。它接受了连接吗？它是主动关闭的吗？某个响应是否越过了一道边界，却始终没有到达下一道？

如果条件允许，在客户端和服务器两端都抓包。只出现在客户端、不出现在服务器端的重置，并非源自服务器。

留意两个方向上的 RST 报文段：

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

用受控对比缩小范围

第二个获准使用的网络可以告诉你，故障是跟随客户端还是跟随路径。如果同一配置在别处可用，客户端配置多半没问题，变量就在路径上。

这仍然不能指认某一台中间设备。它把范围缩小到某条路由，这已经是有用而诚实的结论。

要区分“这条路径失败”和“这个被点名的行为者造成了它”。前者可以验证；后者通常无法从单个客户端验证。

在不改动信任设置的前提下验证修复

不要关闭 TLS 校验，不要重新生成凭据，也不要凭一行重置记录就宣布封锁政策。这些改动都会改变被测系统，让下一次对比失去意义。

通过组件的负责人修复被确认的环节，然后重复同一配置和同一观察：

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

有用的结果是把故障定位得更准，而不是一个更笃定的故事。如果修复代理之后重置消失，你就有了原因。如果它转移到另一个阶段，你就对路径多了解了一点。无论哪种情况，证据都应该经得起第二个人阅读。写下你观察到的，而不是你推断出的。