从你提供的日志来看，这个502错误的核心原因是PHP-FPM子进程触发了段错误（SIGSEGV）——进程崩溃后，Nginx与它的连接被重置，因此返回了502状态码。下面是一步步的排查和解决方案：

1. 定位段错误的具体根源（最关键） #

你已经在PHP-FPM配置里开启了rlimit_core = unlimited，接下来需要确保系统允许生成核心转储文件：

• 临时生效：执行ulimit -c unlimited（需要在PHP-FPM运行的用户环境下，或者重启PHP-FPM前执行）
• 永久生效：编辑/etc/security/limits.conf，添加：

  domain_live soft core unlimited
  domain_live hard core unlimited
  

然后重启PHP-FPM服务。等下一次进程崩溃后，你会在核心转储目录（通常是站点根目录或系统默认的/var/core/）找到类似core.xxxx的文件。

用GDB分析核心文件，定位崩溃点：

gdb /usr/sbin/php-fpm core.xxxx
# 输入bt查看调用栈
bt

这个调用栈会告诉你是哪个PHP扩展、函数或者Magento代码导致了内存访问越界。

2. 排查最近的代码/扩展变更 #

段错误大多和代码或扩展的bug有关，先回忆：

• 最近是否安装了新的Magento模块？尤其是和购物车（/checkout/cart/）相关的模块？
• 是否更新过PHP扩展（比如Redis、Xdebug、ImageMagick等）？
• 是否修改过Magento核心或自定义代码？

尝试禁用可疑模块，比如：

bin/magento module:disable Vendor_SuspectModule
bin/magento cache:flush

然后测试站点是否恢复正常，以此缩小排查范围。

3. 验证PHP与Magento的兼容性 #

确保你的PHP版本和Magento版本完全匹配：

• Magento 2.3.x 对应 PHP 7.2/7.3
• Magento 2.4.x 对应 PHP 7.4/8.1/8.2

另外，检查PHP扩展的兼容性：禁用非必要的扩展（比如Xdebug，调试时才需要），只保留Magento必需的扩展（如pdo_mysql、gd、redis、opcache等），逐个启用排查哪个扩展导致崩溃。

4. 检查Magento自身日志 #

除了Nginx和PHP-FPM日志，查看Magento的日志文件：

• var/log/exception.log：记录未捕获的异常
• var/log/system.log：记录系统级日志

重点查找和/checkout/cart/请求相关的错误，这些错误可能直接关联到进程崩溃的原因。

5. 调整PHP-FPM配置（辅助优化） #

虽然这不是根本原因，但不合理的进程配置可能加剧问题：

• 你当前的pm.max_children = 150，如果服务器内存不足，可能导致进程内存溢出触发崩溃。可以根据服务器内存计算合理值：比如每个PHP-FPM进程占用~200MB，8GB内存的话，pm.max_children建议设为30-40。
• 降低pm.max_requests（比如从500改为200），避免进程长时间运行积累内存问题。

内容的提问来源于stack exchange，提问作者Jaimin