端口耗尽导致“Cannot assign requested address”或偶发“Connection refused”，本质是本机临时端口（ephemeral ports）用尽，而非服务未监听；需通过sysctl net.ipv4.ip_local_port_range查端口范围，用ss -tan state time-wait | wc -l比对TIME_WAIT数量是否接近上限，并结合ss -s确认timewait占主导，再用lsof或ss -tanp定位高连接进程。
端口耗尽导致“Connection refused”或“Cannot assign requested address”，本质不是服务没监听，而是本机连出去的临时端口用光了——系统想建新连接，却找不到可用本地端口。排查要绕开“服务是否在听”的惯性思维，直击客户端侧资源瓶颈。
确认是不是端口耗尽
先看系统允许哪些端口当临时端口：
sysctl net.ipv4.ip_local_port_range
典型输出如 32768 60999，说明可用端口约 28232 个。再统计当前 TIME-WAIT 连接数：
ss -tan state time-wait | wc -l
如果这个数字接近甚至超过端口总数（比如 >25000），且应用还在高频发起新连接，基本可判定端口即将或已经耗尽。再补查一句：
ss -s | grep -i "used"
关注 “TCP: xxx (estab) yyy (orphan) zzz (timewait)” 中 timewait 是否占绝对大头。
区分端口耗尽和其他拒绝原因
“Connection refused”常被误判为服务未监听，但端口耗尽时也会出现类似报错（尤其在容器或代理场景）。关键区别在于：
- 服务端监听正常（ss -tuln | grep :端口 可见 LISTEN）
- 本地 curl 127.0.0.1:端口 成功，但从客户端访问失败
- 错误日志里出现 “Cannot assign requested address”（不是 “Connection refused”）——这是端口耗尽的标志性提示
- 问题集中在出站连接密集的服务（如网关、爬虫、微服务调用方），而非被访问的服务本身
快速定位高连接进程
找出谁在猛开短连接：
ss -tan | awk '{print }' | cut -d: -f1 | sort | uniq -c | sort -nr | head -5
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
看哪些目标 IP 出现最多；再结合 PID 查具体进程：
ss -tanp | grep ':目标端口' | grep -v 'users:'
或直接按进程查连接数：
lsof -iTCP -sTCP:ESTABLISHED | awk '{print $2}' | sort | uniq -c | sort -nr | head -5
若某个 PID 占据数千连接，就是重点怀疑对象。
临时缓解与长期优化
临时扩大端口范围（立即生效）：
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
永久生效需写入 /etc/sysctl.conf 并运行 sudo sysctl -p。
更治本的做法是减少短连接风暴：
- 客户端启用连接复用（HTTP Keep-Alive、数据库连接池、gRPC channel 复用）
- 避免在循环中 new HttpClient / new Socket
- 检查是否有 DNS 轮询或重试逻辑引发连接爆炸
- TIME-WAIT 本身不可怕，但大量短连接+低频复用会让它堆积成瓶颈
不复杂但容易忽略
