Nginx 中怎么排查连接数限制模块在代理转发中统计偏高故障-Nginx-PHP中文网

连接数统计偏高通常源于Nginx对“连接”的判定与业务预期不一致，尤其在代理转发、HTTP/2多路复用或upstream长连接场景下，$binary_remote_addr等key导致单连接反复计入，或idle连接、缓冲阻塞、reuseport统计口径差异被误计为活跃连接。

nginx 中怎么排查连接数限制模块在代理转发中统计偏高故障

连接数统计偏高，通常不是真实并发连接过多，而是 Nginx 模块（如 ngx_http_limit_conn_module 或自定义计数逻辑）对“连接”的判定与业务预期不一致，尤其在代理转发场景下容易误统计。排查重点不在“有多少连接”，而在“哪些连接被计入、为何重复或滞留”。

确认 limit_conn 的作用域和键值是否合理

limit_conn 统计依赖 limit_conn_zone 定义的键（key）。代理场景中常见错误是用 $binary_remote_addr 作为 key，但后端服务启用了长连接复用（如 HTTP/1.1 keepalive 或 HTTP/2），同一个客户端 IP 可能持续复用少数几个 TCP 连接发起大量请求，导致单个连接被反复计入（尤其配合不当的 limit_conn 放置位置）。

检查 zone 定义：确认 key 是否包含能区分请求粒度的变量，例如 $server_name:$binary_remote_addr 或更精细的 $http_x_forwarded_for（需确保可信）
避免在 location 块中重复声明 limit_conn，否则可能因多匹配触发多次计数
用 log_format 加入 $limit 和 $limit_key 变量，记录实际生效的 key 值和限流状态，验证是否 key 冲突或重复命中

检查 upstream 长连接配置与连接复用行为

代理转发中，Nginx 与上游服务器之间的连接复用（keepalive）本身不直接影响 limit_conn，但如果 upstream 配置了 keepalive 32 且未设 keepalive_requests 或 keepalive_timeout，可能导致 Nginx worker 进程长期持有空闲 upstream 连接，而这些连接在某些自定义模块或监控脚本中被错误纳入“活跃连接”统计（比如通过 stub_status 的 Active connections 是 TCP 连接总数，含 idle 状态）。

确认 upstream 块中设置了合理的 keepalive_requests（如 100）和 keepalive_timeout（如 60s）
用 ss -tnp | grep :your_upstream_port 观察 ESTABLISHED 连接的实际数量和生命周期，对比 nginx -T | grep limit_conn 配置，判断是否 upstream 连接被误读为客户端连接
若使用第三方连接统计模块（如 nginx-module-vts），查阅其文档确认“connection”指标是否包含 upstream idle 连接

排查 proxy_buffering 和请求体读取导致的连接滞留

当 proxy_buffering off 或客户端发送大 body（如文件上传）且未及时读取时，Nginx 会保持客户端连接等待后端响应或缓冲区释放，此时连接处于 “reading request header” 或 “reading request body” 状态，仍被计入活跃连接，但并非有效业务连接。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

启用 error_log debug;（临时），搜索 "client timed out" "upstream sent too big header" "client closed prematurely" 类日志，定位是否因读写阻塞导致连接卡住
检查 client_header_timeout、client_body_timeout、proxy_read_timeout 是否过长（如设为 300s），导致异常连接长期不释放
对上传接口单独配置更短的超时和独立的 limit_conn zone，避免影响其他路径

验证是否受 reuseport 或多 worker 影响统计口径

启用 listen ... reuseport 时，每个 worker 进程独立监听端口，limit_conn 的 zone 是 worker 级别共享的（默认），但部分旧版本或特殊编译模块可能存在 zone 同步延迟；同时，stub_status 显示的是当前 worker 的连接数，若用脚本聚合所有 worker 数据却未去重，也会虚高。

运行 ps -ef | grep nginx 查看 worker 数量，再分别请求每个 worker 的 /basic_status（需绑定不同端口或用 worker_connections 分离）比对数值
升级到 Nginx 1.19.10+，确保 reuseport 与 limit_conn 兼容性
避免直接用 netstat -an | grep :80 | wc -l 代替 stub_status，前者包含 TIME_WAIT、CLOSE_WAIT 等非活跃状态

不复杂但容易忽略：统计偏高往往源于“连接定义”和“业务模型”错位，而不是模块坏了。先厘清你要限的是“客户端 IP 并发请求数”，还是“到上游的连接数”，或是“当前处理中的事务数”，再选对模块和 key，比调参数更重要。