验证limit_conn是否生效的核心方法是用hey或ab模拟高并发连接，观察nginx是否按配置拒绝超额连接，并交叉验证错误日志（含“limiting connections by zone”）、返回状态码（如503）及系统连接数（如ss -s统计）是否符合预期。
直接用并发连接工具模拟真实压力，观察 Nginx 是否按预期拒绝超额连接，并确认日志、状态码和后端负载是否符合配置逻辑——这是验证 limit_conn 在极限压力下是否真正生效的核心方法。
用 hey 或 ab 模拟高并发连接
推荐使用 hey（比 ab 更适合 HTTP/1.1 和 keepalive 场景）：
- 基础压测：`hey -n 200 -c 50 http://your-domain.com/` 表示发起 200 个请求，最大并发 50 连接
- 突破阈值测试：若配置了 `limit_conn perip 10`，就用 `-c 15` 启动 15 路并发，应有约 5 个请求返回 503（或你设的 limit_conn_status 状态码）
- 注意 keepalive 影响：HTTP/1.1 默认复用连接，单个客户端可能只建 1 个 TCP 连接却发多个请求；如需严格测试“连接数”，可加 `-disable-keepalive` 强制每请求新建连接
重点观测三项反馈信号
不能只看响应结果，要交叉验证三类输出：
- 访问日志中 $limit 和 $limit_key 字段：在 log_format 里加入它们，可明确看到哪些 IP 被限、命中哪个 zone（如 `addr` 或 `perip`）
- 错误日志关键词：`tail -f /var/log/nginx/error.log` 中出现 limiting connections by zone "perip" 即表示模块已触发
- 返回状态码与响应头：检查是否返回你设定的 `limit_conn_status`（如 429 或 503），并确认响应体为空或符合预期（避免被前端静默吞掉）
排除干扰项：真实 IP 与 SPA 路由陷阱
两类常见误判场景必须提前处理：
- CDN 或反向代理后失真：若 Nginx 前有 SLB、Cloudflare 等，`$binary_remote_addr` 会变成代理 IP。务必配好 `set_real_ip_from` + `real_ip_header X-Forwarded-For`，再用 `$realip_remote_addr` 替代
- Vue/React 单页应用刷屏：`try_files $uri $uri/ /index.html` 会导致所有静态资源和 API 请求都落入同一 location，全部计入连接数。建议将 API 接口单独放在 `/api/` location 下限流，静态资源走无限制路径
结合系统指标看是否真起作用
光看 Nginx 返回不够，要确认底层连接是否被真正拦截：
- 用 `ss -s | grep "tcp:"` 或 `netstat -an | grep :80 | wc -l` 查看 ESTABLISHED 连接总数，应稳定在 `worker_connections × worker_processes` 以内，且不随压测并发线性上涨
- 检查 `nginx -T | grep limit_conn` 确认配置已加载，避免 reload 失败或语法错误导致配置未生效
- 若后端服务（如上游 PHP/Java）的活跃连接数也明显低于压测并发值，说明 limit_conn 成功在入口层截断了连接洪流
