證书到期、CDN 配置變更、回源协议不匹配，這几種情况有個共同点：出問题时整站一起出問题，而且往往發生在你毫無准备的时刻。抓取、收錄、用戶訪問同时受影响，留给排查的時間又很紧。這篇把常见的检查点按顺序理一遍。
證书過期為什么比想象中更麻烦
浏览器遇到證书不受信任时，會给用戶一個醒目的拦截頁；蜘蛛遇到同样的情况，通常不會给你寫邮件，只是把這次訪問记成失敗。如果连續多次都失敗，原本正常的抓取节奏就會被打乱，恢复訪問後也需要一段時間才能回到原来的水平。
更麻烦的是，證书問题经常不是“整站全挂”，而是部分子域名、部分 CDN 节点出問题。你在办公室訪問正常，用戶走其他线路却打不開，這種情况最容易拖到第二天才被發現。
按顺序排查：從解析到證书鏈
遇到打不開或抓取異常，先按下面的顺序過一遍，避免一上来就怀疑程序代碼。
- 域名解析：確認 A 记錄或 CNAME 指向的是目前在用的服務器或 CDN，没有被誤改。
- 證书有效期：看的是目前實际生效的那張證书，不是控制台里另一張同名的證书。
- 證书鏈完整性：中間證书缺失时，部分客戶端會直接判定失敗，而浏览器有时會帮你补上，導致本地看不出問题。
- 域名覆盖范围：主域名、带 www、移動端子域名、接口子域名是否都在證书的覆盖列表里。
- 跳轉與混合内容：HTTPS 頁面里如果還引用了 HTTP 的图片或脚本，浏览器會提示不安全，不會直接报错但會被标记。
續期這件事，尽量交给自動流程
靠人工记日期的續期方式，迟早會出問题。常见的做法有几種：
- 用 ACME 類工具自動簽發和續期，把續期時間设在到期前一個月左右，留出失敗重试的空間。
- 續期成功後自動重载服務，避免證书換了但進程還在用舊文件。
- 續期失敗要有告警，而不是等它自然過期。
- 把提醒同时發给至少两個负责人，避免有人休假时没人處理。
如果是商业證书，采购流程和审批時間也要算進提前量，別把續期安排在到期前一天。
CDN 與反向代理层的几個坑
回源协议不一致
用戶到 CDN 是 HTTPS，CDN 回源却用 HTTP，源站如果强制跳轉到 HTTPS，就容易形成循环。要么统一协议，要么把源站的跳轉規則放行 CDN 的回源請求。
多張證书混用
同一台服務器上跑多個站点时，容易出現配置里挂的還是上一個項目的證书。检查时最好直接訪問域名看實际返回的證书信息，而不是只看配置文件。
缓存把舊頁面留住
配置調整後，CDN 上的舊缓存可能還在。修改規則後主動清理一次，再观察几天的抓取情况，別指望它自動過期。
把它變成固定動作
證书相關的检查不需要很频繁，但需要固定。可以這样安排：
- 每月看一次證书剩余有效期，確認自動續期任務正常执行。
- 每次改 CDN、改解析、換服務器之後，立刻做一次全域名訪問測試。
- 把主域名、移動端、接口等關键地址列成一張表，逐個点開確認。
- 出現訪問失敗时，先记錄時間和涉及的线路，方便和 CDN 或服務商沟通。
證书和訪問可用性是站点运营的底线。内容做得再细，用戶和蜘蛛打不開，前面所有工作都归零。
最後提醒一句：恢复訪問後不要急着大改结构，先让訪問和抓取回到正常狀態，观察一两周再安排其他調整。