站点日誌里突然出現一批握手失敗或连接中断的记錄，很多人會直接归到“服務器不稳定”上，但真正的原因可能是證书鏈、协议版本，或者頁面里混用了 HTTP 资源。這類問题不涉及内容质量，却會让抓取請求在拿到 HTML 之前就断開，入口自然也無法被發現和跟進。
一、抓取中断的常见表現
- 同一批 URL 反复出現 0 狀態碼、连接重置或超时，而不是明确的 4xx、5xx。
- 整体抓取频率在某一天之後明顯下降，但站点内容並没有大的改動。
- 不同环境结果不一致：浏览器打開正常，抓取端却拿不到响應。
- 部分来源 IP 段正常、部分失敗，CDN 各节点表現有差异。
- Sitemap 提交後，對應 URL 長時間没有出現在訪問日誌里。
二、先分清是握手层還是内容层
握手层：證书鏈與协议版本
服務器只下發叶子證书、缺少中間證书时，浏览器往往能通過證书里的补全地址自動拉取，抓取程序不一定有同样的行為。协议版本過低（僅保留 TLS 1.0、1.1）或加密套件過于陈舊，也可能在协商阶段就被拒绝，表現為连接直接中断。
内容层：混合内容與资源阻塞
HTTPS 頁面里如果混用了 HTTP 的图片、脚本或样式，浏览器會拦截或降級處理。若首屏連結是由這些脚本注入的，抓取端渲染时可能完全看不到入口，頁面在日誌里“被抓過”，但連結没有被繼續發現。
三、可执行的排查步骤
- 用 openssl s_client -connect 域名:443 -servername 域名 查看返回的證书鏈，確認是否包含中間證书，以及顺序是否正确。
- 用 curl -vI 观察握手過程，记錄實际协商到的 TLS 版本、是否發生到 HTTP 的跳轉。
- 把抓取日誌按狀態碼、耗时和来源 IP 分组，找出只在特定环境失敗的记錄，而不是笼统地看總量。
- 检查頁面源碼中以 http:// 開头的资源引用，重点看脚本和样式，因為連結常由它們生成。
- 對比 Sitemap 中已提交但從未出現在日誌里的 URL 比例，判断是入口問题還是传輸問题。
四、修复與回归观察
- 在服務器配置中补全中間證书，按叶子、中間、根的顺序拼接，避免只部署單張證书。
- 關閉過舊的协议版本，保留 TLS 1.2 及以上，同时確認加密套件没有被過度裁剪。
- 把頁面内的资源引用统一為 https，或使用协议相對寫法，减少混用带来的拦截。
- CDN 场景下逐节点驗證，避免只测源站就認為問题已经解决。
- 改動之後按天观察握手失敗數量、首次被抓 URL 數，以及原本失敗的路径是否開始出現請求。
證书與协议属于基础设施层面，修好之後一般不需要重新提交 URL，但入口恢复需要時間。建议以周為單位观察趋势，而不是当天就下结论。
五、和内鏈、Sitemap 的關系
Sitemap 與内鏈解决的是“哪里可能有入口”，握手與资源加载决定的是“能不能走到”。如果传輸這一层不通，Sitemap 再完整也只會變成一串抓取失敗记錄，内鏈结构也無從驗證。反過来，当抓取恢复後，可以用内鏈確認關键頁面是否能在两三跳内到達，再用 Sitemap 补齐那些确實缺少入口的頁面，两條线配合起来看，排查方向會清晰很多。