Nginx reload 时旧 worker 中的 keepalive 空闲连接不会迁移，而是按 keepalive_timeout（建议20–30秒）自然超时释放；新 worker 同步重建连接池，需配合后端滚动发布与合理 keepalive_requests（500–1000）实现业务无感过渡。
系统重载（nginx -s reload）时，Nginx 默认会启动新 worker 进程、优雅关闭旧 worker 进程，但upstream 长连接本身不会自动继承或迁移——旧 worker 中已建立的 keepalive 空闲连接会在其退出时被主动关闭。要让现有长连接“不受影响”，关键不是保留连接本身，而是确保连接释放可控、业务无感、复用快速恢复。
理解 reload 对 upstream 连接的实际影响
旧 worker 进程在 reload 后进入“优雅退出”阶段：不再接收新请求，但会继续处理已接受的请求和已建立的空闲 keepalive 连接，直到这些连接自然超时（由 keepalive_timeout 控制）或被显式关闭。这意味着：
- 只要
keepalive_timeout设置合理（如 20–30 秒），旧连接会在几十秒内逐步释放，不会瞬间断连 - Nginx 不会强制 kill 空闲连接，也不会把它们“移交”给新 worker —— 这是设计限制，无法绕过
- 客户端感知到的中断，往往来自后端服务重启 + Nginx 连接池清空的叠加效应，而非 reload 本身
减少 reload 期间连接波动的关键配置
真正起作用的是让新 worker 快速重建并复用连接，同时避免旧连接被异常提前终止：
-
设置合理的
keepalive_timeout：建议设为 20–30 秒，且必须小于后端服务的 idle timeout（如 Tomcat 的connectionTimeout）。这样旧连接能在可控窗口内自然退出，新 worker 可同步开始建连复用 -
调高
keepalive_requests（如 500–1000）：避免单连接因请求数达限而提前关闭，延长有效复用周期，降低 reload 前连接碎片化程度 -
确保后端支持快速重建连接：例如 Spring Boot 默认启用 keep-alive；Tomcat 需确认
maxKeepAliveRequests未设为 1，connectionTimeout≥ 30 秒 -
禁用可能干扰的 proxy 指令：如
proxy_buffering off在大响应体场景下易触发流式中断；proxy_http_version 1.0会彻底禁用复用，务必保持为 1.1
配合后端滚动重启，实现“无感”过渡
单独优化 Nginx reload 不足以保证零影响，需与后端部署策略协同：
- 采用滚动发布：每次只下线一台后端实例，其余实例持续提供服务，Nginx 的
max_fails=3 fail_timeout=30s能自动屏蔽短暂不可用节点 - 后端启动完成后再触发 Nginx reload：确保新 worker 建连时，后端已就绪，避免连接拒绝或超时堆积
- 验证连接释放节奏：reload 后执行
ss -tnp | grep :<backend_port> | grep ESTAB | wc -l</backend_port>，观察连接数是否平缓下降而非骤降，确认旧连接按预期超时退出
不推荐但常被误用的做法
有些方案试图“强行保留”连接，实际不可靠或引入新风险：
- 把
keepalive_timeout设得极大（如 300 秒）：会导致旧 worker 拖延退出，占用资源，且连接可能已被后端主动关闭，变成“僵尸连接” - 依赖
ip_hash或least_conn算法“绑定”连接：这些只影响请求分发，不影响连接生命周期，对 reload 无实质帮助 - 用
nginx -s stop && nginx替代 reload：会强制中断所有连接，比 reload 更不优雅
