一次容易被带偏的排查

看到网站打开慢，我以前的习惯是先看机器负载，再翻程序日志。后来学会看五段耗时才发现，如果 TLS 握手这一段特别突出，前面那些排查方向可能全跑偏了。

TLS 握手是客户端和服务器在正式传数据之前，协商加密参数的过程。它不是建立连接，连接在 TCP 阶段就已经建好了。这一段慢，说明加密协商本身费时间。

握手要几个来回，先看协议版本

TLS 1.2 完整握手需要两个往返，TLS 1.3 只要一个，会话复用时还能更少。节点离源站越远，一个往返的代价越大，握手耗时就被放大。

所以第一件要确认的是协议版本，而不是急着换证书。服务端如果还在只支持老协议，握手多一个来回，跨地区节点上的差距会非常明显。

证书和 OCSP 也会拖时间

证书链太长，客户端要多下载、多验证；中间证书塞得没必要，同样增加传输量。OCSP stapling 没开的话，客户端可能还要自己去查吊销状态，多一次外部请求。

这类问题有个共同特征：所有节点都慢，而且慢得比较平均。它不挑地区，跟线路问题的表现不一样。证书的到期时间也顺手看一眼，过期的证书会让握手直接失败，那种情况在状态码那一列更显眼。

用节点分组区分两种慢

这是我判断时最依赖的一步。用宝塔拨测的网站测速跑多地区多运营商节点，看 TLS 段在各地的表现：

  • 只有远处节点慢、近处正常，更像往返次数和延迟的问题
  • 所有节点一起慢，更像证书链、协议配置或服务端算力
  • 忽快忽慢、最慢节点飘忽，先怀疑丢包和链路质量

节点分布能把「延迟型」和「配置型」分开，比在服务器上瞎翻日志快得多。

复测和对照怎么做

改配置之前先连测三次，留个底。同一路径、同一协议，别在改完的瞬间就下结论，连接复用和会话缓存都可能让结果暂时好看。

改完再测，看的是同一批节点的 TLS 段有没有整体下降。只降了一部分，说明还有别的原因叠着；完全没动，先回头确认配置真的生效了。

还有一个容易忽略的点：测的地址要和用户实际访问的一致。如果 http 会跳到 https，握手其实发生在另一个域名上，对着 http 地址测出来的 TLS 段参考价值有限。

我现在的顺序

先看状态码确认请求走通，再看五段里 TLS 是不是真的占大头，然后用节点分组判断是延迟型还是配置型，靠复测验证。顺序别乱，不然很容易把线路问题当成证书问题，换了一圈证书还是慢。