限流配置没生效通常因配套项缺失或理解偏差：一是limit_req_zone未在http块正确定义且zone名不一致；二是limit_req未置于server/location中，或遗漏burst/nodelay关键参数；三是请求未匹配到限流location；四是未开启limit_req_log_level导致日志无法定位问题。
限流配置没生效，通常不是 limit_req 写错了，而是漏掉了关键配套项或理解有偏差。下面列几个最常踩的坑，按排查顺序梳理清楚。
共享内存区域（zone）未正确定义
limit_req_zone 必须在 http 块中定义，且 zone 名称要和后续 limit_req 指令中的 zone 参数严格一致。大小写、拼写、空格都不能错。
常见错误示例：
- 在
server块里写limit_req_zone→ Nginx 启动失败或直接忽略 - 定义了
zone=perip:10m，但使用时写成limit_req zone=per_ip→ 找不到 zone，限流不触发 - 内存大小设得太小（如
1m），导致高并发下 zone 溢出，新请求无法被记录 → 表现为“有时生效、有时不生效”
limit_req 没放在正确的作用域或缺少必要参数
limit_req 必须放在能生效的位置：一般在 server 或 location 块中；若放在 http 块，会影响所有虚拟主机，容易误判。
关键参数缺一不可：
-
burst和nodelay不是可选“锦上添花”，而是控制突发流量行为的核心。没设burst，默认 burst=0 → 只允许严格按 rate 处理，超一点就 503 - 漏掉
burst却以为“应该能缓存几个请求”，实际立刻拒绝，误以为“没生效” - 用了
nodelay但没配burst→ Nginx 报配置错误，启动失败（日志里有提示）
请求匹配不到 location 或被其他指令绕过
limit_req 是按 location 匹配生效的。如果请求路径没进到配置了限流的 location，自然不受控。
典型场景：
- 静态资源走
location /static/，但限流只配在location /api/→ 访问/static/js/app.js完全不触发 - 用了
try_files或rewrite跳转，原始请求被重写后进入另一个 location → 原 location 的limit_req失效 - HTTP/2 或 gRPC 流量走的是不同处理链路，普通
location配置可能不覆盖 → 需确认协议和路由是否匹配
日志没开或没看对地方，误判“没生效”
Nginx 默认不记录限流拒绝详情。不打开日志，就只能靠返回码（503）盲猜，很难定位是限流还是后端挂了。
建议开启调试级限流日志：
- 在
http或server块加：limit_req_log_level warn; - 同时确保
error_log级别 ≤ warn（如error_log /var/log/nginx/error.log warn;） - 触发限流时，error 日志会出现类似：*12345 limiting requests, excess: 5.123 by zone "perip" → 明确说明是哪个 zone 拒绝、超了多少
