TCP 正常而 UDP 在同一端口上到达了另一台服务器

一个配置在 TCP 上工作，在 UDP 上却以证书警告失败。直觉的解读是 UDP 路径破坏了信任，直觉的修法是接受该证书。这两种假设都漏掉了一种能完整解释症状的可能：两条传输到达了不同的机器。转发规则按协议分别匹配，没有任何东西强迫同一端口号的 TCP 和 UDP 两半指向同一台主机。

一个端口号，两条独立规则

转发是按协议、目标地址与端口查表。一条针对 TCP 1194 的规则和一条针对 UDP 1194 的规则表达的是两个独立决定，它们可以指向不同的内部主机。共用的号码只是给人看的便利，不是网络强制保证的属性。把端口号当作标签，而不是服务定义。

要看实际生效的规则，而不是设想中的规则。目标地址、转换后的端口和入口接口都参与其中，而起初迁移遗留的规则正是两半不一致的常见原因。

在改动其他任何东西之前，先把两条映射写下来。这两行就是全部假设。

客户端究竟验证了什么

握手期间，客户端用已配置的信任和它预期的名称来检查证书。意外的证书是一次成功的验证，只是在身份检查上失败；当对端不是你打算到达的那台时，这正是正确的结果。拒绝它证明客户端工作正常，而不证明传输坏了。先读被报告的证书名称，再读被报告的证书链，因为名称才是客户端比较的东西。

这个区分很重要，因为两种失败通向不同的修复。信任问题需要修信任，而意外的对端需要修路由或转发。

记下客户端报告的是哪个身份。那个名称是判断哪台机器应答的最强线索。

把这次尝试与某台服务器对应起来

记录配置、公网地址、传输方式和客户端使用的端口。然后把尝试的时间与你打算到达的服务器日志对照。日志里没有记录只是线索，不是防火墙丢弃的证明，因为各部署的日志级别并不相同。时间戳加上源地址，比只靠其中一项更能缩小范围。

通过管理通道，把你遇到的证书身份与预期身份作比较。正是带外比较让这项检查保持可信。

在断定两条传输共用同一后端之前，检查旧的转发规则、替代的监听器和任何负载均衡路径。其中任何一项都能改变一条流的走向，而不触碰另一条传输。

不要为了迎合错误的对端而改信任

导入那张意外 CA 会让症状消失，也会改变客户端信任谁。这比连接失败更糟，因为它掩盖了不匹配，而不是解决它。仅仅为了看隧道能否建立而关闭验证，同样如此。

如果对端被证明合法但并非本意，正确的做法是让它退役，或把规则指向正确的主机。信任库不是用来核对资产清单错误的地方。

保留拒绝信息。这是客户端所见内容的唯一记录。

修复之后，测试一条新流

改正映射，然后用全新的客户端会话连接。有状态转换可能让既有流仍指向旧目标，因此一条已建立的连接可能挺过这次改动，把你带偏。请新建一条，并从目标服务器的日志确认它处理了这次尝试。

如果两条传输确实都能到达同一台服务器、行为却仍然不同，剩下的差异就在那台服务器自己的监听器与配置上。只有在端点身份确定之后，比较传输方式才有意义。