核心是盯住“连接生命周期错位”——客户端、nginx、后端对“空闲”和“该断”的判断不一致，导致连接滞留、端口占满；需通过ss统计estab/time-wait分布、验证upstream keepalive配置与响应头、比对三类proxy超时参数，并协同后端调整资源回收节奏。

核心是盯住“连接生命周期错位”——不是连接没释放，而是客户端、Nginx、后端三者对“空闲”和“该断”的判断不一致，导致连接长期滞留、端口被占满。

查当前连接状态分布

先确认是否真存在连接堆积，而不是误判：

• 在 Nginx 服务器上运行：ss -tn state established | wc -l，看 ESTABLISHED 连接总数是否接近本地端口上限（默认约 28000）
• 按后端分组统计：ss -tn state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr，识别是否某台后端连接数远高于其他节点
• 检查 TIME_WAIT 是否异常高：ss -tn state time-wait | wc -l；若持续 > 30000，说明短连接频繁新建，keepalive 可能未生效

验 upstream keepalive 是否真正启用

配置写了不等于生效，必须逐层验证：

Nginx Hosting

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

下载

• 确认 upstream 块中明确写了 keepalive 32（数值建议 16–64），且没有被 include 覆盖或注释掉
• 对应 location 中必须有：proxy_http_version 1.1; 和 proxy_set_header Connection "";，缺一不可
• 用 curl -I http://your-domain/ 查响应头，确认返回中不含 Connection: close；若出现，说明后端主动断连，Nginx 无法复用

核对三类超时参数是否匹配后端行为

超时设错是连接卡死的主因，重点比对：

• proxy_read_timeout 必须略大于后端心跳间隔（如后端每 30 秒 ping 一次，此值应设 60–90 秒）；WebSocket 场景可设 86400，但前提是后端 keepAliveTimeout ≥ 86400
• proxy_connect_timeout 控制建连，建议 1–3 秒；过长会让失败连接阻塞 worker
• proxy_send_timeout 设为 10–20 秒，避免大请求上传时误断；若后端接收慢，可单独调高，但不要全局拉长

协同后端服务确认资源回收节奏

Nginx 无法单方面决定连接何时释放，必须与后端对齐：

• Tomcat 需设置 connectionTimeout > Nginx 的 proxy_read_timeout，否则服务先断，Nginx 还在发数据，触发 reset 或 502
• Kubernetes 环境下，检查 Pod 的 terminationGracePeriodSeconds 是否 ≥ 30 秒，并配 preStop hook（如 sleep 30），给 Nginx 留出自然释放活跃连接的时间
• 在后端日志中搜索 “close idle connection” 或类似关键词，确认其实际关闭行为是否与配置一致