如何应对因定时任务短时间并发调用大量外部CURL指令而导致的宿主机本地 ephemeral 端口枯竭问题

“Cannot assign requested address”源于短连接风暴、TIME_WAIT堆积与端口池过小；需同步减少新建连接（优先启用keep-alive或requests.Session）、加快端口回收（开启tcp_tw_reuse）、扩大端口范围（1024–65535）。

核心问题是：短连接风暴 + TIME_WAIT堆积 + 端口池太小 → “Cannot assign requested address”。这不是代码写错了，而是系统资源被高频 curl 耗尽。解决要从减少新建连接数、加快端口回收、扩大可用端口池三方面同步入手。

优先启用连接复用（最有效）

curl 默认每次请求都建新 TCP 连接，这是最大根源。必须强制复用：

• 在脚本中统一加 -H "Connection: keep-alive"，并用 --http1.1 显式指定协议（HTTP/2 默认复用，但部分服务端不兼容）
• 改用 curl --reuse（libcurl 7.62+ 支持），或更稳妥地：用 curl -K 配合配置文件批量复用同一 host 的连接
• 若调用量极大（如每秒百次以上），直接换长连接客户端：用 Python 的 requests.Session()、Go 的 http.Client（带 Transport 复用连接池），避免 shell curl 的进程开销和连接隔离

调大临时端口范围并启用快速复用

默认 32768–60999（约 28k 端口）完全扛不住高并发 curl：

• 临时扩到 1024 65535：执行 echo "1024 65535" > /proc/sys/net/ipv4/ip_local_port_range
• 永久生效：在 /etc/sysctl.conf 加一行 net.ipv4.ip_local_port_range = 1024 65535，再运行 sysctl -p
• 必须开启 net.ipv4.tcp_tw_reuse = 1（要求 net.ipv4.tcp_timestamps = 1，现代内核默认已开）——它允许内核在时间戳校验安全前提下，把 TIME_WAIT 端口立刻用于新连接（仅对客户端 connect 有效）

降低 TIME_WAIT 堆积压力

哪怕开了 reuse，大量短连接仍会短暂卡住端口。配合以下手段进一步缓解：

• 缩短 FIN 超时（非直接缩 TIME_WAIT，但能加速进入阶段）：net.ipv4.tcp_fin_timeout = 30
• 确认未启用 tcp_tw_recycle（已废弃且 NAT 下必出问题，Linux 4.12+ 内核移除，设为 0 更安全）
• 检查定时任务是否“堆叠触发”：比如 cron 每分钟跑一次，但上一轮没结束就启下一轮 → 用 flock 或临时锁文件串行化，避免连接数指数级增长

验证与监控（别等报错才查）

优化后要持续盯住关键指标：

• 实时看 TIME_WAIT 数：ss -ant state time-wait | wc -l，应明显低于端口上限（如扩到 64k 后，稳定在 5k 以内较健康）
• 确认端口范围：cat /proc/sys/net/ipv4/ip_local_port_range
• 抓一个典型 curl 进程，看其 fd 和连接：lsof -p $(pgrep -f "curl.*your-target") -iTCP，确认连接是否复用（源端口重复出现）
• 若用 Docker/K8s，注意宿主机参数生效，容器内无需单独调 —— ephemeral 端口由宿主机内核分配