先分清两件事：缓存和回源
入口页通常是轻内容、重链接的页面，正文不多，主要作用是让蜘蛛发现并顺着链接爬到目标站。这类页面走 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 和缓存只解决入口页能不能被稳定拿到的问题，它不解决内容质量，也不改变目标站自身的条件。入口页再稳，目标站打不开、内容空，效果也不会凭空出现。