用 Cloudflare 边缘拦截 AI 刷量脚本，把后端 Token 成本压下来的实战经验

最近把公司所有 AI 服务的入口全部迁移到了 Cloudflare，核心目的就是为了解决那个让人头疼的流量滥用问题。之前我们尝试在后端用 Nginx 写简单的 Rate Limit 规则，但面对那些灵活的爬虫或专门刷接口的脚本，简单的频率限制几乎没用，因为对方可以通过分布式 IP 轻松绕过。结果就是后端 Token 消耗速度惊人，月度预算经常在月中就超标，这种被动应对的局面让整个团队压力很大。

这次我们尝试了 Cloudflare 的 AI 流量管理选项，最直接的体感就是它能精准地将“真实用户”与“AI 机器人”剥离，而不是简单地通过 IP 计数。在具体的落地配置中，我们采取了三步走的策略。

首先是识别流量来源。这里我们利用了 CF 的 Bot Management 标签，这个功能非常关键，它能直接把已知的大模型爬虫（比如 GPTBot 或 Common Crawl）以及第三方 AI Agent 标记出来。以往我们习惯于维护一个巨大的 User-Agent 黑名单，但事实证明这种方式效率极低，因为请求头可以随意伪造。而 CF 的指纹识别在识别 AI 机器人方面比单纯看请求头要准得多，能从底层协议特征上区分出请求者。

其次是实施分级限流。我们没有采取一刀切的策略，而是建立了三层阈值：内部测试账号和核心合作伙伴的 IP 段直接开绿灯；对于外部公开接口，我们设置了一个极低的请求阈值，比如每分钟限制在 5-10 次请求。这种设计的精妙之处在于，拦截动作发生在边缘节点，请求根本传不到我们的 API 服务器上，直接省掉了后端的计算资源和 Token 消耗。

最后是动态拦截。一旦某个 IP 的请求特征符合典型的 AI 刷量模式，比如高频次地请求 /v1/chat/completions 路径且缺乏有效的 Session Cookie，CF 会在边缘节点直接将其拦截。实操下来，后端 API 的无效请求减少了大约 30%。最关键的是，工程师不再需要频繁地修改 Nginx 配置文件并执行 nginx -s reload 来重启服务，在控制面板点几下就能实时生效，极大地提升了运维效率。

不过在部署过程中我们也踩了一个坑，建议大家注意：如果拦截规则配置得过于激进，很容易误杀一些正常的 SEO 爬虫，导致搜索引擎索引下降。我们当时就因为把 Bot 阈值设得太低，导致部分谷歌爬虫被拦截了，直接影响了页面的收录速度。

针对这个问题，现在的最佳实践是：不要直接上线拦截。先将规则设置为“Log Only（仅记录）”模式，观察 24 小时的流量日志，通过分析日志确认没有误杀正常业务流量后，再将其切换为“Block（拦截）”状态全量开启。

总的来说，把流量控制前移到边缘节点，比在应用层做限流要高效得多。尤其是在面对 AI 时代这种高频、分布式的接口请求时，这种架构能给后端服务器提供极大的缓冲空间，让团队能把精力从“补漏洞”转移到“优化模型”上。