nginx平滑升级分热升级自身和代理后端服务两类：一是通过usr2/winch/quit信号实现二进制热替换，零中断；二是利用upstream权重或slow_start调度后端流量，支持蓝绿/金丝雀发布。
Nginx 本身不直接“代理升级”，而是通过其进程模型与信号机制实现服务的平滑升级——核心是让新旧版本 Nginx 二进制文件共存、协同工作，用户请求无感知切换。所谓“通过 Nginx 代理实现快速平滑升级”，实际是指：利用 Nginx 自身作为反向代理的能力，在升级过程中保持对外服务不中断，同时完成自身或后端服务的无缝切换。这里分两种典型场景说明：
一、升级 Nginx 自身（热升级）
适用于需更新 Nginx 版本、新增模块（如 http_image_filter_module）或修复安全漏洞，又不能停服的情况。
-
关键前提
- 必须使用原生启动方式（如
/usr/local/nginx/sbin/nginx），而非systemctl start nginx管理的实例（systemd 不完全支持 USR2 流程） - 新版本编译参数必须与旧版一致（用
nginx -V查看并复用），避免模块/路径不兼容
- 必须使用原生启动方式（如
-
四步操作流程
- 备份旧二进制：
mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old
- 编译新版本（只
make，不make install）：./configure --prefix=/usr/local/nginx [其他原参数] make cp objs/nginx /usr/local/nginx/sbin/
- 发送
USR2启动新 master：kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid)
此时
ps -ef | grep nginx可见两组进程：旧 master + worker，新 master + worker - 优雅关闭旧 worker，再退出旧 master：
kill -WINCH $(cat /usr/local/nginx/logs/nginx.pid) # 旧 worker 逐步退出 kill -QUIT $(cat /usr/local/nginx/logs/nginx.pid) # 旧 master 退出
- 备份旧二进制：
✅ 效果：整个过程无连接中断、无 502/404，浏览器刷新无感知；旧 worker 处理完存量请求后自动退出。
二、代理后端服务升级（蓝绿/金丝雀发布）
当升级的是 Nginx 后端的应用服务（如 API 或 Web 应用），Nginx 可作为流量调度器，配合 upstream 实现平滑过渡。
-
配置示例（动态权重切换）
upstream backend { server 192.168.1.10:8080 weight=10; # 老版本 server 192.168.1.11:8080 weight=0; # 新版本（初始零流量） }升级时先将新服务部署就绪，再逐步调高
weight值（如 0→5→10），观察日志与监控；出问题可秒级切回。 -
进阶做法（配合健康检查+slow_start）
upstream backend { server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; server 192.168.1.11:8080 max_fails=3 fail_timeout=30s slow_start=60s; }slow_start防止新实例刚上线就承接全量流量导致雪崩。
三、注意事项与避坑点
-
PID 文件自动重命名：发送
USR2后，旧 master 会把原nginx.pid改为nginx.pid.oldbin，新 master 写入新的nginx.pid—— 别手动删错文件 -
不要跳过
nginx -t：替换二进制后、发信号前，务必执行nginx -t验证配置兼容性（新版可能废弃旧指令） -
回滚极简单：若新版本异常，直接
kill -QUIT新 master，再kill -HUP旧 master（前提是旧二进制未被覆盖） -
日志切割要同步：升级前后建议
kill -USR1重新打开日志，避免新旧进程写混同一文件
不复杂但容易忽略。
