把 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 失败的提示。
- 换个域名变体重复一次，确保每个变体都能通过。
另外，把请求固定到某一台后端机器上再测一次，可以避开负载均衡带来的随机性，更容易判断是单台机器的问题还是全站的问题。
出问题时的处理顺序
- 先确认是全线失败，还是个别域名、个别机器失败，范围决定后续动作。
- 检查证书有效期与链完整性，这两项最容易快速确认。
- 核对服务进程实际加载的证书文件，而不是磁盘上最新改动的那个。
- 检查跳转链和域名变体，看是否有请求落在没配证书的入口上。
- 改完后重新验证一遍，并在日志里观察几天抓取是否恢复。
证书问题通常不会一次把站点打死，它更像一个缓慢的漏点：每天少抓一点，几周后才发现流量掉了。放进季度巡检清单，比事后排查省事得多。