把入口页直接放在服务器上对外，是很多蜘蛛池的默认做法。为了让源站 IP 更隐蔽、扛住突发流量，有人会给入口页套一层 CDN。这个选择本身没有对错，但它会给蜘蛛的访问路径增加一个中间层，日志、缓存、状态码都会随之变化。用之前，先弄清楚 CDN 到底改变了什么。
CDN 带来的好处与代价
先说好处。CDN 能在源站前面挡一层，源站 IP 不直接暴露；静态入口页命中节点缓存后，回源压力明显下降；遇到扫描或异常流量，节点也能吸收一部分。对于入口页数量多、页面以静态为主、又不想让源站直接面对公网的场景，这些收益是实在的。
代价同样明显。蜘蛛请求到达的是 CDN 节点，不再直接命中源站。你看到的访问日志里，绝大部分访问来源会变成 CDN 回源 IP，而不是蜘蛛或普通用户的真实 IP。回源链路变长之后，TTFB 可能上升；如果节点缓存和源站缓存策略不一致，蜘蛛还可能拿到一份过期的页面副本。
回源配置：先解决“蜘蛛是谁”
只要你打算根据访问来源做判断——比如给蜘蛛放行、给普通用户跳转、按 IP 限速——就必须在 CDN 层把真实 IP 透传下来。常见做法是在回源请求里带上 X-Forwarded-For 或 X-Real-IP，源站按约定字段取值，而不是直接读 REMOTE_ADDR。写日志时也要记录真实 IP，否则后期分析抓取数据基本无从下手。
还要注意区分两类地址：一类是蜘蛛本体的 IP，一类是 CDN 节点的回源 IP。某些 CDN 会把蜘蛛请求统一回源到固定节点，日志里会出现大量重复的来源地址，看起来像“蜘蛛只从几个 IP 来”，其实是中间层造成的错觉。判断蜘蛛身份时，不要把回源 IP 当成蜘蛛 IP 去做归属验证。
缓存与状态码：容易被忽略的两个变量
入口页如果被节点缓存，蜘蛛在不同时间访问可能拿到不同版本。对需要体现更新的入口页，缓存时间不宜设得过长。可以给 HTML 设较短的 s-maxage，或者用源站校验的方式，让节点定期回源确认。内容更新之后，记得主动刷新对应 URL 的缓存，否则蜘蛛反复看到的都是旧内容。
状态码透传也值得验证。源站返回 404、410 或 503 时，CDN 是否原样透传，还是改写成 200 或自定义错误页？如果错误状态被改写，蜘蛛对入口页可用性的判断就会失真。上线前用工具分别测源站直连和 CDN 地址，对比两者的响应码与响应头，是最省事的验证方式。
哪些情况适合用，哪些建议直连
- 适合用 CDN：入口页以静态内容为主、域名数量多、需要隐藏源站、带宽成本敏感，且不需要按单个 IP 做精细控制。
- 建议源站直连：需要实时、完整的访问日志，需要频繁调整抓取行为，或者入口页更新非常频繁、缓存维护成本高于收益。
- 折中做法：只让部分域名或部分路径走 CDN，核心入口页保留直连；也可以自建反向代理，把控制权留在自己手里。
CDN 不会改变蜘蛛愿不愿意抓，它改变的是蜘蛛看到的路径、你看到的日志，以及缓存和状态码之间的那层不确定性。
上线前后的检查清单
- 确认回源请求已透传真实 IP，日志字段与源站取值逻辑一致。
- 对比源站与 CDN 地址的响应头，检查缓存策略是否符合预期。
- 测一遍 404、410、503 等状态码，确认没有被节点改写。
- 刷新缓存后，再观察蜘蛛是否拿到了新版本内容。
- 定期比对 CDN 日志与源站日志，找出节点回源与直连之间的差异。
CDN 是工具，不是必选项。入口页要不要套 CDN，取决于你对日志精度、更新实时性和源站隐蔽性的优先级。把回源和缓存这两件事配清楚，再决定要不要加这一层，比先套上再排查问题要省事得多。