抓取日志里如果出现一批没有状态码的连接失败，很多人的第一反应是源站宕机或者被防火墙拦了。但实际排查中有一类问题发生在 HTTP 之前：TLS 握手阶段就已经中断，服务器根本没有机会返回任何状态码。这类故障在监控面板上通常表现为抓取量在某条线路上突然下降，容易被误判成服务器不稳定。
握手失败为什么容易被误判
常规的抓取分析依赖响应状态码，而握手失败连请求行都发不出去，日志里只能看到 connect 或 reset 类的记录。如果只看状态码分布，会得出“没有任何异常”的结论，但抓取量却在往下掉。区分的方法很简单：确认失败是发生在证书协商阶段，还是发生在应用层响应阶段。
四类常见的握手层问题
证书链不完整
服务器只配置了站点证书，没有带上中间 CA 证书。部分浏览器能通过缓存或补全机制正常工作，但抓取客户端不一定具备同样的容错能力，握手会直接失败。用 openssl s_client 连接时可以观察 verify 的返回值和证书链层数，链只有一层通常意味着中间证书缺失。
SNI 缺失或默认站点错配
同一个 IP 上承载多个站点时，如果客户端没有携带 SNI，服务器会回落到默认站点，返回另一张证书或者直接拒绝握手。这种差异在 IPv6 出口或特定网络环境下更明显，表现为主机名与证书不匹配。
TLS 版本与加密套件过旧
只开放 TLS 1.0 或 1.1，或者只保留少数冷门套件，都会导致协商失败。建议至少保留 TLS 1.2 及以上，并开放常见的 ECDHE 套件，兼容性比极端的安全配置更重要。
OCSP 装订与握手延迟
如果服务器没有开启 OCSP Stapling，客户端需要额外获取吊销状态，握手的往返次数增加。在高延迟线路上，这点额外开销会把原本勉强及格的响应时间推过超时阈值。
排查顺序
- 用带 SNI 参数的命令行工具分别从 IPv4 和 IPv6 出口测试握手，对比结果是否一致。
- 检查证书链是否完整，确认中间证书已经随服务端一起下发。
- 确认服务端支持的 TLS 版本与套件列表，排除过旧配置。
- 对比不同出口的握手耗时，判断是否属于线路或节点差异。
- 翻看服务器错误日志中的握手失败记录，统计出现频率和来源分布。
修复与验证
- 补全中间证书，重新加载配置后再次用命令行工具确认链层数。
- 统一证书覆盖的域名与实际访问域名，www 与裸域、HTTP 与 HTTPS 的跳转关系保持一致。
- 开启 OCSP Stapling 并预取响应，减少握手阶段的额外往返。
- 保持 TLS 配置的兼容性，不要为了安全评分砍掉常用套件。
- 修复后持续观察一段时间，看失败连接在总抓取请求中的比例是否回落。
证书配置修复后，抓取恢复往往有滞后，不会立刻回到原来的量级。不要在短期内反复调整配置，否则很难判断到底是哪次改动起了作用。
握手层的问题通常不会出现在状态码统计里，需要单独建一个观察维度：连接失败数、握手耗时、失败来源的出口分布。把这几个指标和抓取量放在一起看，才能快速判断是网络层中断还是应用层异常。