AI 接口的限流规则为什么总配错？计数维度、阈值反推与误杀处理

直接回答： 一条限流规则由四件事决定：匹配哪些请求、按什么维度计数、在多长的窗口里数到多少、超过之后做什么、持续多久。AI 接口出问题，绝大多数错在第二件——按 IP 计数，而真正要控的是租户、API Key 或 token 预算。按官方口径，Free 与 Pro 只能按 IP 计数，Business 增加 NAT 支持，Query、Host、Header、Cookie、ASN、国家、Path、JA3/JA4、JSON 字段、请求体、表单字段与自定义表达式要到 Enterprise 才可用。还有一条常被忽略：限流规则「不是为了允许精确数量的请求到达源站」，计数器按数据中心统计且更新存在几秒延迟——它是削峰工具，不是配额系统。

先纠正一个前提：限流规则不是配额系统

Cloudflare 在限流规则文档里写了一句很关键的话：限流规则「不是为了允许精确数量的请求到达你的源站」。原因是计数器按数据中心统计，而且从检测到请求到更新计数之间可能有几秒延迟，在这段时间里多出来的请求仍然会到达源站。

对普通 Web 接口，这点偏差通常无所谓。对 AI 接口不是：一次请求背后可能是几十秒的 GPU 占用，几秒钟里放行的超额请求，就足以把队列压满、把这一分钟的账单推高。

所以限流要放在正确的位置上理解：它是在边缘上减少异常量、削掉尖峰的手段，真正的额度、配额扣减与计费必须在你自己的服务里做。把前者当成后者，是这类配置里最常见也最贵的误会。

还有一条规则引擎的行为值得记住：限流规则按顺序执行，Block 这类动作会终止后续规则的评估。顺序写错，可能出现「一条粗规则把所有细规则挡在后面」的情况。

一条规则的四件事

匹配什么。 用规则表达式选择进入这条规则的请求。可用字段按套餐递增：Free 只有 Path 与已验证 bot；Pro 增加 Host、URI、Full URI、Query；Business 再增加 Method、Source IP、User Agent；Enterprise 可以使用通用请求字段、请求头字段、Bot Management 字段与请求体字段。

按什么计数。 这就是 characteristics，它决定「哪些请求算在同一个桶里」。Free 与 Pro 只有 IP；Business 是 IP 与 NAT 支持；Enterprise 增加了 Query、Host、Headers、Cookie、ASN、Country、Path、JA3/JA4 指纹、JSON 字段值、请求体、表单字段值与自定义表达式。

在多长的时间里数到多少。 Period 是计数周期，Requests per period 是阈值。可选值从 10 秒到 65,535 秒，但每个套餐的上限不同：Free 固定 10 秒，Pro 最长 1 分钟，Business 最长 10 分钟，Enterprise 最长 65,535 秒。

超了之后怎么办，持续多久。 Duration 是缓解时长：Free 固定 10 秒，Pro 最长 1 小时，Business 与 Enterprise 最长 1 天，Enterprise 还可以通过 API 指定自定义时长。动作行为默认在整个缓解期内一律执行，不管速率是否已经回落；Enterprise 可以改成按速率放行（throttle），只在超过速率时拦截，速率降下来就自动放行。

维度选错，会有四种典型后果

一、按 IP 计数，误杀一整片正常用户。 企业出口、校园网、移动运营商的 CGNAT 后面是成百上千个真实用户。他们共享少量出口 IP，其中只要有一个人在批量调用，整片人会被一起拦掉。

二、按 IP 计数，也挡不住分布式低频。 住宅代理池里每个 IP 的请求数都很低，永远到不了你设的阈值。这类流量要靠 IP 之外的判据——JA3/JA4 指纹、Bot Management 字段、行为序列。

三、真正要控的对象在请求头或请求体里。 租户 ID、API Key、模型名、max_tokens 都在 header 或 body 中。要按「每个租户每分钟」计数，就必须用 Header、Cookie 或 JSON 字段值做计数维度，而这些是 Enterprise 才有的计数维度。

