不少入口页在服务器确定之后，会顺手接一层 CDN，用来扛并发、挡攻击、降低源站负载。这一步本身没有问题，但 CDN 会改变蜘蛛实际访问的链路：它连到的是边缘节点，缓存可能让它拿到旧内容，源站日志里的访问 IP 也可能全是节点地址。下面把接入 CDN 之后最容易出问题的几个环节拆开说。
缓存：入口页到底该不该被缓存
缓存是 CDN 最主要的能力，但对入口页来说，缓存策略要根据页面性质来定，不能直接套用静态资源的规则。
相对适合缓存的场景
- 入口页内容长期不变，只做链接聚合，页面本身没有个性化输出。
- 源站带宽有限，希望减少重复回源。
- 可以接受较短的缓存时间，例如几分钟到一小时，并配合主动刷新。
不建议缓存或应设置较短缓存的场景
- 页面内容经常调整，新增链接需要尽快被看到。
- 页面会根据 UA、Cookie 或来源地区返回不同内容。
- 设置了缓存但忘记清理，边缘节点长期返回旧版本。
比较稳妥的做法是给入口页设置一个较短的缓存时间，同时保留手动刷新缓存的入口，避免改了内容却要等很久才生效。
回源之后：日志里为什么看不到蜘蛛
接入 CDN 后，源站看到的访问来源会变成边缘节点的 IP。如果只看源站日志里的远端地址，得到的基本都是节点，无法判断来的到底是不是搜索引擎蜘蛛。
一般需要在源站读取 CDN 传递的真实 IP 头，例如 X-Forwarded-For、X-Real-IP 或各家服务商自有的头字段。要注意这些头只有在源站可信的前提下才有意义，所以更安全的做法是配合回源 IP 白名单，只信任来自 CDN 节点的请求，其余请求不采信这些头。做完这一步，日志里的 IP 才具备反查价值。
另外提醒一点：真实 IP 是否属于搜索引擎，需要通过反向解析或官方 IP 段比对来确认，不能只看 UA 字符串，UA 是可以随意伪造的。
蜘蛛会不会被边缘节点拦下来
CDN 通常自带一部分安全能力，配置不当时，蜘蛛可能在到达源站之前就被挡掉，而且源站日志里什么都看不到。常见的拦截点包括：
- WAF 规则把某些参数或路径判定为异常请求。
- 按 IP 维度的频率限制，蜘蛛短时间多次抓取时被限流。
- 地区访问限制，蜘蛛出口节点所在区域被排除在外。
- 浏览器挑战或 JS 校验，蜘蛛不执行脚本，直接拿到拦截页。
排查这类问题时，可以先临时关闭或放宽相关规则，观察入口页的访问量是否恢复，再逐步收紧。
回源配置的几个细节
- 回源 Host：确认与源站站点配置一致，否则可能出现默认站点串位。
- 回源协议：如果边缘用 HTTPS、回源用 HTTP，注意源站的跳转规则不要形成循环。
- 超时设置：回源超时过短会让响应变慢甚至失败，蜘蛛侧看到的可能是错误状态。
- 回源 IP 白名单：开启后源站只接受节点访问，能减少被直接扫描的情况，但要同步维护节点段。
上线后的检查顺序
- 确认入口页通过 CDN 访问与直连源站返回的内容一致。
- 检查响应头是否被边缘节点改写，例如缓存头、robots 相关头字段。
- 在源站日志中确认能看到真实 IP，并能与节点 IP 区分开。
- 用真实的抓取工具或日志观察一段时间，确认访问没有被边缘规则拦截。
- 改动内容后主动刷新缓存，再次访问确认拿到的是新版本。
CDN 只是链路中的一层，它不会让入口页变得更容易被抓取，也不会替代内容本身的建设。接入之前先想清楚要解决的问题，接入之后把日志和缓存两件事盯住，通常就能避开大部分麻烦。
总的来说，入口页接 CDN 不是能不能做的问题，而是接完之后有没有把缓存、真实 IP 和拦截规则这三件事对齐。这三项理顺了，日志才有参考价值，后续的判断也才有依据。