轮询模式下TCP连接数暴增主因是长连接未回收、后端响应滞后或keepalive配置失控；需通过upstream_addr分布、ss连接统计、keepalive_timeout与keepalive N参数、后端健康检查及系统连接上限等多维度排查。
轮询模式下 TCP 连接数暴增，往往不是“轮询本身出错”，而是长连接未被合理回收、后端响应滞后或连接复用失控导致的表象。关键要区分：是真实并发上涨？还是连接堆积滞留？
看连接是否真在“轮询分发”
轮询（round-robin）只按请求顺序转发，不感知后端负载。若某节点处理慢或卡住，它的连接会越积越多，而轮询仍持续打过去——表面是轮询，实际已失衡。
- 启用日志记录上游地址：log_format main '$remote_addr - $upstream_addr $upstream_response_time $request_time';，观察同一客户端或相似请求是否反复落到同一台后端
- 检查 $upstream_addr 字段是否均匀分布；若某 IP 出现频次远高于其他，说明该节点承接了过多长连接，轮询未起作用
- 对比各后端的 ss -tn state established | grep :端口 | wc -l，确认连接数是否严重倾斜（如 1200 vs 80）
查 keepalive 是否失控复用
HTTP 层的 keepalive 和 upstream 的 keepalive 若配置不当，会让 Nginx 持有大量空闲连接却不释放，尤其在长轮询、WebSocket 等场景下极易暴增。
- 确认 keepalive_timeout 是否设得过高（如 75s），建议压至 30–45s，略大于业务最长等待即可
- 检查 upstream keepalive N（如 keepalive 32）是否过大，且是否配套使用了 proxy_http_version 1.1 和 proxy_set_header Connection ""
- 若缺失后者，后端返回 Connection: close 会导致 Nginx 不敢复用连接，被迫频繁新建——反而加剧 TIME_WAIT 和端口耗尽
验后端响应是否拖慢连接释放
连接数暴增常是结果，根源常在后端：响应延迟高、线程阻塞、连接池满、accept 队列溢出等，都会让连接卡在 ESTABLISHED 状态不关闭。
- 用 curl -o /dev/null -s -w '%{http_code} %{time_total}\n' http://后端IP:端口/health 测单点健康接口耗时，超 1s 就需警惕
- 在后端机器执行 ss -lnt | grep :端口，看 Recv-Q 是否持续 > 0（表示 accept 队列堆积）
- 查后端应用日志是否有线程池满、DB 连接超时、GC 长暂停等线索
核对系统与 Nginx 连接上限是否被挤占
连接暴增若逼近硬限制，会触发拒绝服务，但错误日志可能被掩盖。
- 运行 nginx -T 2>/dev/null | grep -E 'worker_processes|worker_connections'，算出理论最大连接数
- 执行 cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"，确保系统级 limit ≥ 理论值
- 搜索 error.log 中 "accept() failed (24: Too many open files)" 或 "connect() failed (11: Resource temporarily unavailable)"
