入口頁跑在 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 這块不需要多高深，關键是別让它成為“静默失敗”的来源。把跳轉归一、證书鏈完整、资源地址统一這三件事做扎實，後面看抓取資料才有意义——否則你拿到的样本本身就是残缺的，怎么調方向都只能靠猜。