入口頁打不開，或者只有一部分蜘蛛抓不到，很多时候不是程序或内容的問题，而是 HTTPS 這一层就已经把請求挡在门外。蜘蛛發起的是一次普通的 HTTPS 請求，握手失敗、證书校驗不通過、协议版本不匹配，它拿到的就是连接错誤，而不是你的頁面。

HTTPS 為什么容易成為入口頁的隐形故障点

浏览器遇到證书問题，常常會给出一個“繼續訪問”的選項，人点一下就過去了；蜘蛛没有這個選項。它要么按标准校驗證书鏈，要么直接中断。所以你在浏览器里看到的“能正常打開”，並不等于蜘蛛也能打開。

典型的失敗表現是：訪問日誌里這條 URL 完全没有记錄，而服務器错誤日誌或 CDN 的 TLS 日誌里却有握手失敗條目。遇到這種情况，先別急着改模板，先看连接层。

證书鏈不完整：最容易被忽略的一類問题

服務器只發了站点證书，没有带中間證书，部分客戶端能靠缓存补齐，部分客戶端直接失敗。蜘蛛通常属于後者。检查方式是直接拉取完整證书鏈，看返回的證书條數：

• 只返回一條，通常說明缺中間證书；
• 顺序错誤，比如中間證书排在站点證书之前，也可能校驗失敗；
• 證书與私钥不匹配时，部分服務器仍能正常啟動，但握手會失敗。

SNI 與“用 IP 直接訪問”的差別

現代蜘蛛基本都會带 SNI，但如果同一台服務器上多個入口域名共用 IP，配置里没有預設虚拟主机或預設證书，那么不带 SNI 的請求就可能落到一張不相符的證书上。這類問题在 CDN 回源、内網探测和少數較老的抓取端上會暴露出来。

處理办法不复杂：给每個入口域名單獨配置證书，同时给该 IP 配一個兜底的預設站点和預設證书，避免請求落到“不属于它的證书”上。

證书覆盖范围：SAN、通配符與多域名

批量做入口頁时，域名往往很多，常见的三種做法各有代價：

• 單域名證书：最清晰，但域名一多，續期和部署的工作量會线性增長；
• 通配符證书：适合同一主域下的子域，但只覆盖一級，多級子域不生效；
• 多域名（SAN）證书：一張證书覆盖多個不同主域，维護方便，但任何域名不再使用，都要留意證书里是否還留着它。

關键是让證书里的域名列表和實际啟用的入口域名保持一致，避免出現“證书里有、站点已下线”或“站点在用、證书没覆盖”的错位。

协议版本與加密套件

TLS 1.0 和 1.1 已经不被主流客戶端接受，如果服務器只開這些老版本，握手會直接失敗。反過来，只開 TLS 1.3 而完全關掉 1.2，也可能让一部分工具和較老的抓取端连不上。比較稳妥的做法是同时保留 TLS 1.2 和 1.3，加密套件不要做過度裁剪。

跳轉鏈上的 HTTPS 降級與混合内容

入口頁经常伴随跳轉。如果 https 入口跳到 http 中間頁，再跳回 https，中間那一段本身就不够稳定，也容易被判定為異常跳轉。尽量让整條鏈路都走 https，减少协议来回切換。

頁面内资源同理：https 頁面里引用 http 的图片、脚本，浏览器會拦截，蜘蛛拿到的頁面结构也可能不完整。批量建站时，模板里的静態资源地址最好统一用相對路径或 https 绝對路径。

證书過期與自動續期

證书過期是典型的“平时没問题，某天突然全挂”。三個月有效期的免費證书尤其要注意：

1. 把到期時間纳入巡检清單，提前 15 到 30 天告警；
2. 開啟自動續期，並確認續期後服務真的重载了新證书；
3. 多台服務器、CDN 回源證书分別检查，不要只看其中一台。

排查顺序建议

1. 先看證书鏈是否完整、是否临近過期；
2. 確認證书域名列表覆盖目前入口域名，包括带 www 和不带 www 的寫法；
3. 確認服務器保留了 TLS 1.2 和 1.3，没有使用已被淘汰的加密套件；
4. 检查 CDN 回源是否使用了正确證书，是否走了 http 回源；
5. 以上都正常，再去查狀態碼、跳轉和内容，別把连接层的問题誤判成内容問题。

HTTPS 出問题时，日誌里往往只剩一條连接失敗，看不到頁面，也看不到狀態碼。遇到“蜘蛛就是不来”的情况，先確認握手這一步是通的，再往下查。