排查limit_conn过严需三步：先查error日志确认503是否由limit_conn触发（需log level≥warn），再核对配置是否错配（zone大小、limit值、作用域层级），最后用stub_status观察waiting连接数并压测验证。
排查 limit_conn 限制过严导致正常用户被拒绝，核心是确认请求是否真因连接数超限被拦截，而非其他原因（如超时、后端故障或 limit_req）。重点看 Nginx 错误日志、配置逻辑和实时连接状态。
查错误日志确认是否真为 limit_conn 拒绝
Nginx 在触发 limit_conn 时，默认返回 503 状态码，并在 error log 中记录类似：
注意：
- 必须开启 error_log level 至少为 warn（推荐 error 或 crit），否则该日志不会输出；
- 检查日志中是否高频出现同一 zone 名（如 "addr" 或 "perip"）和大量不同客户端 IP 被限；
- 排除误判：503 也可能来自 upstream 不可用，需结合 upstream prematurely closed connection 等关键词交叉判断。
核对 limit_conn 配置是否与业务模型错配
常见误配场景：
-
zone 大小设置过小：例如
limit_conn_zone $binary_remote_addr zone=addr:10m，10MB 最多存约 16 万个 IP（按 64 字节/IP 估算），若业务有大量动态 IP（如运营商 NAT、企业出口网关），实际可跟踪的独立客户端远少于预期； -
limit_conn 值设得过低：比如
limit_conn addr 1表示每个 IP 只允许 1 个并发连接——现代浏览器默认开 6~8 个 TCP 连接加载页面，必然失败； -
作用域层级错误：在
http块设了limit_conn addr 5，又在location /api/里重复写limit_conn addr 2，后者会覆盖前者，但若没加limit_conn_status自定义状态码，难以区分是哪一级生效。
用 stub_status 实时观察连接分布
启用 ngx_http_stub_status_module（编译时默认包含），添加如下配置：
stub_status on;
allow 127.0.0.1;
deny all;
}
访问 http://your-domain/nginx-status 可看到：
server accepts handled requests
123456 123456 789012
Reading: 2 Writing: 12 Waiting: 229
关键看 Waiting 数值：它表示处于 keepalive 状态、未关闭的空闲连接。若 Waiting 持续接近 limit_conn 值，说明连接复用率高、资源被长期占住，而非瞬时并发突增。此时应调大 limit_conn 或缩短 keepalive_timeout。
临时绕过验证 + 分时段压测比对
快速验证是否为根本原因：
- 注释掉相关
limit_conn指令，reload Nginx，观察问题是否消失； - 用
ab或wrk模拟真实用户行为（带 Cookie、合理 headers、多连接）：先压测未限流环境，再恢复限流，对比 503 出现比例与并发请求数的关系； - 检查客户端是否异常：如移动端 App 长连接心跳未断开、前端轮询未退避、爬虫 User-Agent 伪装成浏览器却高频请求等。
