服务报 Cannot assign requested address:一次 Linux TIME_WAIT 端口耗尽排查复盘

2024 年,一个服务在业务高峰期开始报一个我没怎么见过的错:Cannot assign requested address——无法分配请求的地址。这服务要做的事很简单,就是不停地去调一个下游 HTTP 接口。我第一反应是下游挂了,或者网络不通,可下游好好的,网络也通。我又以为是 IP 配错了——"分配地址"嘛,听着就像 IP 的事——可配置里的地址明明白白,一个字没错。我登上服务器 ss 了一下,想看看连接情况,结果被屏幕上的数字惊到了:TIME_WAIT 状态的连接,有两万八千多条。我心里立刻有了判断:这肯定是连接泄漏了,这两万八千条 TIME_WAIT 全是没关干净的"僵尸连接",把系统拖垮了——我得想办法把它们清掉。可我查了半天,发现根本没有什么命令能"杀掉"一个 TIME_WAIT 连接,它们就那么明晃晃地堆在那儿,我对它们无能为力。我盯着这两万八千条 TIME_WAIT 想了很久,最后才反应过来,我从一开始就把它们当成了"故障",可它们根本不是——TIME_WAIT 不是连接出了错,恰恰相反,它是连接正常关闭后,本该经历的一个状态。这件事逼着我把 TCP 的 TIME_WAIT、本地端口耗尽、连接复用这一整套彻底理清了。本文复盘这次实战。

问题背景

环境:CentOS 7,一个服务,高频调用一个下游 HTTP 接口
事故现象:
- 业务高峰期,服务报 Cannot assign requested address
- 报错时新的下游调用全部失败
- ★ 下游服务正常、网络正常、配置里的地址也没错

现场排查:
# 1. 看连接状态统计 —— TIME_WAIT 堆成山
$ ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
  28300 TIME-WAIT                             # ★ 两万八千多!
   1200 ESTAB
     ...

# 2. ★ 看本地端口可用范围
$ cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999                                 # ★ 可用端口约 2.8 万个

# 3. ★ 看这些 TIME_WAIT 连的是谁
$ ss -ant state time-wait | awk '{print $5}' | sort | uniq -c | sort -rn
  28100 10.0.0.50:8080                        # ★ 几乎全连同一个下游

# 4. 看是谁在狂建连接
$ ss -antp state time-wait | grep -o 'pid=[0-9]*' | sort | uniq -c
  28000 pid=9400                              # ★ 都是进程 9400 建的

根因(后来想清楚的):
1. ★ Cannot assign requested address 耗尽的【不是 IP】,
   是【本地端口】。每发起一条对外连接,系统都要从
   "本地端口范围"里【借一个端口】当源端口。
2. 这个范围(ip_local_port_range)默认约 2.8 万个端口。
3. ★ TIME_WAIT 不是故障、不是泄漏。它是 TCP 连接被
   【主动关闭方】关闭后,必经的一个状态 —— 这一方会
   在 TIME_WAIT 里停留 2*MSL(Linux 默认约 60 秒)。
4. ★ 一条连接停在 TIME_WAIT 期间,它占的那个本地端口
   【还没还回去】—— 60 秒内不能给新连接用。
5. 我这个服务用的是【短连接】:每次调下游都新建一条
   连接、用完就关。高峰期每秒建几百上千条,60 秒内
   就建了远超 2.8 万条 —— ★ 全部端口都卡在 TIME_WAIT,
   一个空闲端口都借不到。
6. 借不到本地端口 -> 新连接建不了 -> Cannot assign
   requested address。
TIME_WAIT 堆积不是 bug,是短连接太多 + 端口被占住没还。

修复 1:Cannot assign requested address——耗尽的是本地端口

# === ★ 先纠正最核心的误解:这报错和 IP 无关 ===

