这段时间我一直在处理一个非常头疼的问题一个基于大模型的应用域名接入 Cloudflare 之后用户量不大但后台每秒都有大量请求在打。更烦的是这些请求看起来“太正常了”UA 没问题路径也对甚至没有明显恶意但你从流量曲线一眼就能判断出来它们不是人在操作。盯着 Security 日志的时候我脑子里冒出一个很不专业的词AI Psychosis。不是模型疯了而是整个 AI 流量环境看起来像疯了一样——真实用户、搜索引擎爬虫、各种训练数据采集脚本、自动问答机器人、批量任务调度器全部混在同一个入口用一种极其雷同的方式涌进来。你可能也有过类似体感明明没有大流量宣发也没上热搜为什么访问量一夜之间涨了十倍而且服务器负载一直下不来这种体验让我重新理解了 Cloudflare 在 AI 应用里真正的位置它不是一块挡在前面的盾牌而是一个流量整流器。你如果只把它当成“安全工具”那大概率会被日志里的各种异常流量逼疯。真正的问题不是要不要用 Cloudflare而是你有没有把它当成一套需要持续配置、持续观测、持续调整的流量治理系统。下面是我基于一次真实部署过程沉淀下来的配置思路以及几个容易被忽略的边界。如果你也在给 AI 应用做入口防护这几条应该能帮你少走一段弯路。1. AI 应用的流量为什么这么“难管”1.1 AI 服务天然就长在自动化环境里传统网站的业务流量大多来自浏览器用户用手点、用眼睛看、用键盘输入。这个模型相对简单识别浏览器、识别点击路径、识别停留时长基本就能区分人和机器。但 AI 应用的流量完全不是这样。它的核心调用方式不是人而是 API。你的模型对外提供服务真正在大量消费服务的是另一个程序可能是网页前端里的 SDK可能是服务端调用的 SDK也可能是某个正在做评测的脚本、一个帮你抓取摘要的浏览器插件、一个批量运营内容的工具、一个不知道从哪里买的“测压脚本”。这些程序发出来的请求长什么样和你自己写代码调 OpenAI 接口时的样子几乎一模一样固定的 Authorization、固定的 JSON 体、固定的/v1/chat/completions路径、没有 Cookie、没有点击轨迹、没有鼠标移动。也就是说AI 应用的大量正常流量从特征上看就是“自动化流量”。这就带来了一个根本矛盾传统 WAF 里“自动化的就是可疑的”这个假设在 AI 场景下不成立了。如果直接拦会把自己最大的用户群体拦掉如果不管模型服务会被各种采集脚本和爬虫打穿。所以流量管理在这一类服务里不是可有可无的安全要求而是决定了服务能不能稳定提供的问题。1.2 在 Cloudflare 里AI 应用更像一个“四不像”接入 Cloudflare 之后这个矛盾会被放大。原因在于Cloudflare 的很多安全功能是按照“网站流量”设计的。它有很强的浏览器指纹识别、JavaScript 挑战、Cookie 验证但这些机制都假设对方是一个浏览器。一个标准的大模型调用客户端根本不打算执行你返回的 JavaScript也不会创建 Cookie所以很多“高级挑战”对它无效或者会误伤正常程序。你可以做个简单实验把某个 AI 接口的 URL 放进浏览器能正常返回但同一个地址用命令行去请求Response Headers 里可能多出很多安全校验痕迹甚至直接回 403。这就是 Cloudflare 的自动化识别在起作用。问题在于这个“识别”不是因为你用了 Cloudflare 就自动正确。实际使用时你需要回答几个问题这个请求是真的用户在调用还是程序在调用如果是程序调用是合规客户端还是采集脚本如果是采集脚本是恶意的还是 Google、Bing 这类正常搜索引擎这个请求对模型的 token 成本、配额、延迟指标有没有影响这些问题的答案才决定了策略。但 Cloudflare 默认的控制台不会帮你回答它只会给一个 bot score、一个威胁分数然后让你选择动作允许、跳过、挑战、拦截。2. Security → Bots 这个入口有哪些真实使用姿势2.1 先理解“模式”和“分数”之间的关系进入域名的 Security → Bots 之后不同套餐会看到不同的功能。有的只有简单的 “Bot Fight Mode” 开关有的则能看到完整的管理化 Bot Management。大多数时候你会在里面遇到类似“严格程度”的选项关闭、宽松、严格或者智能。我见过不少团队一开始就选择“严格”模式。为什么因为当时被恶意流量搞怕了觉得越严格越安全。但跑一段时间就会发现问题正常服务的调用成功率明显下降有些用户反馈客户端老是被断连有些小程序开发者在群里问“为什么我的请求被拦截了”。原因在于严格模式的核心动作就是“尽最大努力拦截可疑机器流量”。但因为 AI 应用的主要消费者就是程序严格模式会把你最想留住的程序用户也拦掉。换句话说对普通网站严格模式可能只是稍微提高误杀率对 AI 应用严格模式可能会直接破坏产品。这并不意味着严格模式不能用而是说你要清楚它控制的是什么。Cloudflare 的 Bot Management 会给每个请求打一个 bot score范围一般是 1 到 99。分数越低越像机器人分数越高越像真人。通过 WAF 自定义规则你能用这个分数做非常精细的控制比如分数低于 30 的请求进入托管质询。分数在 30 到 60 之间的请求只限速不拦截。分数高于 60 的请求直接放行。这个“分数 规则”的组合才是很多 AI 项目真正需要的。但分数本身并不总是准确尤其是对于那些经过伪装、模拟浏览器头信息的爬虫它也会给出接近正常的分数所以你还需要加入业务层面的判断条件比如路径、区域、Account ID、Header 特征。2.2 不要把“一眼看出是 AI 流量”变成口号在配置 Bots 策略的时候最容易犯的一个错误是试图让 Cloudflare 自动完成所有判断。很多人会以为Bot Management 开了之后系统会像人一样识别出“哪些是 AI 爬虫”“哪些是正常 API 调用”但其实它是一个统计系统不是语义系统。它会从很多维度做特征识别TLS 指纹、HTTP 请求顺序、header 顺序、窗口尺寸、鼠标轨迹。这些对浏览器里的真人判断比较准但对纯 API 客户端它只能靠“请求是否足够标准”来猜测。一个合法的开发者用官方 SDK 发起请求很容易被认为 bot一个恶意脚本把 header 伪装得特别完整反而可能拿到高分数。所以我的建议是一定要把流量日志开起来至少保留几天。在 Cloudflare Analytics 或者 Logpush 里把出现次数最多的 UA、路径、IP 段、用户端特征拉出来。哪怕不写复杂规则先观察三天也比对着官方文档能猜中更多的东西。注意不要一上来就套用“严格模式”或者“拦截所有 bot”。在没看日志之前先只做观察和托管质询等你知道真实流量构成之后再加硬规则。3. 给 AI 服务加防护一个最小可行流程这部分我从零开始梳理过一遍顺手整理成了一个可以复用的最小流程。无论你是给大模型 API、AI 工具站还是给 RAG 应用的中间层做防护都可以先按这个顺序走一遍。3.1 前置准备把域名和日志链路打通第一步是确认自己的 Cloudflare 账户有没有对应功能权限。Bot Management 通常不是免费功能Rate Limiting、WAF Custom Rules 在不同套餐里也有差异。如果你进入控制台发现某个功能不存在先不要折腾先确认当前套餐的功能边界。第二步是把域名 DNS 接入 Cloudflare让流量经过代理。这一步常见问题是不确定 DNS 记录是否已经“橙色云朵”开启。可以在 Cloudflare 的 DNS 页面检查只有代理状态开启WAF、Bots、Rate Limiting 这些安全功能才会生效。第三步是配置日志出口。我的习惯是先用 Cloudflare Analytics 的实时日志或者如果你的套餐支持打开 Logpush把 HTTP 请求日志推送到自己的对象存储或者日志平台。没有日志后面所有判断都是盲猜。3.2 三个动作先限速再质询最后精细拦截推荐先创建一个“全局默认宽松”的阶段再叠加规则。整体配置分成三层第一层是基础限流保护模型接口不被海量请求打死。在 Security → WAF → Rate Limiting Rules 里创建一条规则针对/v1/、/api/这类核心路径设置一个比较宽松的阈值比如“同一个 IP 每 60 秒最多 120 次请求”。这个阈值不要一开始设太严格先观察线上真实调用频率。如果线上确实有批处理任务阈值可以放宽但每一层都要有记录。第二层是托管质询。给可疑流量加 Managed Challenge而不是直接拦截。要做的事是在 Custom Rules 里当请求路径匹配/v1/且 bot score 小于等于 30 时执行 Managed Challenge。这里的效果是正常用户通过浏览器能通过挑战普通 API 脚本会因为无法执行 JavaScript 而失败。但是你自己服务的服务端调用如果也在同一层也要注意。如果你的产品是 B 端 API 形态这一层一定要仔细评估因为它可能把正常开发者拦住。第三层才是精确拦截。基于已经观察到的恶意特征比如高频 IP 段、异常 User-Agent、非常规请求体大小创建针对性规则。这些规则宁可窄不要宽。每一条规则都要能说清楚它拦截的是什么。3.3 最小验证和回滚配置完之后不要马上收工。先用两个角色验证入口。第一个角色是用命令行直接请求核心接口确认请求能否返回预期结果。如果返回 403说明规则过严需要看看具体命中了哪条规则。第二个角色是打开 Cloudflare 的 Security 事件页面查看刚才那几条请求的 bot score 和命中规则。在事件列表里你会看到每条请求到底是被哪条规则处理的。这个页面是排查问题的第一个入口。如果某个规则导致误伤立刻把它从“拦截”改成“托管质询”或者直接停用。规则改了之后一般几秒内生效。稳定的做法是先加一条“只记录不处罚”的规则跑一两天看看会命中哪些流量再改成真正的动作。4. 真正容易踩坑的地方不是配置而是误伤4.1 三类“正常但很像异常”的调用方第一类是 AI Agent 的自主请求。很多 Agent 会发请求到你的接口用于理解页面、生成摘要、判断分类。这类请求没有浏览器环境也不会执行 JS 挑战UA 千奇百怪有的还会带上一个看起来很假的“bot”字样。但它们是真实产品的一部分不能直接封。第二类是测试工具和自动化验证。你在本地跑一个脚本循环调用 100 次接口验证 token 是否正常、输出是否稳定。Cloudflare 很可能把这类循环流量识别成 bot 或限流对象。你被封了之后一脸懵明明是自己开发的系统怎么还把自己拦了第三类是搜索引擎和第三方采集器。比如一些 SEO 工具、知识库同步工具会定期抓取你的页面。它们不是恶意爬虫但如果不限流可能会占用大量资源。4.2 排查链路从日志回放而不是直接改参数遇到“访问被拦截”或者“请求超时”我建议先不要直接调大阈值或者关掉安全功能。按照下面这个链路排查先看现象是 403、是超时、还是返回异常 JSON再进 Security 事件确认命中规则。里面会显示“Bot Score”“Country”“IP”“Rule”等信息。再看业务特征这个请求是真实用户发起的还是程序调用的如果是程序它有没有能力处理质询最后调整规则动作。优先级从来都是“先放开再逐步收紧”不要反向操作。这个顺序能避免一个最常见的问题把普通故障误判成 WAF 问题。有几次我发现请求没有 403但响应特别慢最后一查是模型推理时间太长和 Cloudflare 一点关系都没有。4.3 服务不同客户端时策略需要分层如果你的 AI 服务同时面向 Web 端用户和 API 开发者绝对不建议用同一套策略。Web 端可以开启严格的浏览器挑战。API 端则应该完全走另一套逻辑用 API Key、签名、账户级鉴权来验证身份而不是依赖“是不是真人”这种不确定性判断。Cloudflare 可以按路径区分规则。我的习惯是/web/*路径走严格挑战保证只有真人访问。/api/v1/*路径不启用浏览器挑战只做限流和 API Key 校验。这样正常 API 开发者不会因为“看起来像 bot”而被误伤Web 用户也不会因为无法处理挑战而卡在加载页。这个分层看似简单但能解决掉一大半“AI 流量像疯了一样”的困扰。提醒很多“更高级”的安全功能是有版本身和成本门槛的。如果你现在使用的是基础版界面里没有某些功能先不要为了某个安全开关去升级套餐。先用 WAF 规则和限流把主要问题挡住比堆功能更实际。5. 从一次救火到一套可持续的流量治理框架5.1 一个可复用的五步框架我最后把这次经验收成一个框架名字不花哨就叫“AI 流量治理五步法”。如果你需要快速给一个新 AI 项目做防护可以按这个顺序往下走。步骤做什么常用出口1. 看清流量打开 Analytics/Logpush统计主要 UA、路径、IP、状态码Cloudflare Analytics、自定义日志平台2. 划出业务边界区分 Web 端、API 端、内部调用、外部工具路径前缀、Header、ApiKey3. 给不同边界设置基线Web 端走挑战API 端走鉴权与限流Custom Rules、Rate Limiting4. 加一层兜底对异常特征做针对性质询或拦截Bot Score、ASN、国家、路径特征5. 持续观测和复盘每周看一次安全事件调整阈值观察误伤率Security Events 日志、告警这里的关键不是第几步用了什么功能而是“看清流量”永远在“配置规则”前面。跳过第一步后面每一步都可能跑偏。5.2 别追求“拦截所有可疑请求”要追求“可疑请求可测量”在 Cloudflare 里做防护时我见过最极端的心态是把能开的全都打开把可疑的全拦截结果产品不可用。也见过最懒散的心态完全不管觉得流量疯就疯吧反正有回源保护。这两种都走不通。AI 应用的安全本质上是一个“成本与可用性”的平衡。恶意流量会消耗模型 token占用 GPU产生高额账单所以你必须管。但管得太狠又会把正常用户挡在外面。所以核心目标不是“拦截所有机器人”而是“让恶意请求付出成本让正常调用保持顺畅让所有流量都可测量”。也就是说你要尽量做到每条被拦截的请求都有日志可以回看每条放行的请求都有评分和特征记录下来。这样即便某个规则有误伤你也能快速定位而不是靠猜。5.3 这套配置并不适用所有场景最后说边界。Cloudflare 给 AI 应用做入口防护并不适合所有情况。如果是一个纯局域网内部工具、完全不开放在公网的模型服务其实不需要关心 bot 策略直接把来源限制到内网更合适。如果是一个面向高并发、低延迟的企业级 API 平台Cloudflare 加在回源前面会引入一跳网络虽然通常影响有限但如果你对 P99 延迟要求极端苛刻就必须提前做性能压测。如果要处理的是完全离线的模型推理任务那入口防护更不是核心问题算力调度才是。另外如果你的主要场景是服务端到服务端的调用建议优先考虑 Cloudflare 的 API Shield 能力结合双方证书校验、端到端加密和策略引擎而不是只依赖 Bots 模式。多数时候API 服务的安全看门人应该是“凭证和签名”而不是浏览器行为特征。这次经历让我对“AI 应用接入 Cloudflare”这件事有了完全不一样的理解。最开始我以为把域名放到 Cloudflare 后面打开几个安全开关就万事大吉。后来才发现真正的困难不是“有没有防护”而是“防护规则是否匹配你的流量模型”。在 AI 的世界里自动化和真人之间的分界已经越来越模糊你要处理的不是一次性的攻击而是持续变化、持续混合、持续重复的调用洪流。所以如果你现在也在用 Cloudflare 托管 AI 服务并且被后台日志里那些“疯了一样”的请求困扰先停一下不要急着把严格模式拉满。开日志看三天把路径和客户端类型理清楚再用规则去切。你会发现流量其实没有疯只是你还不够了解它。