先看结论：502 不是 WordPress 的错
502 Bad Gateway 的本质是：网关（Nginx、Apache、CDN 或负载均衡）把请求转给后端 PHP 处理，但后端没有返回合法响应。也就是说，问题几乎总在 PHP-FPM、PHP 进程崩溃，或两者之间的连接上，而不是 WordPress 主题或插件本身。所以排查方向应该从「服务器 → PHP-FPM → WordPress」倒着查，而不是先折腾插件。
第一步：确认 502 是偶发还是持续
先看错误日志，这是最直接的证据。Nginx 默认日志位置：
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/php*-fpm.log如果看到 connect() to unix:/run/php/php8.1-fpm.sock failed (11: Resource temporarily unavailable)，说明 PHP-FPM 连接池被打满；如果看到 upstream prematurely closed connection，多半是 PHP 进程被 OOM 杀掉或脚本执行超时。用 dmesg | grep -i oom 可以确认是否被系统内存杀手干掉。
第二步：按优先级排查四类常见原因
- PHP-FPM 进程池太小：并发一上来，
pm.max_children不够用，请求排队超时。先看pm.max_children当前值，再结合内存调整。每个 PHP 进程约占 30–80MB，用pm.max_children = 可用内存 / 单进程内存估算。 - 内存不足触发 OOM：小内存 VPS 上装了 WooCommerce 或大量插件最容易出现。加 swap 能缓解，但治本还是升级内存或限制插件数量。
- PHP 脚本超时：Nginx 的
fastcgi_read_timeout默认 60 秒，PHP 的max_execution_time默认 30 秒。备份、导入、爬虫抓取时容易触发。适当调大，但别无限大。 - 插件或主题死循环：如果 502 只在访问某个页面时出现，禁用插件逐个测试。用
wp plugin deactivate --all（WP-CLI）快速定位。
第三步：针对性的修复命令与配置
调整 PHP-FPM 池（以 PHP 8.1 为例，文件在 /etc/php/8.1/fpm/pool.d/www.conf）：
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500改完重启：
systemctl restart php8.1-fpm
systemctl restart nginxNginx 侧同步调大超时（在 location ~ .php$ 块内）：
fastcgi_read_timeout 120s;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;如果用了 Cloudflare 等 CDN，还要确认回源超时设置，否则源站恢复了 CDN 仍返回 502。临时可先「暂停 Cloudflare」验证。
第四步：长期预防比救火更重要
502 反复出现的站点，通常有三个共性：内存吃紧、插件臃肿、没有监控。建议做三件事：一是开启 swap（至少 1–2GB），二是用 wp plugin list --status=active 定期清理不用的插件，三是配置 Uptime 监控和日志告警。对于流量较大的站点，把 PHP-FPM 换成 pm = static 并固定进程数，比 dynamic 更稳定，代价是常驻内存略高。做完这些，502 基本能从「天天见」变成「偶尔见」。
