浏览器升级后访问正常，老旧客户端却在代理前报TLS握手失败；或者直连源站支持TLS 1.3，一经过安全设备就退回TLS 1.2。代理终止TLS时，前端和后端是两次独立协商，不能用源站扫描结果替代整条链路。
两段TLS可能完全不同
| 连接段 | 协商双方 | 重点检查 |
|---|---|---|
| 客户端到代理 | 客户端与代理入口 | 版本、SNI、ALPN、入口证书 |
| 代理到上游 | 代理与源站 | 版本、上游SNI、信任CA、客户端证书 |
前端TLS 1.3、后端TLS 1.2可以是正常设计；问题在于安全基线、功能和观测是否明确，而不是要求两个版本数字完全相同。
TLS 1.3改变了什么
TLS 1.3减少握手往返，移除多种旧算法和不安全组合，并调整密码套件的定义。老旧库若把TLS 1.3套件误用旧版配置字段，可能启动失败或没有共同算法。应按实际OpenSSL、Java、操作系统或代理版本查文档。
SNI错误仍然很常见
同一IP托管多个站点时，客户端通过SNI告知目标名称。代理连接上游若只使用IP且未设置正确SNI，可能获得默认证书或错误虚拟主机。HTTP Host发生在TLS之后，不能替代SNI。
ALPN决定上层协议
客户端和服务端通过ALPN协商HTTP/2等应用协议。中间设备不识别、删除或错误转发ALPN时，连接可能退回HTTP/1.1，也可能因应用仅支持特定协议而失败。应同时记录TLS版本与最终应用协议。
为什么老旧中间设备会阻断
部分防火墙或TLS检查设备对新握手字段、扩展顺序或未知版本处理不正确，直接丢弃或重置连接。通过直连、旁路测试和设备日志对照可以定位，但生产修复应升级规则或固件，而不是永久关闭安全检查且不留替代控制。
证书验证没有因为TLS 1.3消失
主机名、证书链、有效期和撤销策略仍然重要。代理解密会向客户端提供企业签发证书，并自己验证真实上游。任意一侧CA或SNI错误都可能表现为握手失败，撤销检查还可参考OCSP、CRL与Stapling排查。
0-RTT为什么需要谨慎
TLS 1.3的Early Data可以减少恢复会话延迟，但数据可能被重放。登录、支付、创建任务等有副作用的请求不应只因性能开启。代理和应用必须共同识别并限制可安全重放的方法。
会话恢复与节点切换
多节点代理若不共享或协调会话票据密钥，客户端切换节点后可能无法恢复，但通常应回退完整握手。票据轮换、有效期和密钥保护需要统一，不能为了提升命中率无限延长票据寿命。
怎样做分段测试
- 固定域名、SNI、客户端版本和代理节点；
- 分别测试TLS 1.2与1.3，记录Alert而非只看“失败”；
- 从代理节点测试上游TLS、SNI与证书链；
- 记录ALPN、Cipher、会话恢复和是否使用0-RTT；
- 对照旁路链路与中间设备日志，确认失败段；
- 升级后做旧客户端兼容与安全基线回归。
不要用宽泛降级掩盖问题
临时限定版本可以定位不兼容组件，但长期开放过旧TLS版本或弱算法会扩大风险。建立客户端版本清单和淘汰计划，对确需兼容的遗留系统使用隔离入口，而不是降低全站安全策略。
结论
TLS 1.3经过代理握手失败，必须分别观察客户端到代理、代理到上游的版本、SNI、ALPN和证书。找到实际不兼容的库或中间设备并升级，才比全局关闭TLS 1.3更可持续。