# === "assign address" 字面又骗了人 ===
# 看到 Cannot assign requested address,直觉是
#   "IP 地址有问题" —— 配错了、冲突了、网卡没 IP。
# ★ 错。这里 "address" 指的是一个【完整的 TCP 端点】,
#   而真正不够用、分配不出来的,是其中的【本地端口】。

# === ★ 每发起一条对外连接,都要"借"一个本地端口 ===
# 一条 TCP 连接,由【四元组】唯一确定:
#   源IP : 源端口  <->  目的IP : 目的端口
# 你的服务去连下游 10.0.0.50:8080:
#  - 目的 IP、目的端口:固定,就是下游那个
#  - 源 IP:本机 IP,固定
#  - ★ 源端口:每条连接都要【现借一个】,不能重复
# 这个"现借的源端口",就是【临时端口/本地端口】。

# === 本地端口从哪个范围里借 ===
$ cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999
# ★ 系统发起连接时,源端口就从这个范围里挑一个没被
#   占用的。32768~60999,大约 2.8 万个 —— 就这么多。

# === ★ 于是报错就说得通了 ===
# 如果这 2.8 万个本地端口【全被占着】,系统再想发起
#   新连接,就借不到源端口了 ->
#   ★ Cannot assign requested address。
# 它不是 IP 出错,是"本地端口这个资源,用光了"。

# === 看本地端口到底用掉多少 ===
$ ss -ant | wc -l                          # 当前连接总数
$ ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
  28300 TIME-WAIT                            # ★ 大头是 TIME_WAIT
   1200 ESTAB
# ★ 注意:不只 ESTAB(已建立)占端口,
#   TIME-WAIT 状态的连接,★【照样占着】本地端口(见修复 2)。

# === 区分:这是连"同一个下游"还是"很多下游" ===
$ ss -ant state time-wait | awk '{print $5}' | cut -d: -f1 \
    | sort | uniq -c | sort -rn
# ★ 如果几乎全连【同一个目的地】,端口耗尽会来得特别快
#   (后面会讲:连不同目的地时四元组更宽松)。

修复 2:TIME_WAIT 是什么——它不是 bug,是正常且必要的状态

# === ★ 重点:TIME_WAIT 不是故障,是 TCP 设计的一部分 ===

# === TIME_WAIT 出现在"主动关闭方"身上 ===
# 一条 TCP 连接关闭时,有一方先发起关闭(主动关闭方),
#   另一方被动跟着关(被动关闭方)。
# ★ TCP 四次挥手结束后,【主动关闭方】不会立刻消失,
#   它会进入一个叫 TIME_WAIT 的状态,停留一段时间。

# === ★ 为什么非要有 TIME_WAIT —— 它解决两个问题 ===
# 问题 1:确保最后一个 ACK 能送达。
#   主动关闭方发的最后那个 ACK 万一丢了,对端会重发
#   FIN,这一方还得能再回一次 ACK —— 所以它得【多待
#   一会儿】,不能马上走人。
# 问题 2:★ 防止"上一条连接的迷路旧包"污染新连接。
#   网络里可能有上条连接的延迟数据包还在游荡。如果
#   立刻用【相同的四元组】建一条新连接,旧包飘过来
#   就会被新连接错收。TIME_WAIT 等的这段时间,就是
#   让这些旧包在网络里【自然过期消失】。

# === TIME_WAIT 待多久 ===
# 它停留的时间是 2*MSL(MSL = 报文最大生存时间)。
# ★ Linux 上这个值固定约 60 秒,而且【改不了】
#   (它是写死的,不像别的参数能调)。
$ ss -ant state time-wait | head -3
# 每条 TIME-WAIT 连接,都会在 60 秒后自己消失。

# === ★ 关键认知:TIME_WAIT 多,不是"坏" ===
# 大量 TIME_WAIT 出现,本身只说明一件事:
#   ★ 这台机器【主动关闭了很多连接】。
# 这通常恰恰是连接被【规规矩矩地关闭】的证据 ——
#   它和"连接泄漏"是完全相反的两回事。
# 真正的连接泄漏,表现是 ESTAB 或 CLOSE-WAIT 只涨不跌,
#   ★ 不是 TIME_WAIT。

