nginx限流落地需建立三层约束：策略分层（防护/保护/体验型）、配置模板化（禁用手写、公式算zone大小）、灰度与可观测闭环（压测验证+prometheus监控告警）。
团队开发中，Nginx 限流配置容易各自为政：有人按 IP 限 10r/s，有人对登录路径限 5r/m 却漏配 burst，还有人把 zone 内存设成 1m 导致高并发下 key 淘汰失准——结果就是线上限流形同虚设，或误伤正常流量。要真正落地、可维护、能审计的限流标准，关键不是堆参数，而是建立三层约束：策略分层、配置模板化、灰度与可观测闭环。
一、按业务风险分级定义限流策略类型
不区分场景的“统一限流”等于没限。建议团队明确三类策略，并写入《后端接入规范》：
-
防护型限流：面向登录、短信发送、密码重置等高敏感接口。强制要求
rate=5r/m+burst=3+nodelay，拒绝排队，直接拦截暴力尝试； -
保护型限流：面向核心 API（如订单创建、支付回调）。推荐
rate=30r/s+burst=60（不加 nodelay），允许短时脉冲，但平滑削峰； -
体验型限流：面向静态资源、搜索建议等低敏感接口。可用
limit_rate 256k控制单连接带宽，避免大文件拖慢整体响应。
二、配置必须模板化，禁用自由发挥
所有限流配置禁止手写，统一使用团队提供的 Ansible 模板或 CI/CD 插件生成。例如：
- 每个
limit_req_zone必须带注释说明用途、生效范围、QPS 设计依据（如“防撞库，参考近30天登录峰值×1.5”）； -
zone大小按公式计算：预期独立限流 Key 数 × 32 字节（$binary_remote_addr占约 32B），最小不得低于 5m； - 禁止在
http块外定义 zone，禁止在location中嵌套多个limit_req而不加注释叠加逻辑； - 白名单绕过必须用
map + geo组合实现，且白名单列表走配置中心管理，不可硬编码。
三、上线前必做两件事：压测验证 & 熔断观测
配置不是写完就上线。团队需固化以下动作：
-
压测验证：用 wrk 或 go-wrk 对目标 location 发起 2×rate 流量，检查是否稳定返回 503（nodelay 场景）或延迟上升（无 nodelay 场景），同时确认 Nginx error log 中出现
limiting requests记录； -
熔断可观测：在 Prometheus + Grafana 中预置看板，监控
nginx_http_limit_req_rejected_total和nginx_http_limit_req_delayed_total两个指标，设置告警阈值（如 5 分钟内拒绝率 > 3% 触发 Slack 告警）； - 每次发布后 15 分钟内，SRE 必须巡检限流命中日志，确认被限 key 是否符合预期（如非白名单 IP、非爬虫 UA）。
限流标准不是越严越好，而是让每一次配置变更都可解释、可验证、可回溯。当新同学入职，他打开文档就能知道“为什么这个接口 burst=10 而不是 20”，而不是翻三天日志猜前任意图。
