端口检查需对比TIME_WAIT数量与临时端口总数并结合错误日志判断：执行ss -ant state time-wait | wc -l和cat /proc/sys/net/ipv4/ip_local_port_range获取数据，若TIME_WAIT持续接近或超过端口范围差值（如25000+），且日志出现“cannot assign requested address”或dmesg提示“time wait bucket table overflow”，则确认端口耗尽；再通过lsof、ss定位主动断连方，结合ESTAB与TIME_WAIT数量悬殊可判定短连接风暴。
端口检查不是只看“有多少TIME_WAIT”，而是要判断这些连接是否正在挤压可用端口资源。核心是对比“当前TIME_WAIT数量”和“系统允许的临时端口总数”，再结合错误日志和连接行为综合判断。
查当前TIME_WAIT数量和端口范围
执行两条命令，一步到位：
- ss -ant state time-wait | wc -l：统计当前所有TIME_WAIT连接数
- cat /proc/sys/net/ipv4/ip_local_port_range：查看本地临时端口起止范围（如 32768 60999，即约28232个可用端口）
如果前者持续接近或超过后者差值（比如 TIME_WAIT 达到 25000+），说明端口池已高度紧张，新连接大概率失败。
确认是否真出现端口耗尽现象
光有大量 TIME_WAIT 不代表出问题，得看有没有实际影响：
- 查应用日志是否有 connect: cannot assign requested address 或 Address already in use
- 用 ss -s 看全局摘要，重点关注 timewait 和 orphaned 数量是否远超 established
- 运行 dmesg | grep "time wait bucket"，若输出 TCP: time wait bucket table overflow，说明内核已开始丢弃连接，必须立即处理
定位谁在高频主动断连
TIME_WAIT 是主动关闭方产生的，所以要搞清是服务端还是客户端在狂发 FIN：
- 如果是本机作为客户端（比如调用外部 API、健康探测脚本），用 lsof -iTCP -n -P | grep ESTABLISHED 查看 outbound 连接目标；再结合 ss -tan state time-wait src $(hostname -I | awk '{print $1}') | wc -l 看本机发起的 TIME_WAIT 是否占主导
- 如果是本机作为服务端（如 Nginx、Java Web 服务），检查是否配置了短连接：Nginx 中 keepalive_timeout 0 或未启用 proxy_http_version 1.1 都会导致服务端主动断连
辅助验证：看连接是否真的“短”
短连接是 TIME_WAIT 堆积的温床。可粗略估算：
- 假设每秒新建 1000 个连接，每个连接由本机主动关闭 → 60 秒后理论 TIME_WAIT ≈ 60000
- 用 ss -tan state established | wc -l 查当前活跃连接数，若远小于 TIME_WAIT 数（比如 ESTAB=200，TIME_WAIT=45000），基本可判定是短连接风暴
