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 自己的日志：
-
/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。
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 导致的。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
