nginx限流必须分两步：先在http块用limit_req_zone定义规则，再在server或location中用limit_req启用；limit_req_zone仅允许出现在http上下文，否则启动报错“directive is not allowed here”，且zone名须全局唯一、内存大小需按客户端规模合理配置。
必须分两步：先在 http 块用 limit_req_zone 定义规则，再在 server 或 location 里用 limit_req 启用；漏掉任意一步，限流完全不生效。
为什么 limit_req_zone 必须写在 http 块里
这个指令只允许出现在 http 上下文。写到 server 或 location 里会直接导致 Nginx 启动失败，错误信息是："limit_req_zone" directive is not allowed here。
常见误操作：
- 把
limit_req_zone放进location /api/ { ... }里，配置 reload 成功但实际无效 - 多个
server块各自定义同名zone（如都叫ip_limit），Nginx 拒绝加载，报错提示 zone 名重复
zone=ip_limit:10m 中的 10m 不是随便写的：1MB 内存约存 1.6 万个客户端状态。若你设了极低速率（如 0.1r/s）又面向百万级用户，10m 很快撑满，新 IP 就无法被记录——此时限流反而“失效”。
$binary_remote_addr 为什么不能换成 $remote_addr
$binary_remote_addr 是固定长度二进制表示（IPv4 为 4 字节，IPv6 为 16 字节），哈希稳定、内存占用小；$remote_addr 是变长字符串（如 "192.168.1.100" 占 11 字节），容易因空格、换行、编码差异导致键错乱。
实测对比：
- 用
$remote_addr+zone=ip:10m，实际只能存约 2 万个 IP - 换成
$binary_remote_addr，同一块内存能存超 200 万个 IP - 压测时同一 IP 发 10 个请求全放行？大概率是键解析不一致，限流根本没命中
burst 和 nodelay 怎么配才不卡也不放水
burst 不是“允许超速”，而是“最多缓存几个等令牌”；nodelay 决定这些缓存请求要不要排队。
- 不加
nodelay：第 6 个请求（rate=5r/s,burst=5）进入队列，每 200ms 放一个，第 5 个排队请求要等 1 秒——用户明显卡顿，还可能触发客户端超时 - 加
nodelay：前 5 个超速请求立刻处理，第 6 个开始直接返回503 Service Temporarily Unavailable，响应快、边界清晰 -
burst=100看似宽松，实则每个 IP 要维护 100 个等待上下文，内存和调度开销陡增；生产环境建议burst ≤ 20
典型安全配法：limit_req zone=ip burst=10 nodelay;，再配合 limit_req_status 429; 返回标准限流码，前端可据此做退避重试。
怎么验证限流真在工作
reload 配置成功 ≠ 限流生效。必须实测 + 查日志：
- 用
ab -c 10 -n 100 http://your.site/或wrk -t10 -c10 -d5s http://your.site/模拟并发，观察是否出现503或429响应码 - 实时盯住错误日志：
tail -f /var/log/nginx/error.log，真正触发限流时会出现类似limiting requests, excess: 3.123 by zone "ip_limit"或rejected字样 - 注意 CDN 或代理（如 Cloudflare）：若前端有反向代理，
$binary_remote_addr拿到的是代理 IP，需改用$http_x_forwarded_for并配合set_real_ip_from调整，否则限流对象错位
最常被忽略的一点：共享内存区域大小（如 10m）和 rate 单位（r/s 或 r/m）共同决定了实际承载能力。设得太小或太细，桶就“漏光”了，不是限得严，而是限不住。
