限流配置不生效需从配置加载和执行两层面排查：先确认配置是否被Nginx实际加载（检查语法、路径、进程参数），再验证是否按规则执行（zone位置、匹配路径、key准确性），并依赖error_log日志确认生效与否，最后排除多层限流干扰。
限流配置不生效，不是配置写错了，就是没真正“上”到正在跑的 Nginx 实例上。排查要从“它到底有没有加载新规则”和“它到底有没有按规则执行”两个层面入手。
一、配置根本没被加载
这是最常被忽略的第一步。Nginx 启动时只读一次配置文件，改完不重载 = 白改。
- 用 nginx -t 检查语法：有报错就停在这里修，别往下走
- 用 nginx -V 看实际加载的配置路径，确认你编辑的文件就是它读的那个（常见坑：改了 /etc/nginx/conf.d/app.conf，但 Nginx 实际加载的是 /usr/local/nginx/conf/nginx.conf）
- 用 ps aux | grep nginx 查看主进程启动命令，里面通常带 -c 参数，指明了配置文件位置
- 多个 Nginx 实例共存时（比如开发环境手启一个、systemd 管理一个），容易改了 A 却在 B 上测试 —— killall nginx && systemctl start nginx 彻底清场再启更可靠
二、配置加载了但没起作用
语法对、路径对、也 reload 过了，还是不限流？重点看三件事：
- limit_req_zone 定义是否在 http 块里：放在 server 或 location 里会直接失效，Nginx 不报错但静默忽略
- limit_req 应用位置是否匹配请求路径：比如你在 /api/ 下配了限流，但用户访问的是 /v1/login，那就完全绕过了
- key 是否符合预期：用 $binary_remote_addr 限 IP，但你前端有 CDN 或代理，真实 IP 被藏在 X-Forwarded-For 里 —— 此时所有请求都算同一个 IP，或者全算成 CDN 的 IP，限流就失真了
三、限流生效了但你看不到效果
日志是唯一可信证据。光看返回状态码不够，得看 Nginx 自己怎么说：
- 打开 error_log，级别设为 warn 或 info：error_log /var/log/nginx/error.log warn;
- 触发限流时，一定会在 error.log 里出现类似这行：limiting requests, excess: 5 by zone "limit_zone"
- 如果没有这行，说明压根没走到限流逻辑；如果有，说明限流已生效，只是你测试方式或阈值设置不合理（比如 burst=50 + nodelay，实际几乎不拒绝）
四、多层限流互相干扰
限流不是越严越好，而是要各层职责清晰：
- Nginx 层适合做粗粒度防护（IP、URI 级），别指望它做用户级配额
- 如果后端还有 API 网关限流、应用层 RateLimiter、数据库连接池限制，它们叠加后可能让整体吞吐远低于单层阈值
- 排查时先临时关掉其他层限流，单独验证 Nginx 配置是否工作，再逐层打开观察影响
