502错误本质是nginx成功转发请求但未收到php-fpm合法响应，根因集中于连接链路：php-fpm未运行、监听地址与fastcgi_pass不匹配、socket权限不足、超时参数错配（如request_terminate_timeout
502 错误在 Nginx 代理 PHP-FPM 场景下，本质是“传话失败”——Nginx 把请求转出去了，但没收到合法响应。问题几乎从不发生在 Nginx 本身，而集中在它与 PHP-FPM 的连接链路上。排查关键不是猜，而是按通信路径逐层验证：PHP-FPM 是否活着 → 是否能被 Nginx 访问 → 是否来得及响应。
确认 PHP-FPM 进程真实运行且监听正确
很多 502 直接源于 PHP-FPM 根本没起来，或监听地址和 Nginx 配置对不上。
- 运行 sudo systemctl status php*-fpm（如
php8.2-fpm），确认状态为active (running)- 查实际监听配置：sudo cat /etc/php/*/fpm/pool.d/www.conf | grep listen，看是
unix:/run/php/php8.2-fpm.sock还是127.0.0.1:9000- 检查 Nginx 的
fastcgi_pass值是否完全一致——路径多一个斜杠、端口写成9001、socket 路径版本错（php8.1vsphp8.2）都会静默 502验证 Nginx worker 对 socket 文件有读写权限
即使路径完全匹配，权限不对也会导致连接被拒绝，日志里常显示
Connection refused或No such file or directory（注意：后者有时是权限问题而非文件不存在）。
- 查 socket 文件归属：ls -l /run/php/*.sock，关注 owner 和 group（如
www-data:www-data）- 查 Nginx 运行用户：grep "user" /etc/nginx/nginx.conf（常见为
www-data或nginx）- 若不一致，在 PHP-FPM 的 pool 配置中补全三行：
listen.owner = www-datalisten.group = www-datalisten.mode = 0660
然后重启：sudo systemctl restart php8.2-fpm nginx检查超时设置是否被 Xdebug 或复杂脚本触发
Xdebug 启用后单步调试会显著拉长执行时间，极易撞上 PHP-FPM 的强制终止阈值，导致 Nginx 收到 “Connection reset by peer”，最终返回 502。
- 查 PHP-FPM 配置：sudo cat /etc/php/*/fpm/pool.d/www.conf | grep request_terminate_timeout
- 若值为
10s或30s，调试时极大概率超限；临时调高至300（5 分钟）：request_terminate_timeout = 300- 同时检查 Nginx 的 FastCGI 超时参数是否合理：
fastcgi_connect_timeout 300;fastcgi_send_timeout 300;fastcgi_read_timeout 300;
这三项需 ≥ PHP-FPM 的request_terminate_timeout盯紧错误日志里的具体线索
Nginx 错误日志（
/var/log/nginx/error.log）是唯一可靠信源，不同报错指向不同根因：
connect() to unix:/run/php/php8.2-fpm.sock failed (111: Connection refused)→ PHP-FPM 没运行或监听地址错connect() to unix:/run/php/php8.2-fpm.sock failed (13: Permission denied)→ 权限不匹配upstream timed out (110: Connection timed out) while reading response header→ 脚本执行太慢，超时参数需调大recv() failed (104: Connection reset by peer)→ PHP-FPM 主动 kill 掉 worker，重点查request_terminate_timeout
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
