前一天，我刚刚在这台阿里云 ECS 上完成了 PHP 8.5.9 的升级。
服务器使用 Alibaba Cloud Linux 3，Web 环境由 OneinStack 部署。PHP 升级完成以后，我又检查了一下 Nginx，发现当前版本仍然是：
nginx/1.24.0
OpenSSL 1.1.1t
Nginx 1.24.0 已经使用了较长时间，编译时绑定的 OpenSSL 1.1.1t 也比较旧。
考虑到这台服务器承载着我的 WordPress 中文站、英文站、管理子域和静态资源子域，我最终决定继续完成 Nginx 升级。
这次的目标是：
Nginx 1.24.0 → Nginx 1.30.4
OpenSSL 1.1.1t → OpenSSL 3.5.7
PCRE 8.45 → 继续保留 PCRE 8.45
本文记录完整的升级过程，包括中途遇到的源码下载失败、Perl 模块缺失、Python 版本兼容问题、HTTP/2 配置警告，以及最终的完整验收结果。
一、升级前的服务器环境
升级前执行：
/usr/local/nginx/sbin/nginx -V
得到的主要信息为：
nginx version: nginx/1.24.0
built with OpenSSL 1.1.1t 7 Feb 2023
原有编译参数如下：
--prefix=/usr/local/nginx
--user=www
--group=www
--with-http_stub_status_module
--with-http_sub_module
--with-http_v2_module
--with-http_ssl_module
--with-stream
--with-stream_ssl_preread_module
--with-stream_ssl_module
--with-http_gzip_static_module
--with-http_realip_module
--with-http_flv_module
--with-http_mp4_module
--with-openssl=../openssl-1.1.1t
--with-pcre=../pcre-8.45
--with-pcre-jit
--with-ld-opt=-ljemalloc
为了尽量降低升级风险，我没有在这次操作中同时更换 PCRE，也没有改变原有模块组合。
这次只处理两个核心组件：
- 将 Nginx 升级到 1.30.4。
- 将静态编译使用的 OpenSSL 升级到 3.5.7。
二、为什么没有直接运行 OneinStack 的升级脚本
服务器上保留了两个 OneinStack 目录：
/root/oneinstack
/root/oneinstack-latest-20260804其中，/root/oneinstack-latest-20260804 是前一天升级 PHP 8.5.9 时准备的新版 OneinStack 副本。
昨天的操作只涉及 PHP 相关脚本，没有修改 Nginx 的升级逻辑，也没有执行 Nginx 升级。
今天准备升级 Nginx 时，我重新检查了这个 OneinStack 副本中的相关脚本。当前脚本会使用 OpenSSL 1.1.1w 编译新版 Nginx，并通过 Nginx 的在线热升级流程切换二进制。
但这次我希望将 OpenSSL 一并升级到 3.5.7，而且可以接受网站出现短暂不可访问。
因此，我没有直接运行 OneinStack 自带的 Nginx 升级功能，而是采用了下面的方案：
- 在独立目录中下载和编译新版本。
- 编译期间保持线上 Nginx 1.24.0 不变。
- 使用新二进制测试当前生产配置。
- 备份旧版二进制和完整 Nginx 配置。
- 优雅停止旧版 Nginx。
- 覆盖生产二进制并启动新版本。
- 如果配置测试或启动失败，立即恢复旧版二进制。
这种方式虽然会产生短暂停机，但整个过程比较直观，回滚路径也更加清楚。
三、先在旁路目录中编译新版本
我为这次编译创建了独立目录：
/root/nginx-build-1.30.4-openssl-3.5.7
编译完成后的临时二进制则放在：
/root/nginx-1.30.4-openssl-3.5.7
在新二进制完成配置测试以前，不会修改生产环境中的：
/usr/local/nginx/sbin/nginx
这种旁路编译方式有一个明显好处：即使下载、配置或编译失败，当前正在运行的 Nginx 也不会受到影响。
四、第一次从 GitHub 下载 OpenSSL 失败
Nginx 1.30.4 源码包可以正常从 Nginx 官方网站下载，但从 GitHub Releases 下载 OpenSSL 3.5.7 时，连接持续约 90 秒后失败：
curl: (52) Empty reply from server
Connection to 121.40.248.29 closed.
这里实际上包含两个问题。
第一个问题是，这台阿里云 ECS 访问 GitHub Release Assets 不够稳定。
第二个问题是，我当时直接在交互式 SSH Shell 中执行了：
set -euo pipefail
其中的 set -e 表示，只要某条命令返回非零状态，Shell 就立即退出。
因此，curl 下载失败以后，不只是下载命令停止了，整个远程 Shell 也一起退出，表现出来就是 SSH 连接直接关闭。
后来我做了两项调整：
- 改用阿里云镜像下载 OpenSSL 3.5.7。
- 将后续下载和编译过程放在单独的 Bash 子进程中。
例如：
bash <<'BASH'
set -euo pipefail
# 下载、校验和编译操作
BASH
这样，即使子进程再次失败，也只会结束子进程，不会把当前 SSH 会话一起关闭。
OpenSSL 下载完成以后，我还验证了源码包的 SHA-256：
a8c0d28a529ca480f9f36cf5792e2cd21984552a3c8e4aa11a24aa31aeac98e8
验证结果为：
openssl-3.5.7.tar.gz: 成功
五、Nginx 配置阶段顺利通过
解压 Nginx、OpenSSL 和 PCRE 源码以后，我从当前生产二进制中提取了原有编译参数。
然后只替换其中的 OpenSSL 路径：
--with-openssl=../openssl-1.1.1t
修改为：
--with-openssl=../openssl-3.5.7
PCRE 仍然保留：
--with-pcre=../pcre-8.45
--with-pcre-jit
Nginx 的 configure 阶段顺利完成，并正确识别到：
using PCRE library: ../pcre-8.45
using OpenSSL library: ../openssl-3.5.7
using system zlib library
这说明 Nginx 本身的配置参数没有问题，可以继续进入正式编译阶段。
六、编译时第一次缺少 Perl 模块 IPC::Cmd
正式执行 make 后，OpenSSL 配置过程首先报错：
Can't locate IPC/Cmd.pm in @INC
进一步的信息显示，OpenSSL 3.5.7 的配置脚本需要 Perl 模块：
IPC::Cmd
Alibaba Cloud Linux 3 中可以直接通过系统软件包安装：
dnf install -y perl-IPC-Cmd
安装完成后验证：
perl -MIPC::Cmd -e \
'print "IPC::Cmd version: $IPC::Cmd::VERSION\n"'
输出为：
IPC::Cmd version: 1.02
随后重新执行编译。
七、第二次又缺少 Time::Piece
补齐 IPC::Cmd 后，OpenSSL 已经能够开始生成配置，但紧接着又出现了新的错误：
Can't locate Time/Piece.pm in @INC
这次缺少的是：
Time::Piece
如果继续逐个安装模块，后面可能还会遇到其他 Perl 核心模块缺失。
因此，我没有再单独安装 Time::Piece，而是直接补齐 Perl 核心组件：
dnf install -y perl-core
然后分别验证：
perl -MIPC::Cmd -e \
'print "IPC::Cmd version: $IPC::Cmd::VERSION\n"'
perl -MTime::Piece -e \
'print "Time::Piece version: $Time::Piece::VERSION\n"'
所需模块准备完成以后，再次执行 make。
这一次，Nginx 1.30.4、OpenSSL 3.5.7 和 PCRE 8.45 均顺利完成编译。
八、先用新二进制测试生产配置
编译完成以后，我没有立刻覆盖线上 Nginx，而是先检查新二进制：
/root/nginx-1.30.4-openssl-3.5.7 -V
输出的主要信息为：
nginx version: nginx/1.30.4
built with OpenSSL 3.5.7 9 Jun 2026
新版本保留了原有模块和编译参数，只将 OpenSSL 路径升级到了 3.5.7。
随后，使用新二进制直接测试当前生产配置：
/root/nginx-1.30.4-openssl-3.5.7 \
-p /usr/local/nginx/ \
-t \
-c /usr/local/nginx/conf/nginx.conf
配置语法检查和完整测试均成功：
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
新二进制的 SHA-256 为：
bd95deac509fd0d7720541f35cb0231711a235262067ae62695bea1b17ebed67
此时，线上仍然运行 Nginx 1.24.0，新版本只是作为一个独立文件保存在 /root 下。
九、新版本发现旧版 HTTP/2 配置警告
虽然配置测试通过，但 Nginx 1.30.4 给出了多条警告：
the "listen ... http2" directive is deprecated,
use the "http2" directive instead
涉及的虚拟主机包括：
admin.shuijingwanwq.com.conf
cn-test.shuijingwanwq.com.conf
media.shuijingwanwq.com.conf
www.shuijingwanwq.com.conf
原来的配置写法为：
listen 443 ssl http2;
listen [::]:443 ssl http2;
这种写法在新版本中仍然能够使用，但已经被标记为弃用。
由于它只是警告，不会阻止 Nginx 启动，所以我没有在正式切换二进制以前同时修改配置。
这样可以让两个步骤相互独立：
- 先确认 Nginx 1.30.4 二进制能够正常接管生产流量。
- 再单独修改 HTTP/2 配置并 reload。
如果中途出现问题，也更容易判断是二进制升级导致的，还是配置修改导致的。
十、备份旧版 Nginx 和完整配置
正式切换以前，我创建了升级备份目录：
/root/nginx-upgrade-backup-20260805-172623
备份内容包括：
旧版 Nginx 1.24.0 二进制
完整的 /usr/local/nginx/conf 配置目录
旧版 nginx -V 输出
新旧二进制 SHA-256
旧版二进制文件名为：
nginx-1.24.0
如果新版本配置测试失败或无法启动，升级脚本会自动：
- 停止可能已经启动的新 Nginx。
- 将旧版二进制恢复到生产路径。
- 使用旧版二进制重新测试配置。
- 启动旧版 Nginx。
十一、停止旧 Nginx 并切换生产二进制
完成所有检查和备份以后，我向旧版 Nginx master 进程发送了 QUIT 信号，让它优雅退出：
kill -QUIT "$master_pid"
旧版 Nginx 大约等待了 29 秒才完全停止。
随后，将已经验证过的新二进制安装到：
/usr/local/nginx/sbin/nginx
安装命令类似：
install \
-m 0755 \
/root/nginx-1.30.4-openssl-3.5.7 \
/usr/local/nginx/sbin/nginx
覆盖完成以后再次检查：
nginx version: nginx/1.30.4
built with OpenSSL 3.5.7 9 Jun 2026
然后重新执行生产配置测试，并启动 Nginx 1.30.4：
/usr/local/nginx/sbin/nginx \
-c /usr/local/nginx/conf/nginx.conf
启动完成后，进程状态为：
nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx: worker process
nginx: worker process
这说明新版 master 和 worker 均已经正常运行。
十二、最初的本地回源测试为什么出现 000
切换完成以后，我通过 curl --resolve 将域名强制解析到 127.0.0.1，直接测试源站。
第一次测试结果为：
www.shuijingwanwq.com 000
en.shuijingwanwq.com 200
admin.shuijingwanwq.com 000
000 并不是真正的 HTTP 状态码，它表示 curl 没能在规定时间内取得完整响应。
由于第一次命令将错误输出隐藏了，所以单看 000 很容易误以为 Nginx、TLS 或虚拟主机配置存在问题。
后来重新使用详细模式测试：
curl \
--http1.1 \
--verbose \
--insecure \
--max-time 20 \
--resolve "www.shuijingwanwq.com:443:127.0.0.1" \
"https://www.shuijingwanwq.com/" \
--output /dev/null
最终发现：
www和admin均已成功建立 TLS 1.3 连接。- 两个站点最终都返回了
HTTP/1.1 200 OK。 - 完整响应时间大约为 16 秒。
- 第一次测试设置的超时时间只有 15 秒。
也就是说，第一次的 000 只是因为测试超时时间比实际响应时间短了一点，并不是 Nginx 升级失败。
再次测试以后，三个站点的源站 HTTPS 请求均正常返回 200。
公网测试结果同样正常：
https://www.shuijingwanwq.com/ 200
https://en.shuijingwanwq.com/ 200
https://admin.shuijingwanwq.com/ 200
其中：
- 中文站通过 EdgeOne 提供访问。
- 英文站通过 Cloudflare 提供访问。
- 管理子域直接访问源站。
十三、修改旧版 HTTP/2 配置
确认 Nginx 1.30.4 已正常运行后，我开始处理之前发现的 HTTP/2 弃用警告。
先备份四个虚拟主机配置：
/root/nginx-http2-config-backup-20260805-173655
然后将旧写法：
listen 443 ssl http2;
listen [::]:443 ssl http2;
修改为：
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
这样，监听端口和启用 HTTP/2 被拆分成独立指令，符合新版 Nginx 的配置方式。
十四、修改配置时又遇到 Python 3.6 兼容问题
我最初使用 Python 脚本批量修改四个虚拟主机配置，其中包含下面的类型注解：
output: list[str] = []
执行时出现错误：
TypeError: 'type' object is not subscriptable
检查以后发现，服务器上的 Python 版本为：
Python 3.6.8
list[str] 这种内置泛型写法需要更新版本的 Python。Python 3.6 无法识别，所以脚本在真正写入配置文件以前就终止了。
好在修改前已经创建备份，脚本也执行了恢复操作，因此线上配置没有受到影响。
后来将这一行改成普通写法：
output = []
同时避免使用其他较新的 Python 语法，脚本便可以在 Python 3.6.8 中正常执行。
四个配置文件最终都成功转换为：
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
配置测试成功后执行 reload：
/usr/local/nginx/sbin/nginx -s reload
reload 完成后，Nginx master 进程保持不变，两个 worker 进程已经更新，说明新配置成功加载。
十五、完整验收结果
最终执行：
/usr/local/nginx/sbin/nginx -V
/usr/local/nginx/sbin/nginx -t
确认线上版本为：
nginx version: nginx/1.30.4
built with OpenSSL 3.5.7 9 Jun 2026
配置测试结果：
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
HTTP/2 旧写法的弃用警告已经消失。
Nginx 正常监听：
0.0.0.0:80
0.0.0.0:443
[::]:80
[::]:443
master 进程和两个 worker 进程均正常运行。
公网 HTTP/2 验证
三个公网地址均通过 HTTP/2 返回 200：
www.shuijingwanwq.com
http_code=200
http_version=2
en.shuijingwanwq.com
http_code=200
http_version=2
admin.shuijingwanwq.com
http_code=200
http_version=2
源站 HTTP/2 验证
绕过 CDN，直接将域名解析到 127.0.0.1 后：
www.shuijingwanwq.com
http_code=200
http_version=2
admin.shuijingwanwq.com
http_code=200
http_version=2
这说明源站 Nginx 的 HTTP/2 配置已经真正生效，而不只是 CDN 边缘节点支持 HTTP/2。
WordPress 功能验证
下面几个关键地址均返回 200：
https://www.shuijingwanwq.com/wp-json/
https://www.shuijingwanwq.com/wp-login.php
https://en.shuijingwanwq.com/wp-json/
https://admin.shuijingwanwq.com/wp-admin/
这说明 WordPress REST API、登录页面、英文站和管理后台都可以正常访问。
PHP-FPM 验证
PHP-FPM master 和 worker 进程运行正常，并正常监听：
/dev/shm/php-cgi.sock
因此，Nginx 与 PHP-FPM 之间的 FastCGI 通信也没有因为本次升级受到影响。
错误日志验证
检查 Nginx 日志后，没有发现本次升级后新增的以下严重错误：
emerg
alert
crit
segfault
upstream timed out
connect() failed
prematurely closed
默认错误日志中仍能看到之前产生的 HTTP/2 弃用警告，但这些都是修改配置以前留下的历史记录。
配置修改和 reload 以后，没有再产生新的同类警告。
十六、PHP 日志中的提示与本次 Nginx 升级无关
最终检查 PHP-FPM 日志时，仍然可以看到一些 PHP 8.5 兼容性提示。
Nimble Builder 存在翻译加载时机过早的 Notice：
Translation loading for the nimble-builder domain was triggered too early
Organize Series 使用了 PHP 8.5 中已经弃用的方法：
SplObjectStorage::attach()
SplObjectStorage::contains()
Yoast SEO 则出现了将 null 用作数组下标的 Deprecated 提示。
这些问题来自前一天升级的 PHP 8.5.9，并不是 Nginx 1.30.4 或 OpenSSL 3.5.7 导致的。
目前它们都只是 Notice 或 Deprecated，并不是 Fatal Error。由于网站前台、后台、REST API 和 PHP-FPM 均正常运行，所以没有必要在这次 Nginx 升级中继续扩大修改范围。
相关插件兼容问题可以作为后续独立任务处理。
十七、本次升级后的备份位置
本次升级保留了两组主要备份。
Nginx 1.24.0 二进制和完整升级前配置位于：
/root/nginx-upgrade-backup-20260805-172623
HTTP/2 配置修改前的四个虚拟主机文件位于：
/root/nginx-http2-config-backup-20260805-173655
此外，编译目录和旁路二进制暂时也继续保留：
/root/nginx-build-1.30.4-openssl-3.5.7
/root/nginx-1.30.4-openssl-3.5.7
在新版本稳定运行一段时间以前，我暂时不会删除这些文件。
十八、这次升级过程中值得记录的几个经验
1. 不要直接在交互式 SSH Shell 中随意启用 set -e
set -e 对自动化脚本很有用，但如果直接在当前 SSH Shell 中启用，某个普通命令失败也可能导致整个远程 Shell 退出。
更稳妥的方式是将高风险操作放在独立子进程中：
bash <<'BASH'
set -euo pipefail
# 具体操作
BASH
这样即使子进程失败，当前 SSH 会话通常仍然保留。
2. 新二进制应先旁路测试
在覆盖生产二进制以前，应至少确认：
- 版本和 OpenSSL 版本正确。
- 编译参数和原版本保持一致。
- 新二进制可以加载当前生产配置。
- 配置语法和完整测试均成功。
- 新二进制已经计算并记录校验和。
3. 不要同时修改过多变量
这次继续保留 PCRE 8.45，没有顺便迁移到 PCRE2。
虽然 PCRE 8.45 以后也需要单独评估，但把 Nginx、OpenSSL、PCRE 和虚拟主机配置全部放在一次操作中修改，会显著增加故障定位难度。
4. 警告和错误需要区别处理
listen ... http2 弃用提示不会阻止 Nginx 启动，因此可以先完成二进制升级，再单独修改配置。
如果一看到警告就同时修改多个配置文件，反而会让升级过程变得更难验证。
5. curl 返回 000 不等于服务一定故障
000 不是服务器返回的 HTTP 状态码。
它通常意味着：
DNS 解析失败
连接失败
TLS 握手失败
请求超时
客户端主动中止
这次 www 和 admin 返回 000，只是因为完整响应时间略高于设置的 15 秒超时。
重新显示详细错误并适当增加超时时间以后，两个站点都正常返回了 200。
6. 自动化脚本要考虑服务器上的旧版 Python
这台服务器仍使用 Python 3.6.8。
在服务器运维脚本中，应避免直接使用：
list[str]
dict[str, str]
以及其他只有较新 Python 版本才支持的语法。
简单运维脚本优先兼容服务器现有运行环境，比追求新的类型注解更加重要。
十九、最终结果
本次升级最终完成了：
Nginx 1.24.0 → Nginx 1.30.4
OpenSSL 1.1.1t → OpenSSL 3.5.7
旧版 listen ... http2 写法 → 独立 http2 on 指令
最终确认：
- Nginx 配置测试成功。
- master 和 worker 进程正常。
- IPv4、IPv6 的 80 和 443 端口正常监听。
- 中文站、英文站和管理子域均返回
200。 - 三个公网站点均通过 HTTP/2 访问。
- 源站直连同样支持 HTTP/2。
- WordPress REST API、登录页面和管理后台正常。
- PHP-FPM 运行正常。
- 没有出现新的 Nginx 严重错误。
整个过程中虽然先后遇到了下载失败、两个 Perl 模块缺失、Python 3.6 语法不兼容，以及 curl 000 的误判，但因为始终坚持旁路编译、配置预检、完整备份和可回滚切换，最终没有造成不可恢复的问题。
至此，这台 Alibaba Cloud Linux 3 服务器上的 Nginx 与 OpenSSL 升级正式完成。
WordPress 网站维护、性能优化与博客运营咨询
本站已持续运营超过 10 年，累计发布 1000+ 篇原创技术文章，长期实践 WordPress 网站建设、CDN / Cloudflare 配置、缓存优化、Google SEO、广告变现和多语言网站运营。
如果你的 WordPress 网站遇到访问慢、缓存异常、插件冲突、广告不显示、SEO 基础结构混乱、CDN 配置不确定等问题，可以联系我做一次远程技术排查。
适合以下用户：
✅ 个人博客站长
✅ WordPress 网站运营者
✅ 独立开发者与内容创作者
✅ SaaS 产品官网运营团队
✅ 希望优化网站速度与稳定性的站点
服务内容：
✅ WordPress 速度优化
✅ Cloudflare / CDN / 缓存配置排查
✅ 插件冲突与页面异常排查
✅ AdSense 广告显示问题排查
✅ SEO 基础结构检查
✅ 博客运营与商业化咨询
如需了解方案或交流相关问题，请直接联系我，并注明：WordPress 维护咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复