TLS、SNI 与证书校验：代理节点连不上的协议层原因

连不上时，先判断卡在握手的哪一步

使用 TLS 的代理节点（例如 Trojan、VLESS + TLS、VMess + TLS）在真正传数据之前，必须先完成一次 TLS 握手。握手失败时，常见的协议层原因有五类：SNI 与证书域名不符、证书过期或链不完整、设备时间错误、ALPN 或指纹参数不被对方接受，以及 REALITY 参数不匹配。它们分别卡在握手的不同步骤，报错措辞也不同，先定位步骤，比盲目换节点更有效。

本文只讲协议层原因，客户端里的具体操作归客户端专题。所属二级专题见 代理协议二级专题，TLS 与 REALITY 的概览见 一级专题的协议章节。

TLS 握手的四个检查点

一次 TLS 握手可以简化为四个检查点，每个都可能失败：

下面按检查点逐一说明。

SNI：告诉服务器你找的是谁

SNI（服务器名称指示）是 TLS 问候消息里的一个字段，写的是客户端想访问的域名。一台服务器上可能有多个域名和证书，服务器靠 SNI 决定出示哪一张。

节点参数里常见三个与域名有关的字段，容易混淆：

• 服务器地址：客户端实际连接的目标，可以是域名，也可以是 IP。
• SNI 或服务器名称：写进 TLS 问候里的域名，用于选择和校验证书。
• Host 或伪装域名：在 WebSocket 等传输方式里写进 HTTP 请求头的域名，用于反向代理分发。

当服务器地址是 IP 或中转入口的域名时，SNI 必须单独填写为证书上的域名，否则检查点 ② 和 ③ 会因为域名不匹配失败。订阅转换或手动编辑配置时漏掉 SNI，是这类故障的常见来源。

证书本身的问题

在检查点 ③，客户端会逐项校验证书：

1. 有效期。 证书过期或尚未生效都会被拒绝。很多证书的有效期只有几个月，运营方需要定期续期，偶尔会出现续期不及时的情况。
2. 签发链。 客户端需要能从证书一路追溯到系统信任的根证书。服务器只发了自身证书、漏了中间证书时，有的客户端能补全，有的不能，于是表现为“部分设备能连、部分设备不能”。
3. 域名匹配。 证书上列出的域名必须覆盖 SNI 中的域名。

这些问题都出在服务器一侧，用户能做的是确认故障范围后联系运营方。不建议用“跳过证书校验”长期替代修复，原因见 Trojan 协议原理中关于证书校验的说明。

设备时间：被忽视的共同原因

证书有效期的判断以设备时间为准。如果设备时间被调到了过去或未来，所有证书都可能被判为“已过期”或“尚未生效”。这类故障的特征是：多个不同域名的节点同时失败，报错都与有效期有关，有时连普通 HTTPS 网站也会提示证书错误。VMess 的时间校验和 Shadowsocks 2022 的时间戳同样会受影响，比较见 VMess 与 VLESS 的时间校验差别。

ALPN 与握手指纹

检查点 ① 中还有两个容易被忽略的参数：

• ALPN 声明客户端希望在 TLS 之上使用的应用协议，例如 HTTP/1.1 或 HTTP/2。gRPC 传输依赖 HTTP/2，如果 ALPN 与服务器期望不一致，连接可能在握手后立即中断。
• 握手指纹 指客户端问候消息的整体特征。部分客户端会模拟常见浏览器的指纹。客户端不支持节点要求的指纹选项时，可能无法发起握手。

这两项一般由订阅下发，用户较少手动修改，但在订阅转换或换用客户端后出问题时值得留意。

REALITY 的失败方式不同

REALITY 节点的握手失败没有明显的“证书错误”提示。因为公钥、短 ID 或服务器名称任何一项不匹配时，服务器会把连接转交给真实的目标网站，客户端收到的是目标网站的证书，而不是预期的临时证书，于是表现为握手失败或连接超时。如果普通 TLS 节点正常、只有 REALITY 节点全部失败，优先怀疑客户端对 REALITY 的支持或参数是否被完整导入，原理见 REALITY 不需要证书的握手过程。

从现象反推原因

定位到原因之后的具体操作，例如检查客户端日志、校正系统时间、重新导入订阅，属于客户端专题，见 规则分流与故障排查 以及 节点全部超时的排查顺序。

请遵守所在地法律法规与平台条款。本文只解释协议原理，不提供绕过安全校验或规避监管的方法。