502 Bad Gateway真凶大概率是PHP-FPM挂了：可能是进程死亡、监听地址不匹配、worker崩溃或卡死、phpMyAdmin长耗时操作触发超时，需逐层排查状态、配置、日志与系统调用。
502 Bad Gateway 真凶大概率是 PHP-FPM 挂了
看到 502 bad gateway，nginx 已经把请求转给 php-fpm 了，但没收到响应——不是 nginx 配置错，也不是 phpmyadmin 本身崩了，而是后端的 php-fpm 进程根本没应答。最直接验证方式：执行 systemctl status php-fpm 或 service php7.4-fpm status（版本号按实际替换），看是否显示 inactive (dead) 或反复 restart。
检查 PHP-FPM 是否监听了正确地址和端口
nginx 的 fastcgi_pass 必须和 PHP-FPM 实际监听位置严格一致。常见错配有三种：
-
fastcgi_pass 127.0.0.1:9000，但 PHP-FPM 配置里是listen = /run/php/php8.1-fpm.sock（走 socket） -
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock，但 socket 文件权限不对（如 nginx 用户无法读取）或路径拼错 - PHP-FPM 启用了
listen.allowed_clients，但 nginx 不在白名单里（默认只允 127.0.0.1，IPv6 地址可能被拒）
查 PHP-FPM 主配置：运行 php-fpm -t 确认语法无误，再用 grep "^listen" /etc/php/*/fpm/pool.d/www.conf 看真实监听值；用 ls -l /var/run/php/ 或 netstat -tlnp | grep :9000 验证进程是否真在听。
PHP-FPM worker 崩溃或卡死的典型迹象
进程活着，但不处理请求，表现为间歇性 502、响应超时、php-fpm 日志里频繁出现 WARNING: [pool www] child 12345 exited on signal Segmentation fault (11) 或 WARNING: [pool www] server reached pm.max_children setting。
-
pm.max_children设太小，高并发时新请求排队超时，nginx 主动断开 → 表现为 502 -
request_terminate_timeout或request_slowlog_timeout触发后，worker 被杀但未及时重启，导致空闲 worker 数归零 - 某个 phpMyAdmin 请求触发扩展崩溃（如
gd处理损坏图片、mbstring编码异常），整个 worker 进程退出
临时缓解可调大 pm.max_children 并启用 pm.status_path，用 curl http://localhost/status?full 查看 worker 状态；长期要结合 slowlog 和 dmesg | tail 看内核级 segfault。
立即学习“PHP免费学习笔记（深入）”；
phpMyAdmin 自身配置引发的隐性超时
phpMyAdmin 不是直接导致 502 的原因，但它某些操作会触发长耗时 PHP 执行（如导入大 SQL、浏览超宽表、启用 $cfg['Servers'][$i]['pdoreconnect'] = true），进而压垮 PHP-FPM worker。重点检查：
-
php.ini中max_execution_time是否远小于 nginx 的fastcgi_read_timeout（比如前者 30 秒，后者 60 秒，PHP 先超时退出，nginx 收不到完整响应 → 502） - phpMyAdmin 的
config.inc.php里是否启用了$cfg['ExecTimeLimit'] = 0，却没同步调高max_execution_time - 是否误配了
$cfg['Servers'][$i]['host']指向一个不可达数据库，导致连接卡在 TCP 握手，PHP 线程挂住
这类问题不会报错日志，但 strace -p $(pgrep php-fpm) 可看到 worker 卡在 connect() 或 recvfrom() 系统调用上。
真正麻烦的是多种因素叠加：PHP-FPM worker 数刚好卡在临界点，某个慢查询又拖住一个 worker，剩余 worker 全忙，新请求全进队列，超时后 nginx 报 502。这时候光看日志容易漏掉“排队”这个中间态。
