抓取日誌里如果出現一批没有狀態碼的连接失敗，很多人的第一反應是源站宕机或者被防火墙拦了。但實际排查中有一類問题發生在 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 配置的兼容性，不要為了安全评分砍掉常用套件。
- 修复後持續观察一段時間，看失敗连接在總抓取請求中的比例是否回落。
證书配置修复後，抓取恢复往往有滞後，不會立刻回到原来的量級。不要在短期内反复調整配置，否則很难判断到底是哪次改動起了作用。
握手层的問题通常不會出現在狀態碼統計里，需要單獨建一個观察维度：连接失敗數、握手耗时、失敗来源的出口分布。把這几個指标和抓取量放在一起看，才能快速判断是網絡层中断還是應用层異常。