为什么中间层会改变蜘蛛的体验
蜘蛛抓取入口页时，通常不是直接连到你的源站。DNS 解析、CDN 边缘节点、WAF、反向代理、负载均衡，任何一层都可能先接手这个请求。这些层的默认配置是为“保护站点、加速用户访问”服务的，而蜘蛛的需求和普通用户并不完全一致：它基本不执行 JavaScript、不保存登录态、请求频率高且集中、还经常从同一个出口反复请求同一个地址。
于是同一个 URL 可能返回三种结果：给普通用户的是缓存后的完整页面，给蜘蛛的是被拦下来的验证页或空壳，给回源探测的才是源站原始 HTML。蜘蛛最终看到哪一个，取决于中间层如何判断。
最容易出问题的几个设置
缓存与 Vary 头
如果站点按 User-Agent 返回不同内容，又没有正确设置 Vary，CDN 可能把某个 UA 的响应缓存下来，再发给所有来源。结果是蜘蛛拿到一个几乎为空的页面，而你在浏览器里看起来一切正常，很难第一时间联想到缓存。
WAF 与频率规则
入口页数量多、抓取相对集中时，很容易触发“单 IP 高频访问”这类规则。蜘蛛被拦后不会给你发通知，只在日志里留下 403 或挑战页记录。可以考虑把搜索引擎官方 IP 段加白，或在验证层放开常见蜘蛛 UA 的访问。
回源超时与连接复用
中间层的回源超时设置往往短于蜘蛛的等待阈值。源站稍微慢一点，蜘蛛收到的就是 5xx 或连接超时，而不是它本来还能等到的 200。这类问题在直连测试时通常看不出来。
日志里的真实来源
接入 CDN 后，源站日志里记录的多是节点 IP，看不出蜘蛛的踪影。抓取情况的核对要依赖 X-Forwarded-For 或 CDN 自带的日志字段，否则很容易把正常抓取误判成“蜘蛛没来”。
上线前后的检查清单
- 用 3 到 5 个不同的 UA 和来源 IP 请求同一个入口页，比较返回的 HTML 是否一致。
- 检查响应头中的 Cache-Control、Vary、Age，确认缓存策略与预期相符。
- 查看 WAF 拦截日志，确认是否有蜘蛛 UA 或官方 IP 段被命中。
- 对比 CDN 日志与源站日志，确认抓取次数和状态码能对上。
- 测试绕过中间层直连源站的表现，作为排查时的基线参照。
中间层本身不是问题，问题在于你不知道它替蜘蛛做了哪些决定。排查抓取异常时，先把这条链路打通，再去调整入口页的内容和结构，顺序会顺很多。
几点使用建议
- 需要被稳定抓取的入口页，缓存策略尽量保持简单，避免叠加多层规则。
- 把蜘蛛的访问路径单独列成白名单，与普通用户的规则分开维护，改动时互不影响。
- 定期做一次直连与经过中间层的对比，确认两边的响应内容和状态码一致。
- 变更 CDN、WAF 规则后，观察一段时间的抓取状态与状态码分布，再做下一步调整。