502错误主因是PHP-FPM无响应，需先用ps aux | grep php-fpm确认进程状态，再查systemctl status php-fpm-xx，重点配置request_terminate_timeout、request_slowlog_timeout和pm.process_idle_timeout，并检查慢日志、错误日志及OOM Killer日志。
502错误大概率是PHP-FPM没响应，先看进程还在不在
宝塔面板显示502，绝大多数时候不是Nginx挂了，而是它背后那个php-fpm进程根本没在跑，或者卡死了。别急着重启面板，先登服务器用命令确认：
ps aux | grep php-fpm —— 如果只看到一条带grep的行，说明php-fpm主进程已退出；如果看到多个php-fpm: pool www子进程但数量极少（比如只剩1–2个），可能是被pm.max_children限制死或因脚本阻塞无法回收。
进一步验证：执行systemctl status php-fpm-74（版本号按你实际用的改，如php-fpm-80），重点看Active:是否为active (running)，以及Process:后有没有报failed或core dumped。
PHP脚本执行超时导致FPM子进程僵死，关键参数就三个
即使php-fpm进程活着，只要某个请求卡住不返回，就会占住一个worker，积压多了就全堵死，Nginx等不到响应就回502。核心控制点在www.conf里：
立即学习“PHP免费学习笔记（深入）”；
-
request_terminate_timeout：强制杀掉运行超时的请求（单位秒），宝塔默认注释掉，**必须取消注释并设值**，例如request_terminate_timeout = 30s -
request_slowlog_timeout：记录慢请求日志（需配合slowlog路径），设为10s能帮你定位哪段PHP代码拖慢了整个池 -
pm.process_idle_timeout：空闲worker存活时间（如10s），避免长期空转浪费资源，也减少僵尸进程残留可能
改完别忘了systemctl reload php-fpm-74，reload比restart更安全，不会中断正在处理的请求。
查慢脚本不能只盯access.log，得翻php-fpm慢日志和错误日志
宝塔界面里“网站”→“日志”看到的access.log只记HTTP状态，看不出PHP内部卡在哪。真问题藏在这两个地方：
- 慢日志路径通常是
/www/wwwlogs/php_slow.log（由www.conf中slowlog配置项指定），里面会精确到毫秒，标出超时脚本的完整路径、调用栈和耗时 - PHP错误日志在
/www/wwwlogs/你的站点名_php_errors.log，注意检查是否有Allowed memory size exhausted或Maximum execution time of X seconds exceeded——这类错误若没被display_errors=Off屏蔽，往往就是502前兆
常见诱因：WordPress插件里写了死循环、未加索引的MySQL SELECT *查几万行、file_get_contents()去请求一个无响应的第三方API且没设timeout。
内存不足会静默杀掉php-fpm子进程，free -h和dmesg都要看
当服务器物理内存吃紧，Linux内核OOM Killer可能直接干掉占用内存最多的php-fpm子进程，现象是ps突然看不到worker，systemctl status显示start-limit-hit，但日志里找不到明显错误。
立即执行两步排查：
-
free -h：看available是否长期低于512MB（尤其小内存VPS） -
dmesg -T | grep -i "killed process"：如果有输出，十有八九是OOM Killer动的手，末尾会写明被杀进程名（如php-fpm: pool www）
临时缓解可调低pm.max_children（比如从50降到20），长期得优化PHP内存使用或升级配置。别信“加swap就能解决”，swap只是延缓OOM，反而会让FPM响应更慢，加剧502。
