Nginx平滑重载是配置更新而非升级，通过master-worker架构与信号机制实现无损：校验配置、启动新worker、优雅退出旧worker，确保连接不中断、请求不丢失。
Nginx 平滑重载本身不是“升级”，而是“配置更新”，它通过 master-worker 架构与信号机制实现无损重启——即不中断连接、不丢请求、用户无感知。真正实现无损，关键不在操作动作本身，而在整个流程的设计逻辑和前置保障。
配置重载的核心是进程切换，不是覆盖
执行 nginx -s reload 或 systemctl reload nginx 时，Nginx 并不会杀死旧 worker，而是让 master 进程做三件事：
- 先用 nginx -t 校验新配置语法；失败则中止，旧配置继续运行
- 校验成功后，fork 出一批新 worker 进程，每个都加载完整、只读的新配置副本
- 向旧 worker 发送 QUIT 信号：它们不再 accept 新连接，但会处理完所有已建立的请求（包括长连接上的未完成响应）后才退出
新旧 worker 并行存在一小段时间，端口由 master 统一继承并分发，因此监听不中断、连接不拒绝。
无损的前提是配置变更本身安全
reload 不丢请求，但若配置改得不合理，仍可能引发隐性故障。必须注意：
- 修改 upstream 后端列表时，旧连接仍走原节点，新连接才按新规则分发——这是预期行为，不是问题
- 若启用了 keepalive connections 到 upstream，旧连接复用的是老后端连接池，不影响 reload 本身
- 涉及 SSL/TLS 配置变更（如证书、协议版本），新连接立即使用新设置，但已有 TLS 握手完成的连接不受影响
- 不要直接编辑线上 nginx.conf；应写入临时文件（如 nginx.conf.new），再用 mv nginx.conf.new nginx.conf 原子替换，避免 worker 读到半截配置
真正无损还要考虑应用层兼容性
reload 对 Nginx 是平滑的，但业务是否“无感”，还取决于上层协议和客户端行为：
- HTTP/1.1 的短连接基本无影响；长连接在超时或主动关闭前仍走旧配置路径
- WebSocket 连接不会被中断，但新连接会按新 upstream 或 proxy 设置路由
- HTTP/2 多路复用流在连接生命周期内保持不变；新 stream 按新配置处理
- 客户端若设置了 aggressive keepalive timeout（如 5 秒），可能在 reload 后快速重连，造成瞬时新建连接高峰——这不是 Nginx 问题，但需在容量评估中考虑
回滚比升级更简单，也更可靠
如果 reload 后发现异常（如 502 大量出现、日志报 resolver 超时等）：
- 立刻改回原配置文件（用备份或 git revert），再执行一次 nginx -s reload
- 无需重启、无需等待，几秒内即可切回稳定状态
- 旧 worker 已退出？没关系——只要配置正确，新 reload 仍能启动健康的新 worker
这个能力让 reload 成为生产环境最常用、最值得信赖的变更手段。