四、按请求数计数，控不住成本。 一次请求花多少钱取决于模型和 token 数，不是请求数。想按成本削峰只能近似：用 Path 或 JSON 字段把模型分档后分别设阈值；或者用复杂度计数模型按请求的「复杂度」而非请求数计数，它属于 Advanced Rate Limiting。

选维度的经验顺序是：先问「我要保护的是谁的钱」。如果是平台的 GPU 成本，按租户或 Key；如果是单个用户的误用，按会话或用户标识；只有当你确实要防的是单一来源的暴力调用时，按 IP 才是对的。

一张按套餐的能力表

	Free	Pro	Business	Enterprise（合同含应用安全）	Enterprise + Advanced Rate Limiting
规则条数	1	2	5	100（取决于合同）	100
计数维度	IP	IP	IP、NAT	加 Query、Host、Header、Cookie、ASN、国家、Path、JA3/JA4、JSON 字段、请求体、表单字段、自定义	同左，另加自定义计数表达式
计数周期	10 秒	最长 1 分钟	最长 10 分钟	最长 65,535 秒	最长 65,535 秒
缓解时长	10 秒	最长 1 小时	最长 1 天	最长 1 天，可 API 自定义	最长 1 天
表达式可用字段	Path、已验证 bot	加 Host、URI、Full URI、Query	加 Method、源 IP、User Agent	通用请求字段、请求头、Bot Management 字段、请求体	同左
其他	—	—	缓存排除、自定义计数表达式	可按速率放行	复杂度计数模型

三点说明：JA3/JA4 与 Bot Management 字段需要已购买 Bot Management；请求体字段的可用性取决于 WAF 套餐；Enterprise 必须合同里含应用安全才有 rate limiting rules，条数取决于合同条款。

阈值怎么反推，而不是拍一个整数

从成本反推。 先算单次调用的可变成本（token 单价 × 平均 token 数，加上推理资源占用），再定一个你能接受的「每分钟最大支出」，除以单次成本就得到每分钟请求数。这个数字才是阈值的起点。

从容量反推。 看 GPU 队列或并发上限能同时吃下多少请求，再按租户数或套餐档位分配。重点控制的是「一个租户能占多少」，不是「全网总共多少」。

从正常行为反推。 取正常业务峰值的 p99，再留出合理余量。不要凭直觉取 100、1000 这样的整数——整数和你的成本结构没有任何关系。

先观察，再执行。 新规则先用挑战这类可恢复的动作跑一段时间，看它拦下了谁，确认误杀率可接受之后再收紧到阻断。能不能「只记录不处置」取决于套餐：WAF 自定义规则的 Log 动作是 Enterprise 才有的能力。

短周期加长缓解，惩罚的是正常突发

AI 客户端的调用形态是突发的：一个 Agent 接到任务后可能连发几十个请求，然后安静一段时间。如果计数周期是 10 秒而缓解时长是 1 小时，一次正常的突发就会让这个用户被锁一小时。

更好的组合是长周期、短缓解、按速率放行：周期拉长到几分钟，让突发有空间；缓解时长缩短，让被拦的一方尽快恢复；再打开 throttle，让速率降下来之后自动放行，而不是在整个缓解期内一律拦截。这套组合里，前两件在任何套餐都能配，throttle 需要 Enterprise。

还有一个容易忽略的选项：Business 及以上支持缓存排除，可以让限流规则只在未命中缓存的请求上计数，避免缓存命中的重复请求把计数器推高。

误杀：你会拦到谁

• 共享出口。 企业、学校与移动网络的用户共用出口 IP，一个来源后面是很多人。
• 移动网络。 IP 会在会话期间切换，按 IP 计数既会误杀，也会漏判。
• 第三方集成。 合作方用同一个 Key 或同一个出口网关调用你的接口，把它算成一个「用户」就可能一拦全拦。
• 合法的自动化。 官方文档明确提醒：对已验证 bot 施加限流可能影响 SEO。爬虫、监控与 AI Agent 里的合法部分要单独放行。
• 被拦的人看到什么。 官方文档把被拦的访客引导去查看 1015 错误的说明，所以 1015 的出现次数可以当作「限流正在生效」的观测信号之一。

