stub_status不能清理连接，但能通过waiting值长期高位且与active高度耦合、reading/writing≈0、requests停滞等特征识别keepalive_timeout过长导致的死连接；需调低超时值并配合系统级手段清理。
stub_status 本身不提供连接清理能力，但能清晰暴露 keepalive_timeout 过长引发的死连接特征——关键看 Waiting 值是否持续高位、且与 Active connections 高度耦合。识别后需结合 Nginx 配置调整与系统级手段主动干预。
从 stub_status 输出识别死连接迹象
高频访问 /nginx-status（建议每 5–10 秒一次），持续观察以下组合信号：
- Waiting 数值长期稳定在高位（如 >80% 的 Active connections），且波动极小（例如连续 5 分钟：Active=210，Waiting=207～209）
- Reading 和 Writing 始终接近 0，Requests 增长缓慢甚至停滞
- accepts 与 handled 差值很小，但 requests 增速远低于历史均值（说明新请求极少，连接几乎全在空闲等待）
- 对比 netstat：执行
netstat -an | grep :80 | grep ESTABLISHED | wc -l，若结果与 Active connections 高度一致，而其中大量连接的 Recv-Q 长期非零（ss -tni | grep 'state ESTAB' | awk '{print $2,$3}'），即为典型客户端未发 FIN 的“假活跃”连接
确认 keepalive_timeout 是主因
检查当前配置：
- 执行
nginx -T 2>/dev/null | grep -E 'keepalive_timeout|worker_connections' - 若 keepalive_timeout ≥ 60s（尤其 ≥ 300s），且站点无长轮询/Server-Sent Events 等真实长连接需求，就极可能是根源
- 注意：多个 server 块可能有不同设置，以实际匹配请求的 server 块为准；若使用了
upstream，还需确认 backend 是否也保持长连接，形成双向空闲链路
安全清理与长效防控措施
不能依赖 stub_status 清理连接，必须分步处置：
-
立即降低超时值：将 keepalive_timeout 调至 15–30s（如
keepalive_timeout 20s;），并重载 Nginx（nginx -s reload）。新连接将按新策略断开，已存在的死连接会在下次心跳或超时后自然释放 -
强制清理存量死连接：对已确认的异常连接，可用
ss -tnop state established '( sport = :80 or dport = :80 )' | awk '{print $7}' | grep -o 'inode:[0-9]*' | xargs -I{} sh -c 'echo {} > /proc/sys/net/ipv4/netfilter/ip_conntrack_flush 2>/dev/null || true'（慎用）；更稳妥方式是重启 worker 进程：kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid)+kill -WINCH $(cat /usr/local/nginx/logs/nginx.pid.oldbin) -
添加连接数硬限制：在 http 或 server 块中加入
limit_conn addr 100;（配合limit_conn_zone $binary_remote_addr zone=addr:10m;），防止单 IP 持有过多空闲连接耗尽 worker_connections -
监控告警绑定 Waiting 比率：定义告警规则，如
(Waiting / Active connections) > 0.85 for 3 minutes，而非只盯绝对数值
Waiting 高不是故障，而是配置与业务不匹配的明确提示。stub_status 让它可见，后续动作才决定能否真正释放资源。