# === ★ 所以别想着"清掉"TIME_WAIT ===
# 没有命令能安全地"杀掉"一个 TIME_WAIT 连接 ——
#   它就是要待满 60 秒,这是协议要求。
# 问题的解法不是消灭 TIME_WAIT,而是【别产生那么多】
#   (见修复 5)。

# === 真正的麻烦:TIME_WAIT 期间端口不还 ===
# ★ 一条连接在 TIME_WAIT 的这 60 秒里,它占用的那个
#   本地端口,【不会被释放】。
# 单条连接,这没问题;但短时间内产生【几万条】
#   TIME_WAIT,2.8 万个本地端口就被占满了 —— 这才是
#   它和"端口耗尽"挂上钩的原因。

修复 3:为什么 TIME_WAIT 会堆到几万——短连接的代价

# === ★ 把"为什么会堆几万条 TIME_WAIT"讲透 ===

# === 短连接 vs 长连接 ===
# 短连接:每次请求都【新建一条 TCP 连接】,用完【就关】。
#   调 1000 次下游 = 建 1000 条连接 + 关 1000 条连接。
# 长连接:建一条连接后【复用】,多次请求都走它,不关。
#   调 1000 次下游,可能只用了几条连接。

# === ★ 短连接 + 主动关闭 = TIME_WAIT 工厂 ===
# 我这个服务用的是短连接,而且每次都是【它主动关闭】
#   连接。于是:
#  - 每调一次下游,产生一条 TIME_WAIT
#  - 每条 TIME_WAIT 占一个本地端口,占 60 秒
# ★ 高峰期它每秒调几百上千次下游 -> 60 秒内就建并关了
#   几万条连接 -> 几万条 TIME_WAIT -> 2.8 万个端口占光。

# === 算一笔账,一眼看清临界点 ===
# 本地端口约 2.8 万个,TIME_WAIT 待 60 秒。
# ★ 意味着:对【同一个下游】,你每 60 秒最多只能新建
#   约 2.8 万条短连接 —— 折合每秒约 466 条。
# 一旦【新建短连接的速率】超过这条线,端口必然耗尽。
$ ss -ant state time-wait | wc -l            # 看离 2.8 万还有多远

# === ★ 为什么"连同一个下游"特别容易爆 ===
# TCP 连接靠四元组区分。连【同一个】下游 IP:端口时,
#   四元组里目的 IP、目的端口、源 IP 都固定了 ——
#   ★ 唯一能变的只剩"源端口"。所以源端口一耗尽,
#   就再也建不出新连接。
# 而连【很多不同】下游时,目的 IP 不同,四元组组合多,
#   同一个源端口能复用 —— 没那么容易爆。
# ★ "高频 + 短连接 + 打同一个下游" = 最容易端口耗尽。

# === 确认就是这个模式 ===
$ ss -antp state time-wait | grep 9400 | awk '{print $5}' \
    | sort | uniq -c | sort -rn | head
  28000 10.0.0.50:8080      # ★ 几万条 TIME_WAIT 全冲一个下游 —— 实锤

修复 4:确认端口耗尽 + 找谁在狂建短连接

# === ★ 排查"Cannot assign requested address"的步骤 ===

# === 第一步:连接状态分布,看 TIME_WAIT 占比 ===
$ ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
  28300 TIME-WAIT
   1200 ESTAB
# ★ TIME-WAIT 远多于 ESTAB,且总数逼近 2.8 万 ——
#   基本就是本地端口被 TIME_WAIT 占满了。

# === 第二步:确认本地端口范围,算出"天花板" ===
$ cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999
# ★ 60999 - 32768 + 1 ≈ 28232 个端口,这就是上限。

# === 第三步:看 TIME_WAIT 都冲着哪个目的地 ===
$ ss -ant state time-wait | awk '{print $5}' | sort | uniq -c | sort -rn | head
  28100 10.0.0.50:8080
