不少站点在排查“蜘蛛不来”时，第一反應是改正文、加連結、換模板，却忽略了更前面的一层：蜘蛛要先完成 TCP 连接和 TLS 握手，才可能讀到 HTML。握手這一步失敗或者耗时過長，訪問日誌里连一條记錄都不會留下，從日誌看就像蜘蛛從来没到過。所以把 HTTPS 相關配置当成入口頁的基础设施来看待，常常比反复調整頁面本身更有效。
握手阶段可能卡住的几類問题
- 證书過期或尚未生效：證书不在有效期内，客戶端通常直接中断连接，不會繼續請求頁面。
- 證书鏈不完整：服務器只下發了站点證书，没有带上中間證书。部分浏览器能靠缓存补全，但抓取程序一般不會，于是握手失敗。
- 域名不匹配：證书只覆盖了主域或只覆盖了 www，而入口頁用的是另一個。泛域名證书和 SAN 列表要能覆盖實际投放入口的所有域名。
- 协议版本不兼容：只開老舊 TLS 版本，或者只保留過新的版本，都可能出現协商失敗。
- 直接用 IP 訪問：證书里通常没有 IP 條目，用 IP 当入口属于常见誤配。
- SNI 處理異常：同一台服務器、同一個 IP 上放了多個站点，如果没按 SNI 返回對應證书，蜘蛛可能拿到別的站点的證书，後續校驗自然不過。
證书之外，容易被忽视的连接细节
跳轉鏈是否過長
HTTP 到 HTTPS、主域到 www，這些跳轉本身没有問题，但如果叠成三級四級，每一次都要重新建立连接，握手開销就被放大。建议把入口頁收敛成一跳可達的最终地址，中間不要绕路。
混合内容
頁面主体是 HTTPS，但里面引用了 HTTP 的图片、脚本或样式。浏览器會有拦截提示，抓取程序的表現則各不相同，有的直接放弃渲染。把资源地址统一成相對协议或顯式 HTTPS，可以少一類變量。
连接复用與首字节
如果服務器禁用了會话复用，或者每次請求都要走完整的證书鏈校驗和 OCSP 查询，首字节時間就會被拉長。對蜘蛛来说，這不是“打不開”，而是“打開得慢”，長期看會影响它在站点上的抓取节奏。啟用會话票據、把 OCSP 装订打開，是比較常規的做法。
證书與 IP 环境的關系
同一張證书挂在多個 IP 上、或者 IP 频繁更換时，要確認每個 IP 上的證书配置是同步更新的。只換了其中一台机器的證书，另一台仍在用舊證书，入口分流之後就會有一部分請求在握手阶段失敗。
一套可执行的自查流程
- 用 openssl s_client -connect 域名:443 -servername 域名 看服務器實际下發了哪些證书，輸出里應当能看到完整鏈。
- 用 curl -I -v https://入口地址 確認狀態碼、跳轉次數和最终地址，顺便看 TLS 协商结果。
- 換一個網絡环境和解析线路再测一次，排除本地 DNS 或运营商缓存带来的假象。
- 检查服務器配置里的协议版本與加密套件，確認没有只留极舊或极新的组合。
- 把所有在用的入口域名列成清單，逐個比對證书覆盖范围與到期時間，設定提前續期提醒。
- 對照訪問日誌，看握手失敗时段是否和請求量下滑吻合，把問题定位到具体机器。
日常维護上的几点建议
- 證书到期時間统一登记，提前續期，不要等到当天再處理。
- 新增入口域名时，先確認證书覆盖，再挂内容。
- 多站点共用 IP 时，保證 SNI 配置正确、證书不串。
- 入口頁尽量一跳直達最终地址，减少中間跳轉。
- 換 IP、換机器、換 CDN 之後，重新跑一遍上面的自查流程。
證书和握手解决的是“能不能到達”的問题，它决定不了頁面會不會被收錄。但這一层没做對，後面關于内容、連結和抓取配額的所有優化都無從谈起。把它当成稳定的基础设施来维護，比事後反复猜测蜘蛛為什么不来的成本更低。