OpenVPN TLS 握手失败：你在哪条分支上？

写着 TLS 握手失败的那一行是一个故事的结尾，而不是开头。关键是紧挨着它前面的那个事件，因为那个事件会指明你属于四种截然不同的故障中的哪一种。超时、控制通道不匹配、证书被拒和协商之后的失败都会给出同一行标题。依据证据选分支，修法就不再是猜测。

读失败之前的最后一个事件

往上滚动，不要只读最后一行。断开之前的事件通常会指明阶段：完全没有回应、交换控制包时报错、出现验证结果，或者协商成功之后又出现认证结果。这些各自属于不同的责任方。这一行决定下面哪一节适用。

保存报错文本时连同客户端版本、端点和传输方式一起保存。公开粘贴的任何内容里都不要带上密钥、密码和未脱敏的配置文件。

一条精确的首个报错比一大段日志更有价值。它指明阶段，阶段则指明责任方。

分支一：什么都没回来

如果客户端发出第一个包之后没有收到任何可用的东西，问题在路径上或在监听一侧。先确认配置对上了服务方真正提供的选项：地址、端口，以及 UDP 还是 TCP。然后再查这个网络到底能不能到达该端点。往下走之前，先记下这两项检查里是哪一项失败了。

在同一个主机名上能打开网页，只证明有 Web 服务在应答。即使 TCP 连接被接受，也说明不了 OpenVPN 的协商是否完成。

如果这份配置在另一个可信网络里能用，就保留这个对照。它把限制定位在某段路径或某个中间设备上。

分支二：控制通道对不上

如果交换开始了又卡住，首先要怀疑控制通道的设置。tls-auth 和 tls-crypt 必须与部署一致，来自另一台服务器的材料不会换来有用的交换。这种失败发生在任何账号登录之前。从旧服务器复制来的配置是常见来源。

重置密码换不掉这些设置，从别的服务借一把密钥也不是兼容性修复。通过服务方经过验证的渠道获取配置，并记下它要求的客户端版本。

记录具体的协商错误，而不是打开一堆旧算法看哪个能撑住。抓到手的报错文本，才能让服务方去查他们那一侧。

分支三：证书被拒

明确的验证失败会点名它不接受的证书。先查设备时钟，再看是哪个对象失败了：服务器证书、客户端证书，还是链条里的某个签发者。过期、签发者不受信任和身份不符合预期，是三种不同的消息。

在拿到修正后的材料之前，保持验证开启。接受一张不相干的证书只是消掉了报错，并不能证明你连到了本该连的服务器。

记下这个失败是跟着网络走还是跟着配置走。到处都出现的证书错误，不是路径问题。

分支四：协商完成了，别的地方失败

身份交换成功之后，剩下的失败属于认证或路由。明确的账号拒绝是认证问题，而连上了却打不开站点则是 路由或 DNS 问题。这时候还去换 TLS 选项，只会破坏一个本来已经跑通的阶段。

汇报问题时，说清楚是不是每个网络都失败、换一份配置能不能用、服务器有没有记录这次尝试。服务端的沉默和它给出的拒绝，站在两条不同的边界上。