# ★ 高度集中在一个下游 = 对那个下游的短连接太猛。

# === ★ 第四步:揪出是哪个进程在狂建连接 ===
$ ss -antp state time-wait | grep -oP 'pid=\K[0-9]+' \
    | sort | uniq -c | sort -rn | head
  28000 9400
$ ps -p 9400 -o pid,comm,args
9400  java  /opt/app/bin/run ...             # ★ 锁定:就是这个服务

# === 第五步:看新建连接的速率有多快 ===
$ for i in 1 2 3; do ss -ant state time-wait | wc -l; sleep 2; done
28100
28200
28230
# ★ TIME_WAIT 数持续顶在 2.8 万附近不掉 = 端口一直满负荷。

# === ★ 第六步:确认报错确实是"借不到端口" ===
$ dmesg | grep -i 'port'                     # 有时内核也会留痕
# 或在应用日志里找 EADDRNOTAVAIL / Cannot assign。
# 也可手动验证:此刻发起一条到该下游的连接,大概率也失败。

# === 同时排除:不是 IP 真出问题 ===
$ ip addr                                     # 本机 IP 在不在、对不对
$ ping 10.0.0.50                               # 到下游通不通
# ★ IP 和网络都正常,而 TIME_WAIT 满 —— 锁定端口耗尽。

修复 5:正确的解法——连接复用是根治,内核参数是缓解

# === ★ 解法分两层:根治(改连接方式)和 缓解(调内核) ===

# === ★ 根治:把短连接改成"连接复用"(长连接/连接池)===
# 端口耗尽的【根因】是:每次调下游都新建+关闭一条连接。
# 真正的修复,是让连接【复用】起来,从源头少建连接。
#  - HTTP 客户端开启 keep-alive,复用已有连接
#  - 用【连接池】:建少量连接,反复借还,而不是用完就扔
# ★ 几条连接复用着用,TIME_WAIT 自然就降到了个位数。
#   这是开发侧要改的,但运维要能把根因定位到这里。

# 检查 HTTP 客户端是不是在用连接池 / keep-alive:
$ ss -ant state established | grep 10.0.0.50 | wc -l
# ★ 改对之后,这里应该是【少量、稳定】的几条 ESTAB,
#   而不是疯狂新建又疯狂 TIME_WAIT。

# === 缓解 1:把本地端口范围调宽 ===
$ vi /etc/sysctl.conf
net.ipv4.ip_local_port_range = 10000 65535
$ sysctl -p
# ★ 把可用端口从 2.8 万扩到约 5.5 万 —— 天花板抬高,
#   但如果短连接速率够猛,扩了照样能撑爆。治标。

# === ★ 缓解 2:开启 tcp_tw_reuse(安全、推荐)===
$ vi /etc/sysctl.conf
net.ipv4.tcp_tw_reuse = 1
$ sysctl -p
# tcp_tw_reuse:允许把处于 TIME_WAIT 的端口,★【安全地】
#   复用给【新发起的对外连接】。它有时间戳保护,不会
#   收错旧包 —— 对"大量对外短连接"的场景很对症。

# === ★ 缓解的大坑:别开 tcp_tw_recycle ===
# 网上老教程常让你开 net.ipv4.tcp_tw_recycle = 1。
# ★ 千万别开。它在 NAT 环境下会【错误丢弃】数据包,
#   导致部分客户端连不上 —— 它危害大,新内核已删除。
# 要快速回收 TIME_WAIT 端口,用 tcp_tw_reuse,不是 recycle。

# === 缓解 3:确认 tcp_timestamps 是开的 ===
$ cat /proc/sys/net/ipv4/tcp_timestamps
1
# ★ tcp_tw_reuse 依赖时间戳机制,这个必须是 1
#   (默认就是 1,确认一下别被人关了)。

