入口页跑在 HTTPS 上已经是常态，但“能打开”和“蜘蛛能顺利抓”之间还隔着握手、跳转和资源加载几层。这几层出问题的时候，人用浏览器看不出来——浏览器会替你容错，蜘蛛不会。
为什么 HTTPS 的细节值得单独看一遍
蜘蛛抓一个 HTTPS 页面，第一步是建立 TLS 连接，第二步才是发 HTTP 请求。任何一步失败，留下的是一条抓取失败记录，而不是一个 4xx。也就是说，这类问题往往不体现在服务器的访问日志里，你只会看到“蜘蛛好像不怎么来了”，却找不到对应的请求记录。
三个最容易出问题的环节
1. HTTP 到 HTTPS 的跳转
理想情况是 80 端口上一条 301 直接指到 https 的目标地址。常见的问题是跳转链被拉长：http 到 https，再到 www，再到带斜杠的路径，一次抓取要跟三四跳。蜘蛛会跟，但每一跳都要重新发起请求，抓取预算就这么消耗掉了。
更麻烦的是循环跳转和条件跳转。比如 http 跳 https，https 又因为配置问题跳回 http，蜘蛛跟两轮就会放弃；或者用 UA 判断来做跳转，给蜘蛛返回 302、给用户返回 200，这类差异一旦被识别，容易被判定为刻意隐藏内容。
2. 证书本身
证书过期、证书链不完整（服务器没下发中间证书）、SAN 里不包含实际访问的域名，都会导致握手失败。浏览器对链不完整有一定容错，很多客户端不行。自签证书同理，蜘蛛不会像人一样点“继续访问”。
建议固定一个检查动作：对每个入口域名跑一次证书链检查，重点看有效期、签发链是否完整、覆盖的域名和实际访问的域名是否一致。批量入口页尤其容易出现“主域名换了证书，子域名忘了换”的情况。
3. 混合内容与资源加载
页面主体是 https，但模板里还挂着 http 的图片、脚本、统计代码。现代浏览器会拦截或警告，蜘蛛多数只看 HTML，影响有限；但如果入口页依赖 JS 渲染链接，而这些脚本被混合内容策略挡掉，链接就等于没出现。
同 IP 多站、SNI 与直连测试
入口页常被放在同一台服务器、同一个 IP 上，这时候必须靠 SNI 区分站点。用 IP 直接访问 443 端口，通常会落到默认站点或直接报错，这个结果不能代表真实抓取情况——测的时候一定要带域名。
反过来，有些检测脚本会跳过证书校验，跑出来一切正常，实际蜘蛛那边是失败的。做自检时把校验打开。
一份可以照着走的自检清单
- 用带域名的方式请求 80 端口，记录完整跳转链，看是否一步到位。
- 检查证书有效期和链是否完整，别只看浏览器地址栏有没有小锁。
- 确认 http/https、www/非 www 四种组合最终都归一到同一个地址。
- 检查 80 端口是否还残留旧内容，避免出现两套可访问的版本。
- 检查模板里是否还有硬编码的 http 资源地址。
几个常见的误区
“证书过期几天，等续期就好”——续期之前蜘蛛每次来都是失败的，那几天的抓取就是零。
- 以为用了 CDN 就万事大吉。CDN 边缘的证书和源站的证书是两回事，源站被回源协议限制时可能走的还是 http。
- 以为 302 跳 HTTPS 也能用。能用，但不如 301 干净，频繁变更还会让蜘蛛反复确认。
- 只测首页。入口页往往是批量生成的，模板里一处 http 硬编码会被复制到所有页面。
小结
HTTPS 这块不需要多高深，关键是别让它成为“静默失败”的来源。把跳转归一、证书链完整、资源地址统一这三件事做扎实，后面看抓取数据才有意义——否则你拿到的样本本身就是残缺的，怎么调方向都只能靠猜。