排查定时任务引发的TIME_WAIT饱和，核心是确认“短连接风暴”是否真实压垮本地端口资源——需先通过ss -s和ip_local_port_range验证端口是否耗尽，再按进程、目标地址及cron日志定位触发源，接着检查HTTP或数据库连接是否未复用，最后通过启用tcp_tw_reuse和改造连接池实现应急与长效双轨解决。
排查定时任务引发的 TIME_WAIT 饱和，核心是确认“短连接风暴”是否真实压垮了本地端口资源——不是看 TIME_WAIT 数量大，而是看它是否已挤占可用端口、阻塞新连接。
第一步：快速验证是否真为端口耗尽
别被 netstat -ant | grep TIME_WAIT | wc -l 的数字吓到。直接执行：
-
ss -s：重点看输出中
time-wait后的数字（如time-wait 18234），再对比sockets: used和memory: used是否接近 limit； -
cat /proc/sys/net/ipv4/ip_local_port_range：得到类似
32768 65535，说明最多约 32768 个临时端口； - 若 ss -s 中 time-wait 接近或超过该数值，且业务出现
Cannot assign requested address报错，即可锁定为端口耗尽。
第二步：定位触发源——精准抓出那个定时任务
定时任务往往由 cron、systemd timer 或应用内 scheduler 触发，需从连接源头反推：
-
按进程查连接：用
ss -tanp | grep TIME_WAIT（需 root），看哪些 PID 占用大量TIME_WAIT；再用ps -p PID -o pid,ppid,comm,args查其父进程与启动命令； -
按目标地址筛连接：如果任务固定访问某后端（如
:8080或数据库:3306），运行ss -tan state time-wait dst :8080 | wc -l统计数量，确认是否集中爆发； -
查 cron 日志：
grep CRON /var/log/syslog（Ubuntu）或/var/log/cron（CentOS），结合报错时间点，找出刚执行过的高频任务。
第三步：检查连接行为是否真的“短”且“未复用”
很多定时任务看似调 API，实则每次新建 HTTP 连接、不带 Keep-Alive，或数据库每次查询都 new connection：
-
HTTP 类任务：检查脚本是否用了
curl -H "Connection: keep-alive"或 Python 的requests.Session()；用tcpdump -i lo port 8080 -c 20 -w task.pcap抓包后，用tshark -r task.pcap -Y "tcp.flags.fin==1" | wc -l看 FIN 包密度——高密度即短连接； -
数据库类任务：检查代码是否每次执行都
sql.Open+db.Query+rows.Close，而没设SetMaxIdleConns和SetMaxOpenConns；Go 场景下尤其注意是否漏掉db.SetConnMaxLifetime导致连接池僵化； -
Go 客户端必须加 SO_REUSEADDR：Linux 下标准库默认不启用，需自定义
net.Dialer并在Control回调中调用SetsockoptInt32(fd, SOL_SOCKET, SO_REUSEADDR, 1)，否则即使内核开了tcp_tw_reuse也无效。
第四步：应急+长效双轨处理
短期止血，长期根治：
-
应急（立刻生效）：
sysctl -w net.ipv4.tcp_tw_reuse=1（确保net.ipv4.tcp_timestamps=1已开）、sysctl -w net.ipv4.ip_local_port_range="1024 65535"； -
长效（改代码）：把定时任务中的短连接全部改为长连接或连接池——HTTP 改用
http.Client复用 Transport，数据库统一走连接池并合理配置 idle/max lifetime； -
规避风险项：绝对不要启用
tcp_tw_recycle（已废弃，在 NAT/云环境必出问题）；也不要用SO_LINGER=0强制跳过 TIME_WAIT（会中断响应、丢数据）。
