先定位：502 到底是谁返回的
502 Bad Gateway 不是 WordPress 自己抛出的错误，而是 Nginx、Apache 或 CDN 这类反向代理/网关在向上游（PHP-FPM、Apache、后端服务器）请求时，没拿到有效响应。所以排查顺序永远是：先看网关错误日志，再查上游服务状态，最后才怀疑 WordPress 插件或主题。不要一上来就禁用插件，那是在盲猜。
以 Nginx + PHP-FPM 为例，先执行：
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/php*-fpm.log
systemctl status php*-fpm nginx日志里常见关键字：connect() failed、upstream timed out、recv() failed、server reached pm.max_children。对应原因基本就锁定在下文几类。
原因一：PHP-FPM 进程耗尽或崩溃
这是 WordPress 站点 502 的头号原因。流量突增、插件死循环、爬虫高频请求都会把 pm.max_children 占满，新请求连不上 FPM，网关直接 502。日志里会出现 server reached pm.max_children setting。
处理办法是调大进程池并留出内存余量。先看单进程内存占用，再按服务器内存反推：
ps --no-headers -o rss -C php-fpm8.2 | awk '{sum+=$1} END {print sum/1024" MB"}'
# 编辑池配置，例如 /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500改完执行 systemctl reload php8.2-fpm。注意 max_children 不是越大越好，超过物理内存会导致 OOM，反而更不稳定。若 FPM 频繁崩溃，还要检查 dmesg -T | grep -i oom 是否发生内存溢出。
原因二：上游超时与 WordPress 自身卡死
如果日志是 upstream timed out，说明 FPM 进程还在，但处理太慢。常见于：数据库查询慢、插件调用外部 API 无超时、WP-Cron 阻塞、主题死循环。此时先临时关闭 WP-Cron 并排查慢查询：
# wp-config.php 中增加
define('DISABLE_WP_CRON', true);
# 查看 MySQL 慢查询
SHOW FULL PROCESSLIST;同时检查 Nginx 的 fastcgi_read_timeout 是否过短（默认 60s）。若业务确实需要长请求，可适度调至 120s，但根本仍是修掉慢查询或问题插件。用 curl -I 直接访问后端端口，能区分是网关层还是应用层问题。
原因三：配置错位与连接数限制
换服务器、改 PHP 版本后，Nginx 的 fastcgi_pass 仍指向旧 socket 路径，就会稳定 502。确认 socket 路径与 FPM 监听一致：
grep -r "listen" /etc/php/*/fpm/pool.d/www.conf
# Nginx 对应配置
fastcgi_pass unix:/run/php/php8.2-fpm.sock;另外检查 worker_connections、系统 ulimit -n、以及 CDN 回源超时。若用了 Cloudflare 等 CDN，源站响应超过 CDN 超时也会显示 502，此时要同时看 CDN 日志和源站日志，别只盯一头。
快速恢复与长期预防
- 紧急恢复：
systemctl restart php*-fpm先让站点活过来，再查根因。 - 开启 FPM slowlog：
request_slowlog_timeout = 5s，抓出拖慢的 PHP 脚本。 - 给 WordPress 加对象缓存（Redis），减少数据库压力。
- 监控 FPM 进程数与 502 率，设置告警，别等用户报障。
结论：502 是网关与上游之间的通信故障，按“看日志→查 FPM→查超时→查配置”的顺序走，绝大多数问题十分钟内能定位。盲目重装 WordPress 或禁用全部插件，既慢又容易掩盖真实原因。
