Cloudflare 可能将同一 zone 上的 Workers 子请求计为单独请求，这会导致速率限制规则比预期更早触发。当速率限制规则配置为将 Also apply rate limiting to cached assets 设为 false 时，会发生此行为。
为防止此行为，您必须使用 cf.worker.upstream_zone 字段，从速率限制规则中排除来自同一 zone 的任何 Workers 子请求。例如，您可以在速率限制规则表达式中添加以下子表达式：
and (cf.worker.upstream_zone == "" or cf.worker.upstream_zone != "<YOUR_ZONE>")第一个条件（测试空字符串）将匹配直接访问者请求，而第二个条件将匹配不来自您 zone 的子请求，从而有效地将同一 zone 的子请求从速率限制规则中排除。
如果您使用 Origin Rules 重写 Host 标头，且速率限制规则的表达式或计数特征中包含 http.host，则规则可能匹配传入请求但未能递增其计数器。
这是因为速率限制规则表达式在两个阶段中进行评估：
- 请求阶段（规则匹配）：表达式针对原始请求进行评估，其中
http.host包含原始主机名。规则按预期匹配。 - 响应阶段（计数器递增）：如果规则使用计数表达式，或已关闭 Also apply rate limiting to cached assets（同时对缓存资源应用速率限制），则计数器递增发生在响应之后。此时，Origin Rules 已将
Host标头重写为新值，因此包含原始主机名的表达式不再匹配。
结果是，规则匹配请求但从不递增计数器，速率限制也从未执行。
要修复此问题，请执行以下操作之一：
- 从计数表达式中移除
http.host条件，并使用其他字段（例如http.request.uri.path）限定计数器范围。 - 更新计数表达式以使用重写后的主机名，而非原始主机名。
- 使用
or条件将原始主机名和重写后的主机名都添加到计数表达式中。
Cloudflare 速率限制规则在基础设施过载期间以故障开放模式运行（允许请求通过而非阻止它们）。当底层基础设施经历高负载时，Cloudflare 可能会跳过受影响请求的速率计数器更新和速率限制执行，而不是阻止合法流量。
故障开放事件没有客户可见的信号。如果速率限制规则未阻止本应捕获的流量（假阴性），且规则配置正确，则受影响数据中心的基础设施负载可能是一个因素。
按数据中心计数： 速率限制计数器按 Cloudflare 数据中心维护。分布在许多数据中心的流量可能使每个数据中心的速率低于阈值，即使聚合速率已超过阈值。为全球分布的流量设置阈值时请考虑这一点。