做蜘蛛池的时候，大多數精力都花在連結结构、内容數量和放量节奏上，协议层反而容易被跳過。入口頁的 HTTPS 一旦配置有問题，蜘蛛在建连阶段就會失敗，後面無论结构多合理、跳轉多顺畅都用不上。這類故障的麻烦之處在于：用浏览器打開一切正常，服務器日誌里却是一批连接错誤，或者干脆什么都没有。
抓取失敗往往發生在握手阶段
搜尋引擎蜘蛛不是浏览器。浏览器遇到證书問题时，通常會给出一個可以点击繼續訪問的提示；蜘蛛没有這個選項，證书校驗不過就直接放弃。因此，如果入口頁只在某些线路、某些客戶端上报错，很可能不是蜘蛛不来，而是它来了但连不上。
判断方法比較直接：看 Web 服務器的错誤日誌里有没有 TLS 握手失敗、證书相關的报错，以及訪問日誌中對應時間段的請求量是否出現異常下跌。
几類最常见的證书問题
證书鏈不完整
這是最容易被忽略的一種。服務器只下發了站点證书，没有把中間證书一並發送，浏览器因為能自動补全而表現正常，但很多非浏览器客戶端不會去补，校驗就會失敗。判断方式是检查證书鏈是否完整，而不是只看證书還有多久到期。
域名不匹配
入口頁往往不止一個域名。如果用的是單域名證书，後来新增的域名没有寫進 SAN 列表，新域名在握手阶段就會被拒绝。批量铺入口頁时這個問题尤其容易出現——上线很快，證书没跟上。
過期與自簽
自簽證书在浏览器里可以手動跳過，蜘蛛不會。到期證书同理，只不過它的表現是用着用着突然不行了，排查时容易被誤判成其他环节出了問题。建议對入口頁域名做统一的到期提醒，而不是靠人记。
混合内容：頁面是 HTTPS，资源不是
證书没問题，不代表頁面渲染没問题。如果入口頁本身走 HTTPS，却引用了 http 协议的图片、脚本或样式表，部分资源會被拦截，蜘蛛看到的頁面可能是不完整的。
對蜘蛛池入口頁来说，這類頁面的结构通常都不复杂，與其逐個去改引用地址，不如在模板层面统一使用相對协议或直接寫 https，避免每次都靠事後检查。
协议层的問题有個共同点：修起来不难，但發現得晚。把它放進上线前的检查清單，比出問题後再排查划算得多。
跳轉與协议混用
http 與 https 同时可訪問，是另一個常见隐患。理想情况是只保留一個版本，另一個版本用 301 永久跳轉到規范版本，並且跳轉只做一层。
- 避免 http 跳到 https、再跳到带 www、再跳到另一個域名，鏈條越長，蜘蛛浪費在跳轉上的時間越多。
- 避免跳轉成环，A 跳 B、B 又跳回 A，蜘蛛會直接停在原地。
- 检查内鏈里有没有仍然寫死 http 的地址，尤其是入口頁之間的互鏈。
自查可以怎么做
- 用命令行工具直接看握手過程和證书鏈，而不是只看浏览器地址栏的小鎖图标。
- 分別用带 www 和不带 www、以及每個入口域名各测一次，避免只测了主域名。
- 查服務器错誤日誌，筛出 TLS 與證书相關的报错，看出現的時間是否集中。
- 用抓取類工具模拟蜘蛛訪問，观察返回内容是否完整、资源有没有被拦。
這几步做完，基本能判断問题出在协议层還是内容层，避免一上来就去改结构。
入口域名多的时候怎么選證书
如果入口頁域名數量不大，單域名證书逐個申請最省事，也最容易定位問题；域名較多且集中在同一主域下，泛域名證书的维護成本更低；域名分散在不同主域，就需要多域名證书或者按批次管理。這里没有绝對更優的方案，關键是證书覆盖范围和實际使用的域名列表保持一致，並留一個定期核對的動作。
另外，TLS 版本不要配得過低，過老的协议版本在部分客戶端上會被直接拒绝；HTTP/2 不是必须項，但開啟後在抓取效率上通常没有坏處。
寫在最後
HTTPS 配置属于那種不出問题就完全感知不到的环节。它不會直接带来收錄，但配置不当會让入口頁在蜘蛛面前直接消失。把證书鏈、域名匹配、跳轉鏈條和混合内容這四項纳入上线检查，比事後從日誌里大海捞针要轻松得多。