不少蜘蛛池在搭建初期跑得挺顺，接入 CDN 之后反而出现抓取量下滑、入口页像是被冻住的情况。问题往往不在池子本身，而在加速层：爬虫拿到的可能不是你刚更新的那份页面，甚至可能是一个被缓存下来的错误状态。把这一层理清楚，比继续加域名更有效。
缓存会把入口页冻在某个版本
CDN 的默认逻辑是尽量少回源。入口页如果被当成静态资源缓存住，就会出现这样的场景：你改了标题、换了内链、调整了跳转目标，源站已经生效，边缘节点还在返回几天前的旧副本。
对普通访客来说影响不大，对爬虫来说却是另一回事——它每次到访看到的都一样，自然没有理由提高回访频率。入口页的价值恰恰在于看起来还在维护，一旦被缓存冻住，这个信号就传不出去。
- 入口页的缓存 TTL 建议压短，几百秒以内比较稳妥；
- 需要频繁调整的入口页，可以按路径单独设置规则；
- 内容完全静态、长期不动的入口页才适合长缓存。
多节点副本不一致，会让抓取信号变乱
CDN 有很多边缘节点，不同节点的回源时间不同，缓存副本自然不同。同一个 URL，爬虫从不同节点抓到的内容可能有差异，返回的响应头、ETag、Last-Modified 也可能对不上。
单次差异通常不致命，但如果入口页本身就依赖动态参数、随机推荐位或者时间戳，版本碎片会更多。对比之下，一个稳定、统一、变化可控的页面，更容易让爬虫把它当成值得定期回来看看的地址。
做法不复杂：入口页尽量减少随机元素，改动之后主动刷新缓存，别等 TTL 自然过期。
最怕的是错误状态被缓存
源站短暂抖动，入口页返回了一次 503；或者某条规则误伤，返回了一次 404。如果这类响应被边缘节点缓存住，后续爬虫拿到的一直是同一个错误。
入口页的 4xx、5xx 响应不应该被缓存，或者只能缓存极短时间。一次误缓存，可能让一个入口页在很长一段时间里对爬虫完全失去意义。
配置上通常把错误状态码排除在缓存之外，同时给源站加一个简单的健康检查，避免把抖动放大成持续故障。
CDN 的安全策略也会挡住真爬虫
不少 CDN 默认开着人机校验、UA 黑名单、频率限制。正常的搜索爬虫有时会被误判，尤其是来自陌生 IP 段、没有 Referer、请求头不完整的访问。表现出来的现象是：访客能打开入口页，爬虫却经常拿不到完整内容，甚至直接被拒绝。
比较稳妥的处理方式是把已知爬虫的 UA 特征加入白名单，或者对入口页路径放宽校验，把防护重点放在后台、接口这些真正敏感的位置。限流阈值也要留出余量，别让爬虫的并发刚好卡在触发线上。
回源日志才是能用的抓取记录
只盯 CDN 的访问日志，很容易误判：日志里记录的是边缘节点 IP，不是访客 IP，缓存命中的请求甚至根本不会出现在回源日志里。想看清爬虫行为，需要两边的数据配合。
- 回源日志里保留 UA、X-Forwarded-For、缓存命中状态；
- 区分命中缓存的抓取和回源的抓取，两者反映的问题不一样；
- 长期观察同一入口页的回源次数变化，比看总访问量更有参考价值。
一份可以直接抄的配置清单
- 入口页缓存 TTL 控制在几分钟内，改动后主动刷新；
- 4xx、5xx 状态一律不缓存；
- 已知搜索爬虫 UA 走白名单，减少安全策略误伤；
- 保留回源日志，字段包含 UA 与 XFF；
- 目标页可以适当缓存，入口页谨慎使用长缓存；
- CDN 不要一关了之，源站被打挂同样会导致抓取失败。
说到底，CDN 不是蜘蛛池的对立面。它承担的是带宽和抗压，蜘蛛池承担的是被发现的机会。把缓存规则、错误状态和安全策略这三件事理清楚，入口页对爬虫来说才是稳定可读的；反之，池子铺得再多，爬虫每次来都看到同一份旧副本或者一个被缓存下来的 404，效果也不会好到哪里去。