502 Bad Gateway 的根本原因是 PHP-FPM 故障而非 Nginx 配置错误；应优先检查 php-fpm 服务状态、worker 进程是否存在、错误日志中的 segfault 或内存耗尽等关键线索，确认其正常运行后再排查 Nginx。
先查 PHP-FPM，不是 Nginx。
502 Bad Gateway 的本质是 Nginx 作为代理，收不到 PHP-FPM 的有效响应。但 Nginx 本身极少“主动出错”，它只是忠实地报告上游失联或超时。真正卡住、崩溃、拒绝响应的，几乎总是 PHP-FPM 或其承载的 Laravel 进程。
为什么优先看 PHP-FPM 状态
常见错误现象：页面全站 502，但 curl -I http://localhost 能通，nginx -t 配置无误，Nginx 日志里反复出现 upstream timed out 或 connection refused —— 这些全是“症状”，不是病因。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 运行
systemctl status php-fpm（或php-fpm7.4等具体服务名），确认状态是active (running)；若为inactive或failed，直接跳过 Nginx 检查 - 用
ps aux | grep php-fpm看 worker 进程数是否为 0，或只剩 master 进程 —— 表明子进程已全部退出 - 检查
/var/log/php-fpm/www-error.log（路径依配置而异），重点搜segfault、Allowed memory size exhausted、Connection reset by peer - 如果 Laravel 使用了
opcache或apcu，临时禁用（注释extension=opcache.so后重启 PHP-FPM），排除缓存模块引发的崩溃
什么时候才该怀疑 Nginx 配置
只有在确认 PHP-FPM 正常运行、且能独立执行简单脚本（如 echo "<?php echo 'ok';" > /tmp/test.php && php /tmp/test.php）的前提下，再排查 Nginx。
典型 Nginx 问题场景：
-
fastcgi_pass指向错误地址：比如配成127.0.0.1:9001，但 PHP-FPM 实际监听的是unix:/var/run/php-fpm.sock -
fastcgi_read_timeout过短（如设为 5s），而 Laravel 某个接口实际耗时 8s，Nginx 就会提前断开并返回 502 - 使用 Unix socket 时权限不对：
nginx用户无法读写/var/run/php-fpm.sock（常见于 SELinux 或文件属组错误） -
client_max_body_size或fastcgi_buffer_size过小，上传大文件或返回长 JSON 时触发截断，PHP-FPM 认为响应不完整而关闭连接
快速交叉验证法：绕过 Nginx 直连 PHP-FPM
这不是生产操作，而是定位关键链路的最快方式：
- 临时启用 PHP 内置服务器：
cd /path/to/laravel && php -S localhost:8000 -t public/ - 浏览器访问
http://localhost:8000—— 若能打开，说明 Laravel 代码和 PHP 环境本身没问题；若报错（如Class not found），问题就在应用层或依赖加载 - 若内置服务器也崩（如直接退出、无响应），立刻检查
storage/logs/laravel.log和 PHP 错误日志，大概率是环境扩展缺失（如mbstring）、.env 配置错误或数据库连接失败导致启动阶段异常退出
最易被忽略的一点：Laravel 在 AppServiceProvider::boot() 或配置加载阶段抛出未捕获异常，会导致整个请求生命周期在 PHP-FPM worker 中静默终止 —— Nginx 看不到任何响应，只能报 502。这种错误不会出现在 Laravel 日志里，必须看 PHP-FPM 的 error_log 或用 strace 跟踪 worker 进程退出瞬间的系统调用。
