limit_req单独配置无效，因其仅为启用开关，必须配合http块中定义的limit_req_zone规则才能生效；后者负责存储状态、计算速率并记录ip。
直接上结论：用 limit_req + limit_req_zone 是最轻量、最有效、且无需额外组件的 CC 防御方式；但单独配 limit_req 会完全失效，必须两步一起走。
为什么 limit_req 单独写没用？
因为 limit_req 只是“启用开关”，它不定义规则，只引用规则。真正存状态、算速率、记 IP 的逻辑全在 limit_req_zone 里。
-
limit_req_zone必须写在http块里，否则 Nginx 启动报错：unknown directive "limit_req_zone" - 常见错误：把
limit_req_zone写进server或location，Nginx 直接拒绝 reload - key 用
$binary_remote_addr，别用$remote_addr—— 后者对 IPv6 不友好，还多占内存 - 10m 共享内存 ≈ 支持 16 万个 IP，小站点够用；大流量或需 IP+URI 组合时，建议升到 20m
burst 和 nodelay 到底怎么配才防得住 CC？
这两个参数决定攻击者能不能“打满带宽”或“耗尽连接队列”。配错等于开门迎客。
-
burst=0：超速请求立刻返回 503/429，但真实用户点快了也容易误伤 -
burst=10 nodelay：允许瞬时 10 个请求砸进来，后续仍按 rate 匀速放行 —— 这是防 CC 的黄金组合 - 不加
nodelay时，Nginx 会把 burst 内请求摊到几秒内发给后端，攻击者可发 100 个请求让 Nginx 持续排队 10 秒，反而加重负担 - 登录页等高危路径建议
rate=1r/s burst=3 nodelay；API 搜索接口可用rate=5r/s burst=15 nodelay
如何避免 NAT 用户被误封？
纯按 IP 限流对学校、企业出口这类共享公网 IP 的场景极不友好，真实用户会集体 429。
- 优先改用业务维度限流：比如按
$uri或$request_uri，保护 /login、/sms/send 等敏感路径 - 更精准的做法是组合 key：
"$binary_remote_addr$uri"，既能防单 IP 刷多个接口，又比纯 IP 更抗绕过 - 如果必须按 IP，且已知有大量 NAT，可配合
map提取可信 Header（如内部 CDN 透传的X-Real-IP）做 fallback - 务必开启
$limit_req_status记入 access_log，方便查日志确认是 “rejected” 还是 “passed”，快速定位误伤
别漏掉这三件事，否则限流形同虚设
配置写完只是开始，没配套动作，你根本不知道它有没有在工作。
- 加
limit_req_status 429：默认 503 语义不清，前端无法区分是后端崩了还是被限流了 - log_format 里加
$limit_req_status字段，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $limit_req_status'; - 不要在
if块里调用limit_req—— Nginx 官方明确不支持，行为不可预测，reload 可能成功但实际不生效
最常被忽略的一点：limit_req 对 HTTPS 的 TLS 握手阶段无感知，但它能压住握手后的 HTTP 请求洪峰。如果你发现限流后仍有大量连接堆积，大概率是没配 limit_conn，得补上并发连接数限制。
