limit_conn在长连接场景下误拒请求的主因是连接状态识别错误或key设计不合理，需检查key稳定性、真实客户端ip获取、keepalive超时设置及upstream异常悬挂。
排查 limit_conn 在长连接场景下统计未及时释放的问题，核心是确认 Nginx 是否错误地将已关闭或空闲的连接仍计入连接数限制，导致新请求被误拒（返回 503）。关键不在“连接是否真长”，而在于“连接状态是否被正确识别和清理”。
确认 limit_conn 的作用域和 key 定义是否合理
limit_conn 统计的是当前活跃连接数，但它的 key 决定了“谁和谁”被归为一组。常见误区是用不稳定的 key（如 $binary_remote_addr）在代理或 NAT 环境下把多个用户压进同一桶，或用 $server_name 导致不同域名共享连接池。
- 检查配置中
limit_conn_zone的 key：若后端有 LVS、云负载均衡或 CDN，$remote_addr 可能是中间节点 IP，应改用真实客户端 IP（需配合real_ip指令和set_real_ip_from） - 避免用动态变量（如 $request_uri 或带参数的 $args）作 key，这会导致连接无法复用且统计碎片化
- 对长连接（如 WebSocket、HTTP/2 流），确保 key 能稳定标识“同一个客户端会话”，例如结合 $binary_remote_addr + $http_user_agent（谨慎使用）或业务 token（需前置提取到变量）
验证连接是否真正关闭，还是处于 keepalive 空闲状态
Nginx 默认保持 keepalive 连接（keepalive_timeout 控制），这些连接在超时前仍计入 limit_conn 统计——这是正常行为，但容易被误判为“泄漏”。需区分“连接未关”和“连接卡住”。
- 用
ss -tnp | grep :<port></port>或netstat -anp | grep :<port></port>查看 ESTABLISHED 和 TIME_WAIT 连接数，对比limit_conn配置值 - 开启
stub_status模块（location /nginx_status { stub_status; allow 127.0.0.1; deny all; }），访问后观察Active connections和Reading/Writing/Waiting状态。Waiting 状态高通常表示 keepalive 空闲连接多，而非故障 - 调低
keepalive_timeout（如设为 15s）并观察 503 是否减少；若明显改善，说明是 keepalive 积压而非连接泄漏
检查 upstream 或后端异常导致连接悬挂
当 Nginx 作为反向代理时，若 upstream 服务崩溃、响应缓慢或半关闭连接（如只 FIN 不 ACK），Nginx 可能无法及时感知连接终结，导致该连接长期滞留在连接池中并持续占用 limit_conn 配额。
- 启用
proxy_next_upstream error timeout http_500;并设置合理的proxy_timeout参数（proxy_read_timeout,proxy_send_timeout），防止等待死连接 - 添加
proxy_buffering off;（仅调试时）可暴露后端流式响应问题；但生产环境慎用 - 用
error_log ... debug;开启 debug 日志（需重新编译含 --with-debug），过滤关键字 “limit_conn”, “keepalive”, “upstream” 定位连接释放时机
利用 nginx-module-vts 或自定义日志定位具体触发者
原生 Nginx 不直接暴露每个 key 当前连接数，需借助扩展或日志推断。
- 部署 nginx-module-vts，访问
/status/format/json可查各 limit_conn_zone 的实时连接数分布 - 在
log_format中加入$limit变量（需 patch 或用 vts 模块支持），记录每次请求对应的连接限制状态 - 对频繁 503 的 IP，用
limit_conn_status 503;配合 access_log 记录，并用 awk 统计单位时间内 hit limit 的次数与 IP 分布
