先分清两件事：缓存和回源
入口頁通常是轻内容、重連結的頁面，正文不多，主要作用是让蜘蛛發現並顺着連結爬到目标站。這類頁面走 CDN 是合理的：资源小、结构简單，源站扛不住並發时，CDN 能分摊压力。但要清楚，蜘蛛抓到的往往是 CDN 节点上的副本，不是你源站那一刻的真實响應。入口頁内容本身變動不大，這通常不是問题；真正容易出問题的是响應头、狀態碼和跳轉這三類信息。
TTL 怎么定：按會不會變来分
- 纯静態外壳、样式、图片：可以设較長缓存，比如几小时到一天，减少回源次數。
- 頁面 HTML 本身：如果里面只有固定的連結结构，中等缓存（几十分钟到几小时）够用。
- 涉及跳轉、狀態碼、重定向規則的路径：TTL 要短，甚至设為不缓存，否則你改了跳轉层級，蜘蛛還拿着舊副本。
關键点在于：蜘蛛判断一條 URL 是否有效，很大程度依赖狀態碼和最终落点。如果 CDN 把 301 缓存住，你後續去掉這條跳轉之後，蜘蛛仍可能按老路径走一段時間。
回源失敗时會發生什么
缓存過期那一刻，CDN 會回源。如果源站超时、连接被拒，节点可能直接给蜘蛛返回 5xx，也可能返回過期副本（stale）。两種结果的影响不同：5xx 會让蜘蛛把這批 URL 标记為临时不可用，反复几次後降低抓取频率；返回舊副本相對温和，但會让你的更新延迟生效。
比較稳妥的做法是開啟 stale-while-revalidate 或 stale-if-error 這類策略：後台异步回源，前台先给舊内容，同时给源站留出恢复時間。再配合源站的健康检查，避免單個节点故障被放大成全站 5xx。
蜘蛛 UA 要不要特殊對待
不建议按 UA 返回不同内容。同一個 URL 對不同 UA 给出不同 HTML，容易被判定為作弊，後期维護也麻烦。可以做的是：
- 在日誌里按 UA 打标记，方便統計蜘蛛請求在總請求中的占比。
- 對確認過的蜘蛛 IP 段做限速豁免或直连源站，减少节点誤伤。
- 把 WAF、防爬規則里誤拦蜘蛛的條目單獨放行，並定期复核。
UA 可以伪造，不要只凭 UA 就放行。结合反向 DNS、IP 段和訪問频率一起看，才比較可靠。
几個常见的坑
- CDN 节点给蜘蛛返回 403 或 503，而源站日誌里看不到請求，排查时容易誤判成蜘蛛没来。
- 把 404、410 也一並缓存，後續恢复頁面後，蜘蛛仍拿到错誤狀態。
- 缓存了带參數的 URL，導致同一内容出現多個副本，分散 URL 發現的效果。
- CDN 的 TLS 版本、HTTP/2 配置與部分蜘蛛不兼容，表現為握手失敗或连接中断。
怎么驗證配置是否生效
不要只看源站日誌。可以用第三方节点探测工具，從不同地区請求入口頁，观察 X-Cache、Age、CF-Cache-Status 這類响應头，確認是命中還是回源。再把探测结果與 CDN 侧日誌、源站日誌對照，看三者的狀態碼是否一致。發現不一致时，優先怀疑缓存和 WAF 規則，而不是先怀疑蜘蛛。
最後提醒一句：CDN 和缓存只解决入口頁能不能被稳定拿到的問题，它不解决内容质量，也不改變目标站自身的條件。入口頁再稳，目标站打不開、内容空，效果也不會凭空出現。