朋友遇到了困境
PHP 近期推出了 8.4.21 版本，修补了一系列的安全漏洞。基于安全考虑，笔者有一个朋友在昨天下午把他公司网站的 PHP 版本从 8.4.17 升级到了 8.4.21 版本，但升级之后还没来得及测试，他就有事外出了，等到几个小时之后办完事情回来，重新访问他公司网站，发现提示502错误，才知道他遇上了一些麻烦。由于不太熟悉服务器的一些配置，他找来笔者帮一帮忙。
分析和验证测试
来到他公司，进入他的服务器查看了 nginx 日志，其异常日志中出现了大量类似于下面这样的记录：
2026/05/29 21:50:08 [error] 2479#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: www.abc.com, request: ＂GET / HTTP/2.0＂, upstream: ＂fastcgi://unix:/xxx/php/php-cgi-84.sock:＂, host: ＂www.abc.com＂上面所遇到的recv() failed (104: Connection reset by peer) 错误，其根本原因是 PHP-FPM 的子进程因为 段错误 (Segmentation Fault) 而崩溃了。为了验证跟服务器有关系，我在他们公司本地搭建了两个测试系统，一个是与他们服务器的软件环境基本一致（操作系统为Ubuntu Server 24.04），另一个则是把操作系统更换为 Rocky Linux 9.7，但 nginx、php 等应用软件的环境和其它两个Ubuntu Server系统一致。顺便说一下，他们所有相关的应用程序的部署，包括服务器的，都是使用宝塔面板进行部署的。最后，把网站的程序和数据库都复制一份到两个测试环境中。
测试结果显示，在使用浏览器打开里面的 Ubuntu Server 测试站点的时候，同样出现了502错误，也产生跟上面类似的nginx异常日志记录，而 Rocky Linux 环境下的测试站点则没有出现异常情况，可以正常访问。基于此测试，笔者认为该扩展可能与 Ubuntu Server 24.04特定的 PHP 8.4.21 编译版本或系统库不兼容。
如何找出“肇事”的PHP扩展？
首先，我们需要检查系统日志，锁定崩溃的扩展。PHP-FPM 崩溃时，操作系统内核会记录下详细信息。这是解决问题的金钥匙。可以在终端中执行以下命令：
sudo dmesg | grep -i "php-fpm.*segfault"执行上述命令之后，朋友的服务器就出现以下的提示：
[ 781.234875] php-fpm[1195]: segfault at 749d509b6ffc ip 000074995288bbd6 sp 00007ffe860cd1a0 error 4 in opcache.so[749952825000+ef000] likely on CPU 1 (core 1, socket 0)上述日志显示，opcache.so 这个 PHP 扩展导致了的段错误崩溃。随后，笔者在php.ini中把 opcache 禁用了(注释相关设置，参考下面）：
;zend_extension=opcache.so
;opcache.enable=1随后保存配置并且重启 PHP 服务，再测试一下访问朋友公司网站，结果就是可以正常访问了。
最后的建议
笔者猜测，宝塔面板提供的 PHP 8.4.21 版本，在使用 opcache 扩展的时候，可能会与 Ubuntu Server 24.04 的某些组件存在兼容问题，因此出现了像朋友公司这样的情况，而在 Rocky Linux 9.7 环境下则没有这种问题，在 Ubuntu Server 24.04 下使用较老的 PHP 8.4.17 版本，甚至是使用8.3、8.5 的最新版也没有问题。因此，如果需要在 Ubuntu Server 24.04 下使用 PHP 8.4 系列的，暂时不要使用8.4.21版本，等待官方发布8.4.22或更高版本，在测试环境中测试通过之后再在生产环境中更新，不要像笔者朋友那样鲁莽。如果对安全有要求，需要及时修补软件的安全漏洞的，且在PHP程序兼容的情况下，可以考虑使用 PHP 8.3 系列或者 PHP 8.5系列的最新版。
