Cloudflare、Akamai 与 WAF：别把 AI 爬虫挡在门外

旺季前两周，一家做户外储能电源的独立站被一波采集流量拖到源站超时。运维在 WAF 上补了三条规则：非浏览器 UA 一律拦截、单 IP 每分钟请求过多返回 429、bot 分数偏低的直接给 403。第二天站点恢复了。一周后运营发现，ChatGPT 回答“露营该买哪种便携电源”时不再提这个品牌，Perplexity 的引用列表里也换成了两家竞品；Google 的自然排名几乎没动，AI 入口却一起消失。

WAF 的默认配置不是中立的：它在替你决定谁能读到商品页，而检索类 AI 爬虫通常第一个被误伤。

WAF 不是防火墙，是一套默认的内容政策

防火墙的老假设是“人来看网页”，所以任何不像人的流量都值得怀疑。检索类 AI 爬虫恰恰不像人：不发 cookie、不执行 JavaScript、不点按钮、等不到你的挑战脚本加载完，还会在短时间内对同一批 URL 反复取数。这些行为放进 bot 管理，全是扣分项。

因果链很短：判定可疑 → 发出 JS 挑战或 CAPTCHA → 爬虫执行不了 → 拿到 403 或一张没有正文的挑战页 → 它把这次抓取记为失败 → 后续降低同类路径的抓取频率，甚至不再回来。你看到的现象是“AI 不引用我”，日志里写的是“我拒绝了它”。

更麻烦的是这层拦截不在 robots.txt 里。robots.txt 是声明，WAF 是执行，两者可以完全相反：规则里写着允许抓取，边缘节点照样返回 403。所以抓取审计要先看边缘日志，再谈 robots，顺序见一次完整的 AI 抓取审计。

误伤的四种形态

这四种经常叠在一起，修掉一种还会被另一种挡住。截至 2026-02，各厂商的名单与默认动作仍在变，判断依据只能是官方文档，不要照抄二手清单。

拦截手段	看起来在做什么	对 AI 爬虫的实际效果
已验证 bot 白名单	只放行通过 IP 与 UA 校验的爬虫	名单以搜索与大型平台为主，部分检索类爬虫不在其中，等于默认被拦
JS 挑战 / CAPTCHA	区分人与脚本	爬虫不执行 JS，永远过不了挑战，只能拿到一张没有正文的页面
UA 关键字拦截	挡住伪装采集器	真爬虫被误杀，采集器改一行 header 就绕过去了，净效果为负
单 IP 限速	保护源站	检索爬虫从少数固定 IP 段高频取数，最先触发 429

第一行最容易被忽略。很多团队以为“我们没屏蔽 AI”，但白名单模式的默认值是“不在名单上就拦”，不是“没证据就放行”。这个默认值的商业含义很大：你放弃的不是一次点击，而是被引用的资格。

第三行是反向错误。按 UA 拦采集器，挡住的是守规矩的爬虫，真正的采集器改个请求头就进来了。这条在robots.txt 放行 AI 爬虫，还是屏蔽？里已经展开过，这里重复，是因为它最常被当作“安全加固”写进 WAF。

四步放行：先验证身份，再分组，最后才谈限速

顺序不能反。先限速再验证，等于把所有爬虫当成一个整体；先验证再分组，规则才落得下去。

步骤	做什么	谁来做	怎么算过
1 取证	导出近 30 天边缘日志中命中 bot 规则或返回 403/429 的请求，按 UA、IP 段、路径聚合	工程	拿到被拦最多的十个 UA 和它们实际请求的路径
2 验证	逐个做反向 DNS 加官方 IP 段核对，区分真爬虫与伪装者	工程	抽 20 条，正反解析一致且 IP 落在官方段内
3 分组	分成检索类、训练类、未知三类；检索类放行商品页、类目页与文章，训练类按品牌策略	增长与工程	每条规则旁边留一句可复核的理由
4 限速	只对参数页、搜索页、接口限速，用 429 加 Retry-After，不用 403	工程	403 只落在预期路径，商品页不再出现 403

第 4 步的关键是用 429，不用 403。403 在协议语义里是“你不用再来了”，爬虫会当成永久拒绝；429 是“现在太挤，晚点再来”，配上 Retry-After，守规矩的爬虫会退避后重试。同一个保护源站的目的，两种状态码给出两种长期结果。

示例：一次只改状态码的修复

示例：某跨境家居独立站（假设场景，不含真实品牌与数据），旺季前上线了边缘限速，规则写成“超过阈值返回 403”，路径匹配全站。结果商品页和筛选页一起被拦，检索类爬虫对商品页的请求一周内归零，AI 答案里的引用随之消失。

修复没有换 WAF 产品，只改了三处：状态码从 403 改成 429 并带上 Retry-After；路径规则拆成商品页与类目页豁免、/search 与 /filter 保留限速；把已验证 bot 的放行开关重新打开，并在注释里写明豁免理由。

验收不看订单，看三个信号：商品页路径上的 403 是否归零、429 是否只落在参数页、同一批问题复测时引用来源里是否重新出现这个域名。三个都过之前，不调下一版规则。

监控：403 和 429 要分开看

把 403 和 429 加在一起看，等于把“被拒绝”和“被限速”混成一件事。 前者是政策问题，后者是容量问题，处理方式完全不同。

要盯三个信号：一是商品页、类目页路径上的 403 占比，正常应接近零；二是 429 的分布，集中在参数页是设计，散落在商品页是事故；三是挑战通过率，通过率极低说明规则在按“像不像浏览器”筛人，而这个标准对爬虫天然不友好。

日志只能证明它来过、被拦了，证明不了它本来会不会引用你。要判断修复有效，得用同一批问题复测答案里的引用来源，方法见用日志判断 AI 爬虫到底来了没有。站点越大，爬虫越会把有限注意力放在少数页面上，放行之后先保哪些页面，见抓取预算不是 Google 的专利。

边界：什么时候该拦

第一，授权与合规要求先拦。抓取会触及用户数据、支付接口、会员内容时，先把这些路径关掉再谈放行，它们本来就不该出现在 AI 答案里。

第二，源站确实扛不住。带宽和数据库连接数是硬约束，先用缓存与静态化降载，再谈放行；直接全放会把站点打挂，那才是真正的不可见。

第三，训练类与检索类要分开决策。拒绝训练是品牌选择，可以坚持；把检索类一起拒掉，等于自己把答案从候选集里删掉。

第四，以平台内成交为主的品类，WAF 不是主要矛盾。亚马逊、Shopee 的 AI 读的是 listing 与评论，边缘规则改得再细也影响不到那里的答案。

第五，厂商的“一键拦截 AI 爬虫”不要当默认值用。它拦的是“AI 爬虫”这个类别，而多数业务需要的只是拦住其中一部分。这条线上其他文章在技术底座主题页。

这个月挑一件事做：从边缘日志里筛出近 30 天商品页路径上的 403，按 UA 排序；对排在前三的真爬虫，把 403 改成 429 加 Retry-After，或加进已验证 bot 的放行分组；改完三天后，用同一批问题复测引用来源，确认它们回来了。