最可靠方式是用hey等工具并发压测并交叉验证日志、状态码与系统连接：检查error.log中limiting requests字样、log_format中$limit字段、返回设定的limit_req_status码，同时用ss -s和后端指标确认请求未穿透。
直接用并发压测工具模拟真实请求节奏，观察 Nginx 是否按 limit_req 配置拦截超额请求，并同步核对日志、状态码和系统连接行为——这是验证限流是否真正起效的最可靠方式。
用 hey 或 ab 发起可控并发请求
推荐使用 hey（比 ab 更适配 HTTP/1.1 和 keepalive 场景）：
- 基础测试：比如配置了
rate=5r/s，可运行hey -n 100 -c 20 http://your-domain.com/，发 100 个请求、最大 20 并发，预期约 80–90% 请求会排队或被限 - 验证突发容量：若设了
burst=10 nodelay，就用-c 15启动 15 路并发，前 10 个应快速响应，其余 5 个大概率返回 503（或你自定义的limit_req_status） - 排除连接复用干扰：加
-disable-keepalive强制每请求建新 TCP 连接，确保压测的是“真实连接频次”，而非单连接内多请求
重点看三项交叉信号
不能只盯响应成功数，要同时检查：
-
错误日志：执行
tail -f /var/log/nginx/error.log，出现limiting requests, excess: X.XX或delayed字样，说明模块已介入 -
访问日志字段：在
log_format中加入$limit和$limit_key，例如：log_format main '$remote_addr - $limit_key $limit ...'，可明确看到哪个 IP 被限、命中哪个 zone -
返回状态码与响应头：确认实际返回的是你设定的
limit_req_status（如 429 或 503），且响应体为空或符合预期，避免前端静默吞掉错误
注意真实 IP 和路由路径干扰
两类常见误判必须提前处理：
-
代理层导致 IP 失真：如果 Nginx 前有 CDN、SLB 或其他反向代理，
$binary_remote_addr会变成代理 IP。需配置set_real_ip_from+real_ip_header X-Forwarded-For，再改用$realip_remote_addr作为限流 key -
SPA 单页应用刷屏效应：像
try_files $uri $uri/ /index.html会让所有资源（JS/CSS/API）都落入同一 location，全部计入限流。建议把 API 接口单独放在/api/下做独立限流，静态资源走无限制路径
结合系统指标确认底层拦截生效
光看 Nginx 返回不够，要确认连接真的没穿透到后端：
- 用
ss -s | grep "tcp:"查看当前 ESTABLISHED 连接总数，应明显低于未限流时的峰值，且不随压测并发线性上涨 - 检查后端服务的请求计数（如 access_log 或 Prometheus 指标），确认被限的请求未到达应用层
- 运行
nginx -T | grep limit_req确保配置已加载，避免 reload 失败或语法错误导致限流未启用