# === ★ 解法优先级 ===
# 1. 改连接复用(连接池 / keep-alive)—— 根治,必须做
# 2. 开 tcp_tw_reuse —— 安全的缓解
# 3. 调宽 ip_local_port_range —— 抬高天花板
# ★ 只做 2、3 不做 1,是给一个漏水的桶不停换大桶 ——
#   连接复用这个洞不补,迟早还会满。

修复 6:TIME_WAIT 与端口排查纪律

# === 这次事故暴露的认知盲区,定几条纪律 ===

# === 1. ★ Cannot assign requested address 是本地端口耗尽 ===
# 不是 IP 出错。每条对外连接都要借一个本地源端口。

# === 2. ★ TIME_WAIT 不是 bug,是主动关闭方的正常必经状态 ===
# 它保证最后的 ACK 送达、防止旧包污染新连接,待约 60 秒。

# === 3. TIME_WAIT 多 = 主动关了很多连接,不等于泄漏 ===
# 泄漏看 ESTAB / CLOSE-WAIT 只涨不跌,不是看 TIME_WAIT。

# === 4. ★ TIME_WAIT 期间本地端口不释放,这才是端口耗尽的因 ===
$ ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# === 5. 高频 + 短连接 + 打同一个下游 = 最容易端口耗尽 ===
$ cat /proc/sys/net/ipv4/ip_local_port_range   # 算天花板

# === 6. ★ 根治是连接复用(连接池/keep-alive),不是调参数 ===

# === 7. ★ 调参用 tcp_tw_reuse,绝不要用 tcp_tw_recycle ===
# recycle 在 NAT 下会丢包,危害大。

# === 8. 排查"Cannot assign requested address"的命令链 ===
$ ss -ant|awk '{print $1}'|sort|uniq -c       # ① 看 TIME_WAIT 占比
$ cat /proc/sys/net/ipv4/ip_local_port_range  # ② 算端口天花板
$ ss -ant state time-wait|awk '{print $5}'|sort|uniq -c  # ③ 冲哪个下游
$ ss -antp state time-wait|grep pid           # ④ 找狂建连接的进程
$ 改连接池 + 开 tcp_tw_reuse                   # ⑤ 根治 + 缓解
# 按这个顺序,端口耗尽基本能定位、能根治。

命令速查

需求                        命令
=============================================================
看连接状态分布              ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
只看 TIME_WAIT 连接          ss -ant state time-wait
看本地端口可用范围          cat /proc/sys/net/ipv4/ip_local_port_range
看 TIME_WAIT 冲着哪个下游    ss -ant state time-wait | awk '{print $5}' | sort | uniq -c
找狂建连接的进程            ss -antp state time-wait | grep pid=
调宽本地端口范围            sysctl 改 net.ipv4.ip_local_port_range
安全复用 TIME_WAIT 端口     sysctl 改 net.ipv4.tcp_tw_reuse = 1
确认 tcp_timestamps 开着     cat /proc/sys/net/ipv4/tcp_timestamps
看已建立的连接数            ss -ant state established | wc -l
持久化内核参数              写 /etc/sysctl.conf 后 sysctl -p

口诀:Cannot assign address 是本地端口耗尽不是 IP 错
      TIME_WAIT 是正常状态别想着清,根治靠连接复用,调参用 tw_reuse 别用 recycle

避坑清单

1. Cannot assign requested address 耗尽的是本地源端口,不是 IP 地址出了问题
2. 每发起一条对外连接都要从 ip_local_port_range 借一个本地端口,默认约 2.8 万个
3. TIME_WAIT 不是 bug 不是泄漏,是主动关闭连接方必经的正常 TCP 状态
4. TIME_WAIT 保证最后的 ACK 送达,并防止上条连接的旧包污染新连接,待约 60 秒
5. Linux 的 TIME_WAIT 时长 2倍MSL 约 60 秒是写死的,改不了,也没法安全杀掉它
6. TIME_WAIT 期间本地端口不释放,几万条 TIME_WAIT 就会把端口范围占满
7. 高频加短连接加都打同一个下游,四元组只剩源端口可变,最容易端口耗尽
8. 根治是连接复用,用连接池或 keep-alive 让连接反复用,而不是用完就关
9. 缓解可开 tcp_tw_reuse 安全复用 TIME_WAIT 端口,并调宽 ip_local_port_range
10. 绝对不要开 tcp_tw_recycle,它在 NAT 环境下会错误丢包,新内核已经删除它

