把蜘蛛池的入口页放到 CDN 后面，通常能改善访问速度、分摊带宽，但也常带来一个新问题：真人访问正常，蜘蛛却频繁拿到 403、503，或者只拿到一页需要执行 JavaScript 的验证页面。多数情况下，原因不在蜘蛛池本身，而在 CDN 的缓存策略、回源规则和防护配置。下面按“先判断、再调整”的顺序，把常见的坑和检查方法说清楚。
先确认蜘蛛实际拿到了什么
不要只看浏览器里的效果。用命令行模拟蜘蛛请求，对比直连源站与走 CDN 的返回结果，差异点通常就是问题所在。
- 指定 UA 请求：带上主流蜘蛛的 User-Agent 发请求，看状态码、响应头与正文前几百字节。
- 对比源站直连：同一个 URL 直连源站 IP，如果源站正常、CDN 异常，问题就在边缘层。
- 看 CDN 日志：统计状态码分布与缓存命中比例，确认 403、429、503 集中在哪些路径。
- 检查正文：返回 200 但正文是验证页、跳转脚本或空壳，对蜘蛛来说等同于抓取失败。
三类最容易误伤蜘蛛的配置
1. 浏览器完整性检查与 JS 挑战
这类功能依赖执行 JavaScript 或保存 cookie 才能通过，而蜘蛛一般不执行脚本、不带 cookie。开启后，入口页在蜘蛛眼里就成了无法通过的关卡。以静态内容为主的入口页，建议直接关闭针对蜘蛛 UA 的挑战策略。
2. UA 频控与 IP 限速
蜘蛛抓取往往短时间集中请求，容易被边缘节点判定为异常流量，触发限速或临时封禁。合理的做法是按已验证的蜘蛛来源单独放行或放宽阈值，而不是一刀切。仅凭 UA 放行并不可靠，最好结合反向解析或官方公布的 IP 段做校验，减少伪蜘蛛混入。
3. 缓存策略把错误页面缓存住
有些配置会把 404、5xx 或重定向一起缓存，而且缓存时间不短。结果是源站已经修好，边缘节点还在持续给蜘蛛返回旧结果。5xx 和 4xx 通常应设置较短缓存或干脆不缓存；缓存键也要避免把不同 UA 的结果混进同一个缓存池，导致真人拿到蜘蛛版本或反之。
回源日志与真实来源的识别
接入 CDN 后，源站日志里记录的访问 IP 会变成边缘节点 IP，直接用来源 IP 判断蜘蛛就会失真。需要在回源请求中保留原始客户端 IP（例如通过 X-Forwarded-For 这类通用头部），再结合 UA 与反向解析来判断。同时保留一份 CDN 侧日志，两边对照，才能确认蜘蛛是否真的到达源站。
缓存 TTL 与内容更新节奏
- 入口页作为发现 URL 的枢纽，更新频率不高，静态部分可以给较长的 TTL，减少回源压力。
- 列表页、会新增链接的页面，TTL 不宜过长，否则新 URL 迟迟不出现在蜘蛛视野里。
- 不要对同一份内容同时设置互相矛盾的 Cache-Control 与 CDN 面板规则，边缘通常按更严格的一方执行。
- 如果入口页会按 UA 或来源返回不同模板，明确哪些版本允许缓存，避免蜘蛛拿到给其他场景准备的页面。
一份可落地的检查清单
- 用蜘蛛 UA 直连源站与走 CDN 各请求一次，记录状态码与正文特征。
- 关闭或放宽针对蜘蛛的 JS 挑战、验证码与频控规则。
- 确认 4xx、5xx 不会被长时间缓存。
- 让回源请求保留原始客户端 IP，日志可追溯。
- 静态资源与 HTML 的缓存规则分开设置，两者不必相同。
- 调整后隔几天再看一次日志，确认异常状态码下降，而不是只看单次请求。
CDN 默认面向“防御”和“节省带宽”，而蜘蛛需要的是稳定、可预期的响应。把这两套规则分开配置，通常就够用了。
最后提醒一点：CDN 节点 IP 会调整，DNS 记录的 TTL 也影响蜘蛛多久切换地址。换节点或换回源方案后，留出解析生效的时间，别在当天就下结论。