跳转到主内容
趣航编程网 - 趣学编程,启航技术之路!

如何排查宝塔面板Nginx 502错误_查看日志定位php-fpm超时点

502错误核心线索是Nginx日志中“upstream prematurely closed connection”或“upstream timed out”,需结合php-fpm慢日志、错误日志及fastcgi_read_timeout与request_terminate_timeout匹配排查。 直接看
/var/log/nginx/error.log
里的 upstream 错误行 502 出现时,Nginx 日志里几乎必然带
upstream prematurely closed connection
或
upstream timed out
。这两条是核心线索,不是干扰项——前者说明 php -fpm 进程主动断开了连接(大概率是执行超时或崩溃),后者说明 Nginx 等不到响应就放弃了(配置的 timeout 太短)。 执行命令快速定位:
tail -n 100 /var/log/nginx/error.log | grep "upstream\|502"
重点盯住时间戳紧邻 502 请求的那几行,尤其是带
php-fpm
、
fastcgi
或具体 socket 路径(如
unix:/tmp/php-cgi.sock
)的记录。 对比查
php-fpm
的慢日志和错误日志 Nginx 日志只告诉你“上游挂了”,但不知道为什么挂。必须同步检查 php-fpm 自己的日志: 立即学习 “ PHP免费学习笔记(深入) ”;
/var/log/php-fpm/www-error.log
(错误类退出、致命报错)
/var/log/php-fpm/www-slow.log
(执行超过
request_slowlog_timeout
的脚本) 如果 slow log 有内容,说明问题出在某个 PHP 脚本执行太久;如果 error log 里有
child exited on signal Segmentation fault
或
Allowed memory size exhausted
,那就是内存或段错误导致进程崩了。 确认 slow log 是否启用:
grep "slowlog\|request_slowlog_timeout" /www/server/php/74/etc/php-fpm.d/www.conf
若没开,临时加上这两行再重载:
slowlog = /var/log/php-fpm/www-slow.log
,
request_slowlog_timeout = 5s
。 PHP 8.5.5 PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑,通过深度错误修复、底层性能微调以及安全加固,旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范,不包含破坏性变更。 下载
fastcgi_read_timeout
和
request_terminate_timeout
必须匹配 这是最常被忽略的超时耦合点:Nginx 等 php-fpm 响应的时间,不能比 php-fpm 自己允许单个请求运行的时间还长,否则 Nginx 在 php-fpm 杀掉请求前就先报 502 了。 检查并确保: Nginx 配置中 location 块内有
fastcgi_read_timeout 300;
(单位秒) PHP-FPM 配置
/www/server/php/74/etc/php-fpm.d/www.conf
中有
request_terminate_timeout = 300s
PHP 自身的
max_execution_time = 300
(在
/www/server/php/74/etc/php.ini
) 三者取最小值生效。如果只调高 Nginx 的
fastcgi_read_timeout
,但 php-fpm 仍设为 60s,那第 61 秒 php-fpm 就会杀掉进程,Nginx 收到 RST 后照样记一条
upstream prematurely closed
。 用
strace
抓住 php-fpm 子进程卡在哪一秒 当慢日志没输出、error 日志也干净,但 502 持续发生,说明请求可能卡在系统调用层面(比如 DNS 解析阻塞、curl 外部接口 hang 住、数据库连接池耗尽)。这时需要抓现场: 先找到一个正在跑的 php-fpm worker 进程 ID:
ps aux | grep "php-fpm: pool www" | head -n 1 | awk '{print $2}'
然后用
strace
跟它 10 秒:
strace -p PID -T -tt -e trace=network,connect,sendto,recvfrom -s 100 -o /tmp/strace.log
复现一次 502 请求,立刻去看
/tmp/strace.log
最后几行——如果看到
connect(…)
卡住超过 5 秒,基本就是某次外部 HTTP 或 MySQL 连接没设 timeout 导致的。

相关文章