网络延迟排查怎么利用 netstat 或 ss 命令统计并诊断处于 TIME

time_wait本身不直接导致网络延迟，但大量time_wait常反映短连接高频关闭问题，会放大握手开销并间接引发卡顿；异常堆积时可能造成端口耗尽、文件描述符挤占或内核哈希表溢出，进而导致连接失败、超时及502/504错误。

网络延迟排查怎么利用 netstat 或 ss 命令统计并诊断处于 time_wait 的连接

网络延迟本身不直接由 TIME_WAIT 引起，但大量 TIME_WAIT 连接常是短连接高频关闭的副产品——而短连接模式（如 HTTP/1.0、未启用 keepalive 的 upstream 调用）会显著放大握手开销和首包延迟，间接导致用户感知的“卡顿”或“响应慢”。更关键的是，当 TIME_WAIT 异常堆积时，可能触发端口耗尽、文件描述符挤占甚至内核哈希表溢出，这些才会真正引发连接失败、超时或 502/504 错误。

确认 TIME_WAIT 是否已异常堆积

别只看总数。重点观察三个信号：

数量是否逼近可用端口上限：运行 cat /proc/sys/net/ipv4/ip_local_port_range 查端口范围（如 32768 65535，共约 32768 个），再执行 ss -tan state time-wait | wc -l。若结果 > 2.5 万且持续存在，端口耗尽风险极高
是否远超活跃连接：对比 ss -tan state established | wc -l。若 TIME_WAIT 是 ESTABLISHED 的 4 倍以上并维持 5 分钟，说明连接释放节奏严重失衡
是否伴随系统告警：执行 dmesg | grep -i "tw\|time wait"，出现 time wait bucket table overflow 即表示内核已无法安全维护该状态，必须干预

定位 TIME_WAIT 集中来源（客户端 or 上游）

TIME_WAIT 出现在哪一端，取决于谁主动发起关闭。Nginx 作为反向代理，既可能是客户端（连 upstream），也可能是服务端（被 client 连）。需分场景查：

查 Nginx 被谁大量短连（即 client 主动关）：
ss -tan state time-wait '( dport = :80 or dport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -5
输出类似 12456 192.168.10.22，说明该 IP 频繁建立又快速断开 HTTP 连接
查 Nginx 主动连谁产生大量 TIME_WAIT（即 Nginx 主动关 upstream）：
ss -tan state time-wait '( sport = :80 or sport = :443 )' | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -5
注意这里是 sport（源端口），输出如 8920 10.20.30.40，指向后端服务 IP，说明 Nginx 与该 upstream 未启用 keepalive 或健康检查太激进

关联业务表现做交叉验证

单纯数字无意义，要结合日志和监控判断是否真影响延迟：

查 Nginx error log 是否有 connect() failed (99: Cannot assign requested address) 或 upstream timed out —— 这是端口耗尽或上游响应慢的直接证据
对比 nginx stub_status 中的 Active connections 和 ss -tan state established | wc -l：若前者远小于后者，说明请求卡在读取 request body 阶段（如大文件上传未完成），而非连接层问题；若两者接近但响应慢，则更可能是后端处理延迟
检查 netstat -s | grep -i "tcp:" 中的 connections rejected because of time stamp 或 retransmits，高重传率才指向真实网络延迟，而非 TIME_WAIT 本身