端口资源耗尽本质是本地临时端口被短连接快速占满且复用不足，典型表现为bind: cannot assign requested address；需先通过sysctl查端口范围、ss统计time_wait数量并确认outbound连接方向，再优先扩大ip_local_port_range，辅以tcp_timestamps和tcp_tw_reuse调优，并在应用层启用keep-alive或连接池根治短连接风暴。
端口资源耗尽不是“连接太多”，而是本地临时端口被短连接快速占满又迟迟无法复用，典型现象是报错 bind: cannot assign requested address，同时 ss -tan state time-wait | wc -l 数值接近甚至超过 ip_local_port_range 的可用数量。
确认是不是真端口耗尽
别一看到 TIME_WAIT 多就改参数。先做三件事：
- 查当前端口范围：
sysctl net.ipv4.ip_local_port_range，比如输出32768 60999，说明可用端口约 28232 个 - 统计当前 TIME_WAIT 数量：
ss -tan state time-wait | wc -l，若数值 > 90% 可用端口数，基本可定性为端口瓶颈 - 看连接方向：用
lsof -i -n -P | grep "ESTABLISHED.*->"确认是否大量 outbound 连接——只有客户端侧才可能触发端口耗尽
优先调大端口供给池
这是最直接、最安全、效果最明显的一步，不依赖任何协议特性：
- 临时生效：
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535" - 永久生效：在
/etc/sysctl.conf中添加net.ipv4.ip_local_port_range = 1024 65535，再运行sysctl -p - 注意：部分旧应用对 1024–32767 端口有权限或 SELinux 限制，生产环境可设为
9000 65535平衡兼容性与容量
让 TIME_WAIT 端口更安全地复用
tcp_tw_reuse 不是开关一开就灵，它只在满足三个前提时起作用：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 必须开启时间戳：
net.ipv4.tcp_timestamps = 1（否则不生效） - 仅对客户端 outbound 连接有效（服务端监听不走这条路）
- 新连接的目标地址+端口必须和原 TIME_WAIT 连接不同（同后端不会复用）
启用后验证是否真正生效：netstat -s | grep -i "tw_reuse" 查看计数器是否递增，而不是只看 TIME_WAIT 数有没有降。
配合应用层减少短连接风暴
内核参数只能缓解，不能根治。真正压垮端口的是高频新建连接行为：
- HTTP 客户端加
Connection: keep-alive，服务端（如 Nginx）配keepalive_timeout 60 - 微服务调用、数据库访问务必使用连接池（如 HikariCP、urllib3 PoolManager），禁用每次请求新建 socket
- 避免在循环中频繁
curl或requests.get()，合并请求或引入异步批量机制
很多所谓“高并发”问题，其实只是几十行代码没关连接、没设超时、没复用，比调内核参数更值得花时间检查。
