把 HTTPS 部署完，很多人就不再管它了。可對搜尋蜘蛛来说，每次抓取都要重新做一次 TLS 握手。證书過期、鏈不完整、域名覆盖漏掉一個變体，蜘蛛拿到的就不是頁面，而是一個连接层面的错誤。麻烦的是，這類問题在日誌里未必留下 404 或 500，因為請求根本没走到應用层，只看狀態碼那一列很容易漏判。
為什么蜘蛛會被證书挡住
用戶遇到證书告警，多數會点“繼續訪問”，或者干脆換個入口進去。蜘蛛不會替你做這個判断。驗證失敗时它通常會直接放弃本次抓取，隔一段時間再来试。如果同一时段内多個 URL 都失敗，抓取量就會整体下滑，而且下滑得比較均匀，看不出集中在哪個栏目。
所以当抓取量下降、日誌又没有明顯错誤碼时，HTTPS 值得排在排查清單的前几位。
自查清單
有效期與續期方式
確認目前證书的到期時間，以及自動續期是否真的在跑。常见的坑是：續期脚本依赖某個定时任務，服務器迁移後任務没跟着走；或者續期成功但服務没有重载，進程里用的還是舊證书。
- 到期時間是否留出足够缓冲，不要卡在最後几天才續。
- 續期後是否触發服務重载，實际生效的證书日期以檢測结果為准，而不是以磁盘上的文件為准。
- 是否有提醒或监控，而不是等出事才發現。
證书鏈是否完整
只装站点證书、不装中間證书，浏览器有时能靠缓存蒙混過去，命令行和爬虫却會直接判定鏈不完整。用 s_client 或在线檢測工具看一眼鏈的层數，確認没有缺环。
域名覆盖范围
主域、www、移動站，以及仍在被訪問的舊域名，都要在證书覆盖范围内。常见情况是主域換了新證书，www 還挂着舊的，蜘蛛從站外連結進来正好落在 www 上，握手失敗。
- 列出所有會返回内容的域名變体，逐個驗證。
- 不再使用的域名，與其硬撑證书，不如做一次干净的重定向。
- 通配符證书只覆盖一层子域，多級子域要單獨確認。
跳轉方向是否唯一
HTTP 到 HTTPS、非 www 到 www，這類跳轉要保持一個统一方向，並且每一跳都能正常完成握手。避免 A 跳到 B、B 又跳回 A 的循环，也避免用 JavaScript 做协议跳轉。
混合内容
頁面本身是 HTTPS，里面却引用了 HTTP 的图片、脚本或样式，浏览器會给出警告，蜘蛛抓取时也可能拿不到這些资源。检查模板、編輯器里粘贴的舊連結，以及 CDN 域名是否也配了證书。
TLS 版本與加密套件
為了通過某些合規掃描，有人會把服務端配置收得极紧，只留最新版本和少數套件。抓取方如果版本較舊，可能直接被拒。除非有明确的安全要求，一般保留主流版本区間即可，同时關掉已知不安全的舊协议。
SNI 與共用 IP
同一台服務器上放了多個站点时，如果没開 SNI 支持或預設站点配置寫错，蜘蛛訪問 A 域名可能拿到 B 站点的證书，握手直接失敗。這在虚拟主机和自建反向代理里都不少见，尤其是刚加上的站点。
几分钟的驗證方法
不必装复杂工具，命令行就能看清大部分問题：
- 查看實际返回的證书與到期時間：openssl s_client -connect 域名:443 -servername 域名
- 確認鏈是否完整：在輸出的證书鏈部分數一下层數，看有没有 verify 失敗的提示。
- 換個域名變体重复一次，确保每個變体都能通過。
另外，把請求固定到某一台後端机器上再测一次，可以避開负载均衡带来的随机性，更容易判断是單台机器的問题還是全站的問题。
出問题时的處理顺序
- 先確認是全线失敗，還是個別域名、個別机器失敗，范围决定後續動作。
- 检查證书有效期與鏈完整性，這两項最容易快速確認。
- 核對服務進程實际加载的證书文件，而不是磁盘上最新改動的那個。
- 检查跳轉鏈和域名變体，看是否有請求落在没配證书的入口上。
- 改完後重新驗證一遍，並在日誌里观察几天抓取是否恢复。
證书問题通常不會一次把站点打死，它更像一個缓慢的漏点：每天少抓一点，几周後才發現流量掉了。放進季度巡检清單，比事後排查省事得多。