报错是这么冒出来的。Nginx 1.24 反代推理服务,upstream 块没配 keepalive,QPS 到 800 时后端每秒看到 800 个新连接,TIME_WAIT 涨到 6 万,偶发 connect() failed (99: Cannot assign requested address)。
中间走过弯路,把「Connection 头没清掉 close」当成主因,改完现象没变。
原因不止一个,得分开看。upstream 块缺 keepalive 指令,默认短连接。少数情况下是proxy_http_version 还是 1.0,无法复用连接。
另外,本地端口被 TIME_WAIT 耗尽。
上来先确认 upstream 的配置
nginx -T 2>/dev/null | grep -A6 'upstream'
接着加上 keepalive 并改为 HTTP/1.1
python -c "print('upstream api { server 10.0.0.8:8000; keepalive 64; }')"
然后清掉客户端传来的 Connection 头
python -c "print('proxy_set_header Connection \"\";')"
reload 后看连接数与 TIME_WAIT
nginx -s reload && ss -s | grep -i timewait
这类问题以前遇到过,但这次的触发条件和上次不一样。
这类改动我都写进变更记录,过两周再出问题时能对上号。
我习惯把每一步的执行时间和结果记在一边,后面复盘省事。
改之前我把相关日志按时间截了一段存着,事后对时间线用得上。
别只看报错消失,验证要多做一步。后端看到的连接数稳定在 64 左右,TIME_WAIT 明显下降,connect failed 不再出现,QPS 800 时 P99 保持稳定。
keepalive 指令只是开启连接池,还要 HTTP/1.1 和清空 Connection 头才真正复用;只加一行配置往往看不到效果。拖得越久,排查成本越高,因为现场状态会被后续操作覆盖。
