机场证书错误、时间不同步与 DNS 异常怎么分辨

在所有连接故障里,带报错文本的那一类其实是最好修的。超时不告诉你任何原因,已连接却打不开网页更是连一个字都不给;而证书、握手、解析这三类报错会明明白白写出失败在哪一步,你要做的只是把那句英文翻译回它对应的前置条件。

这里说的前置条件,指的是连接真正建立之前必须成立的几件事:域名要能解析成 IP,TLS 握手要能完成,而握手又依赖本机时钟和一套可信的根证书。任何一项不成立,连接根本走不到「节点好不好用」这一层。所以看到这三类报错时,换节点、换机场、重装客户端都是白费力气——它们改变的是节点,而故障发生在更早的地方。

这一篇按报错文案组织。你可以直接找到自己屏幕上那句话,再顺着它往下读对应的成因和处置。

先按报错文案对号入座#

不同客户端的措辞略有差异,但关键词是通用的。把弹窗或日志里的那一行拿来对照下表:

这张表的价值在于把两件事分开:证书类报错的根因几乎都在你自己的机器上,解析类报错的根因则更多在网络环境里。方向搞反了,后面每一步都是徒劳。

时间差几分钟,为什么足以让整条连接崩掉#

证书不是一个永久有效的东西。每一张 TLS 证书都写着生效时间和过期时间,校验时把当前时刻和这两个时间比一比,不在区间内就直接判定无效。而「当前时刻」取自你的本机时钟。

于是一个很反直觉的结果出现了:服务器一切正常、证书也没问题,只因为你的电脑时间慢了半小时,校验就会认定这张证书「尚未生效」,连接在握手阶段直接中止。虚拟机长期挂起后恢复、主板电池耗尽、双系统之间的 UTC 与本地时间约定不一致,都会造成这种偏差。

此外,部分协议在身份验证阶段会单独做时间戳校验,允许的偏差窗口通常只有几分钟,超出就拒绝握手。这类情况的表现更彻底——所有节点一起失效,和全部节点超时的症状难以分辨。

修复动作很简单,但要确认两件事而不是一件:

1. 开启网络时间自动同步,让系统定期校准时钟。同步一次之后回到设置页确认时间真的变了,有些系统会因为服务未启动而静默失败。
2. 确认时区设置正确。时区错了,显示的本地时间也会错,而校验用的是换算后的绝对时刻。跨时区出差或改过区域设置之后尤其要看这一项。

w32tm /query /status
w32tm /resync

以上为 Windows 上查询与强制同步的结构示例,macOS 与 Linux 有各自对应的时间同步服务,思路一致。

修完时间之后重启一次客户端。部分客户端在启动时读取一次时钟并缓存,时间改了但进程没重启,报错会照旧。

证书被替换:怎么确认是不是本机在做中间人#

第二类高频成因是根证书信任链被改动了。企业安全客户端、部分杀毒软件的网页防护模块、以及公司或校园的出口网关,都会解密 HTTPS 流量做内容检查,再用自己的证书重新签发给你。对浏览器来说这通常没问题,因为它们会顺带把自己的根证书装进系统信任库;对代理客户端来说就不一样了,严格的证书校验会立刻发现证书不是预期的那一张,于是报出「未知颁发机构」。

确认方法不需要任何工具:

1. 在浏览器里随便打开一个 HTTPS 网站,点击地址栏的锁形图标查看证书。
2. 看颁发者一栏。如果是常见的公共证书机构,信任链正常;如果是某个安全软件或企业网关的名字,说明流量正在被解密重签。
3. 换一个网络环境重复第一步。换到手机热点后颁发者变回正常,说明做中间人的是网关而不是本机软件。

确认之后有三条路:在安全软件里关闭 HTTPS 扫描、把代理客户端加入其排除列表、或者接受现状换一个不依赖证书校验的连接方式。企业设备上前两条通常做不了,这时候更现实的做法是承认这个网络环境有硬性限制。

解析失败和解析被污染,是两种不同的故障#

这两者经常被混着说,但现象和处置都不同。

「部分网站能开、部分打不开」是污染的典型指纹,因为污染是按域名逐条生效的,不会一刀切。而解析失败往往是全面的:订阅拉不到、节点连不上、连客户端检查更新都失败。后一种情况可以顺手用订阅链接返回码的判别方法交叉验证一次——浏览器打不开订阅地址,基本就是解析这一层的问题。

快速对照两个解析结果:

nslookup sub.example.invalid
nslookup sub.example.invalid 1.1.1.1

上面是结构示例,域名请替换成你自己的订阅域名。默认解析拿不到结果而指定公共 DNS 能拿到,说明本地 DNS 服务器有问题;两者都拿到但地址明显不同,则要怀疑本地结果不可信。

客户端里那几个 DNS 设置项,分别管什么#

打开任意一款主流客户端的 DNS 设置页,通常能看到三到四个条目,名字各不相同但职责可以归成三类:

本篇讨论的是连接建立之前的故障,要动的是第一类和第四类。第二、三类影响的是连上之后的访问路径,属于另一套排查框架,细节在连上了打不开网页里。

一次只改一项,改完立即测一次。DNS 设置项彼此耦合,一口气改四项之后即使恢复了,你也不知道是哪一项起的作用。

握手失败提示里,哪几个关键词值得记住#

握手类报错的文本比证书类更杂,但有三个词的区分度很高。

timeout 出现在握手阶段,意味着数据包发出去了却没有回音。这通常不是配置问题,而是链路被拦或端口被阻断,换网络复现一次最有效,判别流程见换网络才失效的对照实验。

handshake failure 指双方都在线,但协商不出共同支持的参数。常见于客户端版本过旧、或者节点配置里的传输层参数填错。先升级客户端,再核对配置字段。

reset by peer 表示连接被中途掐断。它可能来自链路上的干扰,也可能来自服务端主动拒绝,单看这一条无法定论,需要结合是不是所有节点都这样来判断。

改完之后,怎么确认前置条件真的修好了#

验证要分两步做,顺序不能反。

1. 先在浏览器里打开订阅地址。这一步同时检验了域名解析、TLS 握手和证书校验三件事,能正常返回内容,说明三项前置条件全部通过。这里应该看到一段乱码或明文配置,那是正常的。
2. 再回客户端做一次延迟测试。第一步通过而第二步仍然失败,说明前置条件已经不是瓶颈,故障移到了转发或节点这一层,该换另一套排查方法了。

第一步不通就不要碰客户端里的任何设置。此时故障还停在连接建立之前,改分流规则、改节点、改协议都不会有任何变化。

小结#

证书、握手、解析这三类报错是连接故障里信息量最大的一种,因为它们直接写明了失败在哪一步。看到证书相关的字样,第一件事永远是查系统时间和时区,这一项修复成本最低、命中率也最高。提示未知颁发机构时,去浏览器里看证书颁发者,就能确认是不是本机或网关在做中间人。解析失败和解析被污染要分开对待:前者有报错、影响全面,后者静默且只影响部分域名。客户端里的 DNS 设置分属不同职责,连不上机场时只需要动管客户端自身解析的那一项。最后用浏览器打开订阅地址做一次验证,通过了再回客户端继续。