nginx配置热更新与平滑重启本质是通过nginx -s reload发送sighup信号实现：主进程校验语法后fork新worker处理新连接，旧worker继续服务现有请求直至自然退出，全程不中断连接。
Nginx 的配置热更新与平滑重启，本质是通过 不中断现有连接 的方式加载新配置，核心依赖 nginx -s reload 机制，而非重启进程。只要配置语法正确、监听端口未被占用、worker 进程能正常派生，就能实现真正的“零停机”切换。
验证并重载配置（最常用且安全的方式）
这是生产环境首选方法，Nginx 主进程收到 SIGHUP 后会：
- 校验新配置文件语法（
nginx -t的逻辑自动执行） - 若通过，则 fork 新 worker 进程，用新配置服务新连接
- 旧 worker 进程继续处理已有请求，直至自然退出（完成当前请求或超时）
操作命令：
nginx -t && nginx -s reload
建议始终先运行 nginx -t 显式检查，避免因语法错误导致 reload 失败而中断服务。
使用 systemd 管理时的平滑重载
若 Nginx 由 systemd 托管（如 Ubuntu/Debian/CentOS 7+），应避免直接调用 nginx -s reload，改用：
sudo systemctl reload nginx
systemd 会触发预设的 Reload 指令（通常指向 nginx -s reload），同时支持依赖检查和日志关联。确保 service 文件中 Reload 配置正确（默认一般已设置好）。
配合上游变更的负载均衡热更新
当后端服务器列表变化（如滚动发布、扩缩容），仅修改 upstream 块并 reload 即可生效。但注意：
- 健康检查（
health_check或第三方模块如nginx_upstream_check_module）需启用才能自动剔除故障节点 - 若用 DNS 解析 upstream（
resolver+ 变量域名），需配合valid参数和定期 reload 或使用nginx-plus的动态解析能力 - 连接复用（
keepalive）不影响 reload，旧连接仍走原后端，新连接按新 upstream 分发
进阶：无需 reload 的动态上游管理
如需完全避免 reload（例如秒级高频变更），可考虑：
-
nginx-plus：原生支持
API动态增删 upstream server（/api/6/http/upstreams/<name>/servers</name>） -
OpenResty + Lua：用
balancer_by_lua*实现运行时选后端，结合共享字典（shared dict）或 Redis 存储节点列表 - Consul + nginx-upsync-module（开源）：监听 Consul 服务发现事件，自动同步 upstream 列表，无须 reload
这类方案适合微服务场景，但引入了额外组件和复杂度，普通静态负载均衡推荐优先用 reload。
不复杂但容易忽略的是：reload 成功不代表业务完全无感——长连接、HTTP/2 流、WebSocket 等可能受 keepalive timeout 或客户端重连策略影响，需结合应用层设计综合保障体验。
