Rate limiting 规则要先确认计数对象和缓存边界，再用 Log 观察，再切到挑战或 Block。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
Cloudflare 的 rate limiting rule 不是简单写一个“每分钟 100 次”就完事。计数对象选错、period 太短、action 太强或没有考虑缓存，都可能误伤正常用户。这份清单按官方 WAF 文档顺序排，适合保护登录页、表单或 API 时逐项检查。
适用场景
- 你要保护 WordPress 登录页、结账接口或管理后台不受密码暴破。
- API 被同一 IP 高频调用，但不想完全封掉来源 IP。
- 你有明确的路径、国家、ASN 或请求头可以用于区分恶意流量。
- 你希望在 Cloudflare 侧挡掉部分请求，减少源站压力。
不适用场景
- 你还没有把站点接入 Cloudflare，或 DNS 状态不是生效的橙色云。
- 流量来自大量分布式 IP，单 IP 速率限制效果有限，需要配合 Bot 或 ASN 维度。
- 你没有确认正常用户的最大请求频率，很容易误伤。
- 你只想用 rate limit 替代源站认证和权限校验。
准备材料
- Cloudflare 账号中目标 zone 的管理权限。
- 需要保护的路径、方法和预期请求频率。
- 最近一周的访问日志，确认正常用户和异常用户分布。
- 一个测试 IP 或专用测试路径，方便验证规则。
步骤一：先确定要保护的流量特征
官方文档说明 rate limiting rule 需要表达式、characteristics、period、requests per period 和 action。表达式决定哪些请求被计数，characteristics 决定按什么拆成不同计数器。先把目标写清楚，再填数字。
- 登录接口通常按路径和方法筛选，例如 POST /wp-login.php。
- API 可能按路径、API key 请求头或国家筛选。
- 管理后台可以加上 Source IP 和 ASN 维度，减少 NAT 误伤。
- 不要把所有路径都塞进一条规则，排错会困难。
步骤二：写表达式并选择 characteristics
Cloudflare 规则使用 Rules language。免费版可用字段有限，付费计划支持更多 header、body 和 JA3/JA4 特征。先确认你的套餐支持哪些字段，再写表达式，避免上线后规则不生效。
(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")
- characteristics 至少包含 IP，必要时加 IP with NAT support。
- 付费计划可以按 ASN、Country、Header、Query 或 Path 计数。
- 企业版可以按 JSON body 字段计数，但需要确认表达式语法。
- 测试时先用较宽表达式，观察 Security Events 再收窄。
步骤三：设置 period 和 requests per period
period 是计数时间窗，requests per period 是窗口内触发阈值。免费版通常只有很短窗口；付费计划可以支持更长周期。先参考正常用户最坏情况，给安全余量。
- 记录正常用户一分钟、十分钟内的最大请求数。
- 把阈值设为正常值的 3 到 10 倍，不要直接压到最低。
- 对登录失败次数单独计数，不要只按总请求数。
- 高流量 API 先设一个宽松阈值，稳定后再收紧。
步骤四：选择 action 和 mitigation timeout
官方文档里的 action 包括 Block、Managed Challenge、JS Challenge、Log 等。mitigation timeout 是触发后持续动作的时间。先 Log 观察，再切到挑战或 Block，避免一上线就误伤。
- 登录暴破可以用 Managed Challenge 或 Block，并设置自定义响应。
- API 被脚本滥用时，Block 通常比无限挑战更直接。
- Log 模式适合上线初期，但不减少源站压力。
- mitigation timeout 不要设成永久，给正常用户恢复机会。
步骤五：先用低阈值试运行并看日志
规则上线后，到 Security Events 查看命中次数和命中请求。重点检查是否有办公室 NAT、代理或 CDN 回源 IP 被误判。正常用户 IP 也可能多人共享，只看 IP 会误伤。
- 创建规则后先保存，不直接 Block，用 Log 观察至少一天。
- 按 IP、ASN、国家和路径分类查看命中。
- 用一个测试 IP 触发阈值，确认 action 生效。
- 确认页面没有出现验证码循环或空白响应。
步骤六：与缓存、Custom Rules 和 Bot 功能协作
官方文档说明 rate limiting 与 Managed Rules、Custom Rules、Super Bot Fight Mode 等会按顺序交互。如果命中缓存，请求可能不会回源；勾选 “Also apply rate limiting to cached assets” 可以让 Cloudflare 边缘也计数。
- 纯静态页面不要启用高频计数，避免缓存命中也被计数。
- 登录和 API 请求通常需要看真实请求，不受缓存影响。
- 用 Custom Rules 处理明确的 IP 封禁，用 Rate Limiting 处理频率模式。
- 检查规则顺序，避免 Block 动作终止后续判断造成预期外结果。
可复制规则模板
规则名称：
目标路径：
方法：
表达式：
characteristics：
period：
requests per period：
action：
mitigation timeout：
是否应用到缓存资源：
自定义响应：
上线日期：
观察结果：
实际例子：给 WordPress 登录页加防护
一个内容站发现登录页每天有几万次 POST，大部分来自同一批海外 IP。团队先写表达式匹配 POST /wp-login.php，characteristics 用 IP with NAT support，阈值设为每 10 分钟 60 次，action 先用 Log。观察两天后，发现办公室出口 IP 会超过阈值，于是把阈值提高到 120，并给管理 IP 用 Custom Rules 放行。随后切到 Managed Challenge，一周内源站登录请求明显下降，正常用户没有大量反馈登录异常。
验收清单
- 目标路径和方法与表达式一致。
- characteristics 已覆盖正常用户和 NAT 场景。
- period 和阈值有日志依据。
- action 已从 Log 逐步切换，没有直接全量 Block。
- Security Events 能查到命中记录。
- 缓存资源和源站行为符合预期。
- 测试 IP 能稳定触发和解除规则。
常见坑
- 把整站所有请求计数，静态资源缓存命中也被算进阈值。
- 只用 IP 计数，办公室 NAT 或运营商出口 IP 被误伤。
- 阈值设得太低，上线几分钟就把正常用户挡住。
- 直接 Block 而不 Log，误伤后难以回查。
- 忘记设置 mitigation timeout，误伤持续几天。
排错路径
- 规则不命中：检查表达式字段是否受套餐限制，以及请求是否走了缓存。
- 正常用户被挡：查看 Security Events 中 IP/ASN，提高阈值或调整 characteristics。
- Block 后仍收到请求：确认规则已部署到正确 zone，并检查 DNS 是否走 Cloudflare。
- 验证码循环：检查 Managed Challenge 是否与源站登录跳转冲突。
- API 请求仍打到源站：确认路径、方法和请求头表达式与真实流量一致。
后续维护建议
更新日期：2026-08-20。上线后每周看一次命中趋势，每月对照访问日志调整阈值。新增登录页、API 或活动页面时重新评估是否需要独立规则。Cloudflare WAF 文档更新后，检查字段、套餐限制和规则顺序是否有变化。