处理误杀的顺序是：先挑战后阻断；给已知的重要来源加跳过规则；把挑战通过率与关键路径的错误率当成指标持续看，而不是配完就走。

限流之外：检测、会话级滥用与落地顺序

限流解决的是「量」，解决不了「这个调用合不合法」。这部分要靠检测：

• Schema 校验。 Schema Validation 2.0 产出的是常开检测结果，本身不缓解流量，需要你用 WAF 自定义规则去执行 cf.schema_validation.uploaded.violated。
• JWT 校验。 官方文档提醒它不会自动轮换 JWKS，只校验 header 与 cookie 里的令牌，并且需要为 OPTIONS 预检放行。
• 用量异常检测。 仅 Enterprise：按会话以 10 分钟分桶、7 天窗口给出 p50/p90/p99 与置信度；要在此基础上按会话限流，需要 Advanced Rate Limiting。
• 序列分析。 按会话标识还原调用序列，序列最长 9 个操作，评分基于最近 24 小时的数据。
• 会话标识。 最多 10 个；未配置且 Authorization 出现在超过 1% 的合格采样请求中时，Cloudflare 会自动配置。

一份可执行的落地顺序：① 列出端点与各自的单次成本；② 给每个端点选计数维度，租户或 Key 优先于 IP；③ 先用挑战动作观察一到两天；④ 按套餐档位分档设阈值；⑤ 叠加 schema 与 JWT 校验挡住非法调用；⑥ 把误杀率、1015 数量与源站错误率接进监控。

边界要写清楚：边缘能按可观测字段削峰，但它不知道这个租户这个月还剩多少额度，也不知道这笔调用该不该计费。这些只有你自己的 API 层知道。

常见问题

只按 IP 限流为什么在 AI 接口上总出问题？ 两个方向同时出问题。企业出口与 CGNAT 后面有大量真实用户，会被一起误杀；住宅代理池每个 IP 的请求量都很低，永远触发不了阈值。要控的是租户或 Key 时，就得用请求头或 JSON 字段做计数维度。

阈值到底设多少？ 从成本或容量反推，不要拍整数。算出单次调用的可变成本，定一个可接受的每分钟支出上限，除以单次成本得到每分钟请求数；或者从 GPU 队列容量倒推每个租户能占的份额。

能按 token 或成本限流吗？ 边缘拿不到真实的 token 消耗。可行的近似是按 Path 或 JSON 字段把模型分档后分别设阈值；复杂度计数模型可以按请求复杂度而非请求数计数，它属于 Advanced Rate Limiting。

限流会不会影响正常用户和 AI Agent？ 会，尤其是短周期加长缓解的组合。用长周期、短缓解、按速率放行来削峰而不是断流，并给已验证 bot 与已知合作方加跳过规则。

是不是必须 Enterprise 才能配好？ 取决于你要按什么计数。只按 IP 的场景低套餐也能做；要按租户、请求头、JSON 字段或模型分档计数，或者要按速率放行、按复杂度计数，就需要 Enterprise，其中复杂度计数还需要 Advanced Rate Limiting。

怎么确认规则真的在生效？ 看三处：被拦请求返回的 Cloudflare 错误页（官方把访客引导到 1015 说明页）、规则命中与动作统计，以及源站侧的错误率与队列深度是否真的降下来。

相关阅读

• AI SaaS 如何控制 API 调用成本和异常流量？
• AI SaaS 如何防止 API 被恶意调用？
• API Key 泄露后如何防止接口被滥用？
• Cloudflare WAF 能力说明

如果你的接口成本已经对不上账，但还不确定该按哪个维度计数，可以把端点清单和成本结构给我们——一起把限流规则从头配一遍。