time_wait本身不占用worker_connections，但会耗尽系统端口和文件描述符，导致nginx无法新建连接；需启用tcp_tw_reuse、调大本地端口范围、上游启用keepalive。
不会直接耗尽 worker_connections，但会间接导致连接资源枯竭。
TIME_WAIT 是 TCP 连接关闭后的状态，它本身不占用 Nginx 的 worker_connections 槽位——因为连接已断开，Nginx 不再持有该连接的 socket 句柄，也不计入当前活跃连接数。真正被限制的是操作系统层面的可用端口和文件描述符（fd），而这两者一旦见底，就会让 Nginx 无法新建连接，表现为“看似 worker_connections 还有余量，却拒绝新请求”。
为什么 TIME_WAIT 多不影响 worker_connections 计数
- worker_connections 统计的是 **当前被 Nginx worker 进程 accept 并维护的连接数**（包括 ESTABLISHED、keep-alive 等），不包含已关闭、仅处于 TIME_WAIT 的连接； - TIME_WAIT 连接由内核协议栈管理，Nginx 已释放对应 fd，不再参与事件循环； - `ss -s` 或 `netstat -an | grep TIME_WAIT | wc -l` 查到的数，不会出现在 `nginx -T | grep worker_connections` 或 `stub_status` 的 Active connections 中。但为什么它会导致“连接耗尽”的假象
本质是系统级资源被占满，Nginx 因无法获取新 fd 而卡在连接入口： - 本地端口耗尽：短连接高频主动关闭（如 Nginx 作为反向代理主动关连 upstream），每秒生成大量 TIME_WAIT；Linux 默认 65535 个本地端口（ephemeral range），若 60 秒内积累超此数，新 connect() 就会失败； - 文件描述符（fd）总数触顶：每个 TIME_WAIT 连接仍占用一个内核 socket 结构（虽不归 Nginx 管，但计入 `/proc/sys/fs/file-nr` 的已分配数）；当 `file-max` 接近上限，新连接即使没到 worker_connections 限额，也会因 `open()` 失败而被内核拒绝； - accept 队列溢出：TIME_WAIT 堆积常伴随高并发短连接，若 `net.core.somaxconn` 过小，SYN 包排队失败，客户端收不到 SYN-ACK，现象就是“连接超时”或“Connection refused”，与 worker_connections 无关。排查时要分清三层瓶颈
- 查 Nginx 层： - `curl -s http://127.0.0.1/nginx_status` 看 Active connections 是否接近 `worker_processes × worker_connections`； - 检查 error.log 是否有 `* * * accept() failed (24: Too many open files)` —— 这说明 worker 进程 fd 上限到了。 - 查系统层： - `ulimit -n` 和 `/proc/$(pidof nginx)/limits` 确认单进程 fd 限制； - `cat /proc/sys/fs/file-nr` 看已用/总文件句柄数； - `ss -s` 关注 `total: X, tcp: Y, orphan: Z, tw: N` —— 若 `tw` 占比高且 `orphan`（即无归属进程的 TIME_WAIT）持续上升，说明端口回收慢； - 查网络层： - `netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'` 确认 TIME_WAIT 数量级； - `sysctl net.ipv4.ip_local_port_range` 查可用端口范围（如 `32768 65535` → 仅 32768 个可用）。关键结论与应对方向
- 如果你看到大量 TIME_WAIT，但 `Active connections` 远低于 `worker_connections × worker_processes`，问题不在 Nginx 配置，而在系统资源或连接模式； - 不要盲目调大 worker_connections —— 它解决不了端口复用或 fd 不足； - 优先做三件事： - 启用 `net.ipv4.tcp_tw_reuse = 1`（安全且推荐）； - 调大 `net.core.somaxconn` 和 `net.ipv4.ip_local_port_range`； - 对上游服务启用 keepalive（减少短连接频次），并确认 Nginx 到 upstream 的连接是复用的（`proxy_http_version 1.1; proxy_set_header Connection '';` + `upstream { keepalive 32; }`）。不复杂但容易忽略。
