从 Nginx 1.18 升级到 1.24 版本，反向代理的核心配置语法基本兼容，但必须重新编译或使用官方包以确保模块支持。升级前务必备份配置文件并核对编译参数，重点关注 SSL 模块和 HTTP/2 配置的默认行为变化。
先说结论：升级过程本身风险可控，主要工作量在于环境一致性检查和配置语法核对。
- 适合：需要新特性支持、安全补丁或解决旧版本 Bug 的生产环境。
- 先准备：备份现有配置与二进制文件，记录旧版本的编译参数。
- 验收：通过日志监控和业务请求测试确认代理转发正常。
命令速用版
以下命令用于备份和查看旧版本配置，执行前请确认路径，注意目标目录需先创建：
# 创建备份目录并备份配置文件
mkdir -p /nginx-backup && cp -r /usr/local/nginx/conf /nginx-backup/conf
# 备份旧二进制文件
cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old
# 查看旧版本编译参数（重要，用于新版本编译对齐）
/usr/local/nginx/sbin/nginx -V版本差异与兼容性对比
1.18 到 1.24 跨越了多个稳定版周期，虽然反向代理指令（如 proxy_pass）保持稳定，但底层依赖和默认行为可能有变。以下是关键差异点：
| 配置项 | Nginx 1.18 | Nginx 1.24 | 升级注意点 |
|---|---|---|---|
| SSL 协议 | 支持 TLS 1.3（需配置） | 默认更倾向安全 cipher | 检查 ssl_protocols 和 ssl_ciphers 兼容性 |
| HTTP/2 | 稳定支持 | 性能优化 | 配置语法不变，确认模块已编译 |
| 编译模块 | 依赖旧版 OpenSSL | 依赖新版 OpenSSL | 重新编译时需指定相同模块路径 |
| 弃用指令 | 无主要弃用 | 无主要弃用 | 主要风险在于模块缺失而非指令弃用 |
分步处理
1. 环境检查与备份：确认系统依赖库（OpenSSL、PCRE）版本，备份 conf 目录和 html 目录。若为源码安装，需保留旧版本的 configure 参数。
2. 获取新版本：下载 1.24 源码或使用官方 apt/yum 源。若源码编译，确保使用与旧版本一致的 prefix 和模块参数（参考 nginx -V 输出）。
3. 平滑升级：
- 源码编译用户：编译完成后，可使用 make upgrade。该命令会自动发送 USR2 信号启动新主进程，再发送 WINCH 信号让旧工作进程退出。注意：执行前确保新二进制已安装到相同路径，并监控进程表确认新旧进程共存正常。
- 包管理用户：直接使用包管理器升级，服务通常会自动 reload，但建议手动执行 nginx -t 后再重启服务。
4. 配置核对：检查 nginx.conf 中是否有已弃用指令，特别是涉及 SSL 和 HTTP2 的配置块。虽然 1.18 到 1.24 无重大指令弃用，但需确保新二进制包含所需模块。
怎么验证是否生效
1. 语法测试：执行 nginx -t 确保配置无语法错误。
2. 版本确认：执行 nginx -v 确认版本号已变更为 1.24。
3. 业务测试：通过 curl 访问代理后的后端服务，确认状态码为 200 且响应头正确。例如：curl -I http://your-domain.com。
4. 日志监控：查看 error.log 是否有启动报错或 SSL 握手失败记录。监控 CPU 和内存使用率，确保无异常波动。
常见坑
1. SSL 模块缺失：旧配置启用了 HTTPS，新编译若漏掉 `--with-http`_ssl_module 会导致启动失败。务必对比旧版 nginx -V 输出。
2. IPv6 支持：新版本若重新编译，需确认是否包含 IPv6 模块，否则 listen [::]:80 会报错。编译参数需包含 `--with-ipv6`（旧版）或确保系统支持。
3. 配置逻辑复查：proxy_pass 末尾斜杠问题虽非版本特有，但升级是复查配置的好时机。location 后有斜杠而 proxy_pass 后无斜杠，或反之，会导致路径拼接错误，需严格匹配。