总结

这次"服务报 Cannot assign requested address、两万八千条 TIME_WAIT 堆成山"的事故,纠正了我一个根深蒂固的思维习惯:看到一个数字异常地大,就本能地认定它是"故障"。当 ss 在屏幕上打出两万八千多条 TIME_WAIT 时,我的判断几乎是瞬间、不假思索完成的——这么多、这么不正常,它一定是哪里出了错,一定是连接泄漏了,这两万八千条一定是没被关干净的"僵尸"。我后续所有的动作,都是顺着这个判断展开的:我去找清除它们的命令,我想把它们一条条"杀掉"。我把它们当成了敌人。可我找遍了所有办法,也没能"消灭"哪怕一条 TIME_WAIT——它们就那样安静地、不可撼动地待在那里。现在回头看,我的失败,不在于我不懂某条命令,而在于我从一开始,就把一个"正常现象"误判成了"故障现象",于是我所有的努力,都用在了一个根本不该有的目标上——消灭一个本就不该被消灭的东西。复盘到根上,我才真正理解了 TIME_WAIT 的身世。它根本不是连接"坏掉"的样子,恰恰相反,它是连接"好好地、规规矩矩地关闭"之后,必然要经历的一段路。一条 TCP 连接,主动关闭它的那一方,在挥手作别之后,并不会立刻人间蒸发,它会在 TIME_WAIT 这个状态里,沉默地驻留大约六十秒。它驻留,是为了万一对方没收到自己最后的道别、还能再补一次;它驻留,也是为了站岗——守住这个刚用过的地址,等网络里那些上一段对话残留的、还在游荡的旧消息,全部自然消逝,免得它们飘进一段新对话里,造成误会。TIME_WAIT 是 TCP 这个协议为了"可靠"和"干净"而精心设计的一道工序,它是一种克制,一种善后,一种负责任。我那两万八千条 TIME_WAIT,非但不是连接泄漏的证据,反而正好相反——它证明了这些连接,每一条都被老老实实地、主动地关闭了。真正的问题,从来不是"TIME_WAIT 存在",而是我用了一种"用完就扔"的方式去和下游打交道:每一次调用都新建一条连接、然后立刻关掉,于是每一次调用都诚实地留下一条正在善后的 TIME_WAIT。高峰期调用太密,善后中的连接还没来得及把端口归还,新的连接就已经排着队来借端口了——本地端口这个有限的资源,就这样被一群"正在尽责善后"的连接占满了。问题出在我建立连接的方式太挥霍,而不出在 TIME_WAIT 太尽责。这次最大的收获,是我对"异常的数量"和"异常的本质"这两件事,学会了分开来看。一个数字大得吓人,这只是一个"现象";这个现象到底是病,还是某种正常机制在大流量下被放大后的、正常的样子,是另一个需要独立去判断的问题。我过去太容易在看到大数字的一瞬间,就跳过"它是什么"这一步,直接冲到"怎么消灭它"。可有些东西,数量再多,它的本质也依然是"正常"——你该做的不是去消灭这个正常的东西,而是去回溯,是什么样的上游行为,制造了这么大的量。下一次,当我再看到某个指标异常地高时,我会先按住自己想要"清理"它的冲动,先冷静地问一句:这个东西,它本来是干什么用的?它的存在,是系统坏了的信号,还是系统在正常运转、只是运转得太猛了的回声?把这个问题想清楚了,我才不会再犯这次的错——对着一群忠于职守的卫兵,徒劳地挥了半天刀。

—— 别看了 · 2026