笙亿网络策划

PHP-FPM 出现 502 Bad Gateway 报错如何排查日志定位原因？

约 7 分钟读完 31 阅
文章导读
90% 以上的 502 错误与 PHP-FPM 进程异常有关，关键排查点在于 pm.max_children 配置（2GB 内存机器建议设为 20）和 request_terminate_timeout 超时参数（默认注释需手动设为 30s）。
📋 目录
  1. A 原因分析
  2. B 排查步骤一：确认 PHP-FPM 进程状态
  3. C 排查步骤二：核对监听配置与权限
  4. D 排查步骤三：调整进程与超时参数
  5. E 排查步骤四：查阅关键日志定位根因
  6. F 注意事项
  7. G 参考来源
A A

PHP-FPM 出现 502 Bad Gateway 报错如何排查日志定位原因？

核心结论：90% 以上的 502 错误与 PHP-FPM 进程异常有关，关键排查点在于 pm.max_children 配置（2GB 内存机器建议设为 20）和 request_terminate_timeout 超时参数（默认注释需手动设为 30s）。

原因分析

502 Bad Gateway 本质是 Nginx 作为反向代理无法从上游 PHP-FPM 获取有效 HTTP 响应。根据 2026 年 4 月 5 日收录的技术资料，当出现此错误时，Nginx 错误日志通常只记录"connect() to unix:/tmp/php-cgi-81.sock failed"这类结果性信息，而非根本原因。真正的问题隐藏在 PHP-FPM 自身的慢日志和错误日志中，常见诱因包括：子进程耗尽（日志显示"WARNING: [pool www] server reached pm.max_children setting"）、脚本执行超时（出现"Maximum execution time of X seconds exceeded"）、内存溢出（"Allowed memory size exhausted"）或 socket 权限不匹配导致 Nginx 用户无法读写 PHP-FPM 监听文件。

排查步骤一：确认 PHP-FPM 进程状态

登录服务器后首先执行systemctl status php-fpm-74（版本号按实际使用调整，如 php-fpm-80、php8.1-fpm），观察输出中是否包含"active (running)"字样。若显示"inactive (dead)"或"failed to start"，说明服务未运行。进一步执行ps aux | grep php-fpm确认存在 master 进程和若干 worker 进程，若仅剩 master 进程且无 worker，或完全无输出，说明 FPM 未能正常派生子进程。根据 2026 年 3 月 15 日的排查指南，此步骤可排除 60% 以上的 502 故障。

排查步骤二：核对监听配置与权限

打开 PHP-FPM 配置文件/www/server/php/74/etc/php-fpm.d/www.conf（路径中的 74 需按实际 PHP 版本调整），查找listen =行，确认其值为127.0.0.1:9000或/tmp/php-cgi-74.sock等具体地址。进入宝塔面板→网站→对应站点→设置→配置文件，搜索fastcgi_pass，确保其值与上一步获取的 listen 值严格一致。若使用 Unix socket，执行ls -l /tmp/php-cgi-74.sock确认属主为 nobody 或 www，且 Nginx 工作进程用户有读写权限，推荐权限设置为srw-rw----。2025 年 11 月 10 日的资料显示，配置不匹配导致的 502 占比约 25%。

PHP-FPM 出现 502 Bad Gateway 报错如何排查日志定位原因？

排查步骤三：调整进程与超时参数

PHP-FPM 子进程平均内存占用约 20-40MB（取决于扩展和代码），盲目加大 pm.max_children 可能导致内存爆满。保守调整示例（2GB 内存机器）：pm.max_children = 20、pm.start_servers = 5、pm.min_spare_servers = 3、pm.max_spare_servers = 8。关键三参数关系需满足：pm.start_servers ≤ pm.min_spare_servers ≤ pm.max_spare_servers ≤ pm.max_children。超时参数方面，request_terminate_timeout必须取消注释并设值（如 30s），且需≥Nginx 的fastcgi_read_timeout（默认 60 秒）。根据 2026 年 2 月 21 日的排查技巧，Nginx 配置中应设置：fastcgi_connect_timeout 30;、fastcgi_send_timeout 300;、fastcgi_read_timeout 300;。

排查步骤四：查阅关键日志定位根因

Nginx 的/www/wwwlogs/nginx_error.log通常只写连接失败结果，关键日志在 PHP-FPM 自己的慢日志和错误日志里。打开/www/server/php/{版本}/etc/php-fpm.conf确认 slowlog 和 error_log 路径已启用（如slowlog = /www/wwwlogs/php_slow.log）。用tail -f /www/wwwlogs/php_slow.log实时查看慢脚本，常见是 MySQL 死锁、file_get_contents 外部请求超时、递归没出口。PHP 错误日志在/www/wwwlogs/你的站点名_php_errors.log，检查是否有"Allowed memory size exhausted"或"Maximum execution time of X seconds exceeded"——这类错误若没被 display_errors=Off 屏蔽，往往就是 502 前兆。

注意事项

第一，重启 PHP-FPM 的正确姿势：宝塔面板点"重启"按钮底层执行的是systemctl restart php-fpm，但不保证旧连接清理干净。建议先手动平滑 reload：kill -USR2 $(cat /www/server/php/{版本}/var/run/php-fpm.pid)，若 reload 失败或子进程僵死，再用systemctl stop php-fpm && sleep 2 && systemctl start php-fpm，中间加 sleep 避免端口/sock 文件残留占用。第二，phpEnv 环境下日志集中放在~/.phpenv/logs/，比全局路径更易定位，但很多人忽略。第三，高并发下 pm = static 且 pm.max_children 过小会导致新请求排队超时，推荐 pm = dynamic 模式。第四，若 php-fpm 进程频繁 restart，error_log 里会出现"WARNING: [pool www] server reached pm.max_children setting"，说明子进程不够用了，但需先确认是否真缺资源再调整。

参考来源

来源：宝塔面板官方技术文档 - 网站出现 502 Bad Gateway 重启 PHP 服务与排查日志（2026 年 3 月 26 日）

PHP-FPM 出现 502 Bad Gateway 报错如何排查日志定位原因？

来源：Linux 运维技术社区 - 宝塔面板网站频繁出现 502 错误网关深度排查（2026 年 4 月 5 日）

来源：Nginx 与 PHP-FPM 配置教程 - 怎么解决 Nginx 502 Bad Gateway 错误（2025 年 11 月 10 日）

来源：PHP 高并发优化指南 - 502 错误快速解决与排查技巧（2026 年 2 月 21 日）