关键在于连接容量上限与复用机制协同：worker_connections需匹配系统ulimit并预留资源，upstream必须配置keepalive复用后端连接，配合分层timeout收敛和worker_shutdown_timeout保障reload不中断长连接。
要让 worker_connections 和 upstream 协同实现后端流量平滑控制，关键不是靠它“分配”流量，而是通过合理设定连接容量上限 + 后端连接复用机制，避免因连接堆积、耗尽或过早断连引发抖动。真正影响平滑度的是连接生命周期管理，而非单纯增大并发数。
worker_connections 要匹配系统与业务真实承载力
它定义每个 worker 进程能同时处理的**最大连接数**（含客户端连接 + 到 upstream 的后端连接）。若设得过高但系统文件描述符（ulimit -n）没跟上，Nginx 会静默降级或启动失败；若设得太低，在高并发或长连接场景下，新请求会被直接拒绝（502/503），造成流量突降。
- 先查系统限制：
ulimit -n，确保 ≥ 所设值；建议设为该值的 70%～80%，预留描述符给日志、临时文件等 - 静态服务（如图片、JS）可设较高（4096–16384）；长连接场景（WebSocket、HTTP/2）需更谨慎，配合
keepalive_timeout控制空闲时长 - 反向代理中，一个客户端请求可能占用 1 个 client 连接 + 1 个 upstream 连接，高峰时连接数接近 2× 并发请求数
upstream 必须启用 keepalive 复用后端连接
默认情况下，Nginx 每次请求都新建到后端的 TCP 连接，频繁建连/断连不仅增加延迟，还易触发 TIME_WAIT 堆积、端口耗尽，导致上游连接失败——这比 worker_connections 不足更常引发不平滑。
- 在
upstream块中显式配置keepalive N;（如keepalive 32;），表示每个 worker 进程最多缓存 N 个空闲后端连接 - 配套设置
proxy_http_version 1.1;和proxy_set_header Connection '';，确保 HTTP/1.1 Keep-Alive 生效 - 后端服务也需支持长连接（如 Tomcat 的
maxKeepAliveRequests、Go net/http 默认开启）
连接超时参数要分层收敛，避免悬空等待
多个 timeout 参数共同决定一个请求在 Nginx 内的“驻留时间”，若设置不当，连接会长时间卡住，挤占 worker_connections 槽位，间接导致新请求排队或被丢弃。
-
proxy_connect_timeout：建立到 upstream 的 TCP 连接超时，建议 3s～5s（网络稳定时） -
proxy_send_timeout：发送请求体给后端的超时，按业务最大写入时间设（如文件上传设 30s） -
proxy_read_timeout：读取后端响应的超时，应 ≥ 后端最慢接口预期耗时，但不宜远超（如 60s） -
keepalive_timeout（upstream 级）：空闲后端连接保持时间，建议略大于后端的keepalive_timeout，避免单边关闭
配合 worker_shutdown_timeout 实现 reload 时不中断长连接
当修改 upstream 配置并执行 nginx -s reload 时，旧 worker 仍需处理已建立的长连接（包括到后端的 keepalive 连接）。若未设 worker_shutdown_timeout，旧进程可能无限等待，导致连接无法释放、新 worker 无法及时接管。
- 该指令必须放在
main块（全局块），例如：worker_shutdown_timeout 60s; - 值需覆盖典型长连接生命周期：HTTP/1.1 Keep-Alive 建议 30s～60s；WebSocket/gRPC 建议 1m～5m
- 它不改变负载均衡逻辑，但保障 reload 过程中已有连接不受干扰，是“平滑”的底层前提
