为了让入口页抗住压力、隐藏源站 IP，不少蜘蛛池会把入口页放到 CDN 或云 WAF 后面。这套架构本身没问题，但它会在“搜索蜘蛛能不能拿到页面、拿到的是什么内容、源站能不能看到真实访问”这几个环节上增加变量。抓取效果不理想时，先排除 CDN 和 WAF 这一层，往往比反复改 HTML 更有效率。
CDN 与 WAF 主要影响哪几件事
可以把这一层理解为中间人，它同时影响三件事：
- 请求能否到达源站：WAF 的规则、频率限制、人机校验可能直接拦掉搜索蜘蛛的请求。
- 返回给蜘蛛的内容：CDN 缓存可能返回旧版本，或者返回一个不带链接的验证页。
- 源站日志的可信度：源站看到的 IP 多半是 CDN 回源节点的，不再是蜘蛛的真实 IP。
常见的几类具体问题
WAF 把人机校验甩给了搜索蜘蛛
很多云 WAF 默认对“没有浏览器特征”的请求做 JS 挑战或等待校验。搜索蜘蛛不会执行 JS，也不会带完整的浏览器指纹，结果就是被反复挑战、最终拿到一个空壳页面或被直接拒绝。表面上看是“入口页没被抓”，实际是请求在边缘就被拦下了。
判断方法很直接：用搜索引擎官方的抓取测试工具跑一次，或者直接从 WAF 日志里看有没有被 challenge、block 的记录。如果同一时间大量被拦截请求的 UA 正是搜索蜘蛛，基本可以确认是规则误伤。
缓存把入口页缓存成了空页或旧页
入口页的内容通常是动态拼出来的，比如从库里取一批目标 URL。如果 CDN 或 WAF 的缓存策略较激进，可能出现两种情况：
- 缓存了首次渲染时还没数据、或者被拦截后的空白版本，之后一直返回这个版本；
- 缓存了几天前的旧链接列表，蜘蛛抓到的还是已经下线的目标 URL。
入口页这类需要随时反映当前链接列表的页面，通常不建议做长缓存。给入口页路径单独设一条缓存规则，把 TTL 压得很短，或者对搜索蜘蛛的 UA 直接回源。
源站日志看不到蜘蛛真实 IP
开启 CDN 后，源站访问日志里记录的往往是 CDN 回源节点的 IP，而不是搜索蜘蛛的 IP。这会直接影响蜘蛛身份的正反回验流程——你按 IP 去反查域名，得到的是 CDN 厂商的域名，看起来“不像蜘蛛”，于是误判成假蜘蛛。
解决方式有两种：一是开启 CDN 提供的真实 IP 回传头，常见的是 X-Forwarded-For 或厂商自定义头，并在源站日志格式里把它记录出来；二是把 CDN 厂商公布的节点 IP 段整理成一份白名单，日志分析时先做一层映射。
节点调度带来的区域差异
CDN 会把不同地区的请求解析到不同节点。搜索蜘蛛的抓取节点分布在不同区域，不同节点上的缓存状态、回源策略可能不一致，于是会出现“同一时间有的节点能抓到、有的抓不到”的情况。排查时最好固定从一个节点复现，再对比多个节点的差异。
一个可落地的排查顺序
- 先确认请求有没有到源站：看 WAF 或 CDN 日志里该 URL 的请求记录，以及源站是否收到对应的回源请求。
- 再确认返回内容：直接请求入口页 URL，对比带搜索蜘蛛 UA 和不带两种情况下的 HTML 是否一致。
- 检查缓存状态：看响应头里的缓存命中标记，判断返回的是缓存版本还是回源版本。
- 核对真实 IP：确认源站日志记录的是回源 IP 还是真实客户端 IP，再决定怎么设计蜘蛛身份验证。
- 最后才动入口页本身：HTML 结构、链接写法这些问题放在这一层之后排查。
配置上的一些实用建议
- 给搜索蜘蛛的 UA 单独放行，跳过 JS 挑战和频率限制，但不要因此对所有 UA 都放行。
- 入口页路径单独设缓存规则，不要和目标站的静态资源共用一条策略。
- 如果入口页需要隐藏源站，回源鉴权用密钥或 IP 白名单，不要靠 UA 判断。
- 日志里务必保留真实客户端 IP 字段，否则后续的抓取分析和蜘蛛验证都做不准确。
- WAF 规则调整后，用同一批目标 URL 观察一段时间，对比调整前后的回源量和抓取量。
CDN 和 WAF 是入口页的门卫，出问题时的表现和“页面写得不好”很像，但排查方向完全不同。先把这一层排除掉，再去看 HTML 和链接本身。
最后提醒一句，这一层配置的目的是让正常抓取顺利通过、把异常流量挡在外面，而不是无差别拦截。规则越严，误伤真实搜索蜘蛛的概率也越高，需要结合日志持续调整。