502错误本质是Nginx反向代理无法从PHP-FPM获取有效响应，主因是PHP-FPM子进程耗尽、超时或socket中断；需优先查Nginx错误日志，核对pm.max_children、request_terminate_timeout及fastcgi_*超时参数匹配性，并用FPM状态页与strace定位僵死进程。
502错误本质是反向代理层收不到上游响应
PHP应用本身没挂，但Nginx返回了502 Bad Gateway，说明Nginx作为反向代理，无法从PHP-FPM（或其它后端）拿到有效HTTP响应。常见于高并发下PHP-FPM子进程耗尽、超时、崩溃或socket通信中断。
排查优先看Nginx错误日志：/var/log/nginx/error.log，搜索upstream timed out、no live upstreams、connect() failed等关键词，比盲调PHP更高效。
检查PHP-FPM的max_children和request_terminate_timeout
高并发下502最常因PHP-FPM子进程被占满或单个请求执行超时导致。需核对以下配置是否匹配实际负载：
-
pm.max_children：不能只看CPU核数，要结合平均内存占用估算。例如每个PHP进程占80MB，服务器有2GB可用内存，max_children设为20较稳妥，而非盲目设成50 -
pm.start_servers/pm.min_spare_servers：避免冷启动时突发流量直接打满，建议设为max_children的60%~70% -
request_terminate_timeout：若PHP脚本偶发卡死（如cURL无超时、DB锁等待），此值应略大于Nginx的fastcgi_read_timeout，否则Nginx先断连，FPM进程仍僵死
Nginx fastcgi_* 超时参数必须与PHP-FPM对齐
错配超时参数是502高频诱因。Nginx默认fastcgi_read_timeout仅60秒，而PHP-FPM的request_terminate_timeout可能设为0（不限制），结果Nginx等不及就返回502。
立即学习“PHP免费学习笔记（深入）”；
关键三连配（写在Nginx server或location块中）：
fastcgi_connect_timeout 30; fastcgi_send_timeout 300; fastcgi_read_timeout 300;
对应PHP-FPM pool配置中必须满足：request_terminate_timeout >= fastcgi_read_timeout，否则必然丢连接。
用strace和php-fpm status快速定位僵死进程
当502偶发且日志无明确线索，直接观察PHP-FPM工作进程状态比反复重启更省时间：
- 启用FPM状态页：在pool配置中加
pm.status_path = /status，Nginx里配好location /status转发 - 访问
http://yoursite/status?full，重点看state: Idle数量是否持续为0，以及slow requests是否增长 - 挑一个长时间
State: Running的进程PID，用strace -p PID -e trace=network,io看它卡在哪个系统调用（比如recvfrom卡住说明在等下游服务响应）
真正棘手的是PHP内部死循环或扩展级阻塞（如APCu缓存锁竞争），这类问题不会出现在FPM状态页里，得靠gdb attach后看PHP调用栈——但90%的线上502，查完前三步就定位到了。
