如果 WordPress 网站的 502 修完又复发，单次排查往往不够。真正有用的线索，是把访问日志、PHP-FPM（PHP 进程管理器）慢日志、数据库慢查询和系统资源曲线放到同一条时间线上，解决“到底是哪一类请求先变慢”的问题。本文不重复泛泛讲 502 的链路概念，而是教你用时间点反推慢请求、连接耗尽和配置超时之间的先后关系，避免每次都靠重启服务临时止血。对外贸站、企业官网和 WooCommerce 站点来说，复发型 502 会持续影响询盘、下单和广告转化，因此排查时要保留证据，而不是凭感觉修改配置。
先建立 502 复发时间线
WordPress 的一次动态页面请求，大致会经过浏览器、Web 服务器、PHP-FPM（PHP 进程管理器）、WordPress 程序、MySQL 或 MariaDB 数据库。如果前端看到 502 Bad Gateway，含义通常是 Web 服务器作为网关，没能从后端 PHP 进程拿到有效响应。遇到反复出现的 502，第一步不是立刻怀疑插件，而是先把错误发生的分钟级时间点固定下来。
可以用 3 个最小测试缩小范围：访问首页、访问一个静态图片文件、访问后台登录页。如果静态图片能稳定打开，而首页和后台间歇 502，说明 Nginx 或 Apache 本身仍能提供静态资源，重点应转向 PHP-FPM（PHP 进程管理器）和数据库。把每次测试的状态码、响应时间和系统时间记录下来，后面才能判断是 PHP worker 先耗尽，还是数据库慢查询先堆积。
常见的第一轮命令如下，执行后重点看日志时间点是否与用户反馈一致：
systemctl status nginx php-fpm mysqld --no-pager
journalctl -u php-fpm --since "30 minutes ago" --no-pager
tail -n 100 /var/log/nginx/error.log
如果使用 Apache，可把 Nginx 日志替换为 Apache 错误日志。站点部署在 WordPress主机 或虚拟主机环境时，可能无法直接执行 systemctl，此时应优先查看控制面板中的错误日志、PHP 错误日志和资源使用曲线。更多 WordPress 运维内容也可以参考 WordPress 教程栏目。
检查 PHP-FPM：进程池是否已经耗尽
当 502 只影响动态页面时，PHP-FPM（PHP 进程管理器）通常是第一排查对象。它负责启动 PHP worker 来处理 WordPress 请求；如果 worker 全部被慢请求占满，Web 服务器等待超时后就会返回 502。此时重启 PHP-FPM（PHP 进程管理器）可能短暂恢复，但如果不查清 worker 为什么耗尽，几分钟或几个小时后还会复发。
先查看 PHP-FPM（PHP 进程管理器）日志中是否出现类似 “server reached pm.max_children setting” 的提示。这个信息说明最大子进程数已经达到上限，新请求只能排队等待。继续检查当前进程数和内存占用，避免把参数调得过大导致系统交换分区被打满。
grep -i "max_children\|slow\|timeout" /var/log/php-fpm/www-error.log | tail -n 50
ps -ylC php-fpm --sort:rss | tail -n 10
free -m
如果单个 PHP 进程平均占用 80 MB，可用内存预留给系统和数据库后还有 1.6 GB，那么 pm.max_children 粗略上限约为 20。这个数字不是越大越好；设置为 80 可能让排队变少，但也可能把内存压垮，最终从 502 变成整机卡死。更稳妥的做法是把慢日志打开，找到真正拖慢 worker 的插件、外部接口或数据库查询。
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
request_terminate_timeout = 60s
修改配置后，先在低峰期 reload，再观察 15-30 分钟。若慢日志反复指向同一个插件目录或主题函数，就应在测试环境复现，而不是直接在线上删除插件。关于主机侧性能瓶颈的基础判断，可延伸阅读 网站优化指南。
排查数据库连接：不是所有 502 都是 PHP 参数问题
PHP-FPM（PHP 进程管理器）worker 被占满，有时只是表象。WordPress 每个动态请求都可能访问数据库，如果数据库连接慢、锁等待严重或连接数耗尽，PHP 进程会一直等数据库响应，最终把进程池拖满。因此，在看到 PHP-FPM（PHP 进程管理器）告警后，还要同步检查数据库。
先确认连接数和慢查询。下面命令适合具备数据库权限的服务器环境；如果是托管环境，可在控制面板或工单中请求相同维度的数据：
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';
SHOW FULL PROCESSLIST;
SHOW GLOBAL STATUS LIKE 'Slow_queries';
如果 Threads_connected 长时间接近 max_connections，或者 SHOW FULL PROCESSLIST 中大量查询停留在 Sending data、Locked、Waiting for table metadata lock，说明瓶颈已经转移到数据库层。常见诱因包括未优化的搜索插件、后台批量导入任务、统计插件写入过多，以及 WooCommerce 订单表在高峰期产生大量查询。
在 MySQL 或 MariaDB 中开启慢查询日志时，可以先设定较保守的阈值，例如 2 秒，而不是一开始就记录所有查询：
slow_query_log = 1
long_query_time = 2
slow_query_log_file = /var/log/mysql/slow.log
拿到慢查询后，再结合时间点判断是否与 502 峰值重合。若慢查询集中在某个插件表，可以先清理历史数据、添加必要索引或调整插件功能；若查询来自核心表，则要进一步检查对象缓存、页面缓存和数据库参数。对于增长较快的站点，选择资源隔离更清晰的 VPS（虚拟专用服务器）主机 或独立数据库环境，会比反复调小插件功能更可控。
把超时参数放在同一张图里看
很多 502 难排，是因为 Nginx、PHP-FPM（PHP 进程管理器）、PHP 脚本和数据库的超时时间不一致。例如 Web 服务器等待 30 秒，PHP 脚本允许执行 120 秒，数据库查询又可能卡在锁等待中。结果是前端已经返回 502，后端进程却还在继续占用资源，新的请求进来后堆积更快。
建议把关键参数放在同一份排查记录里，至少包括：
- Web 服务器：
fastcgi_read_timeout或代理超时，记录当前值和错误日志时间点。 - PHP-FPM（PHP 进程管理器）：
pm.max_children、request_terminate_timeout、慢日志阈值。 - PHP：
max_execution_time、memory_limit，同时记录单个 PHP worker 的 RSS 内存。 - 数据库：
max_connections、慢查询阈值、连接数峰值和锁等待样本。
这组参数的目标不是全部调大，而是让失败更可控。比如 request_terminate_timeout 设置为 60 秒，Web 服务器等待 65 秒，PHP max_execution_time 也接近 60 秒，至少可以减少“前端已失败、后端还占坑”的情况。若某个导入任务确实需要更长时间，应放到 CLI 或队列任务里运行，不要让它占用前台 PHP worker。
这里也要看服务器资源类型。共享环境适合流量较稳定的小站；当站点有促销活动、广告投放或会员系统时，建议提前评估 CPU、内存和 I/O 峰值。你可以从 服务器相关文章 了解更多资源规划思路，避免只在故障发生后被动扩容。
修复后一定要做回归验证
改完配置不等于问题解决。502 的修复需要用相同路径复测，确认错误率、响应时间和资源占用都回到可接受范围。最简单的办法，是选取 3 类页面：一个静态资源、一个普通文章页、一个后台或购物车相关页面，分别连续请求 20-50 次，看是否仍出现 502 或明显超时。
可以用下面的命令做轻量验证：
for i in {1..30}; do curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://example.com/; done
如果 30 次请求中仍有 502，说明问题还没闭环，需要继续回到日志时间点排查。若状态码稳定为 200，但 time_total 偶尔超过 5 秒，也要继续观察慢日志，因为这可能是下一轮 502 的前兆。对业务站来说，建议至少保留 24 小时的观察窗口，覆盖一次访问高峰。
最后，把本次排查记录沉淀下来：故障时间、错误日志、调整前后的配置、慢查询样本、验证命令和结果。下次出现类似问题时，团队能直接从已验证路径开始，而不是重复猜测。如果你需要更稳定的 WordPress（内容管理系统）运行环境，可以考虑结合缓存、备份、监控、SSL（安全传输协议）证书状态和合适的主机资源做整体优化；Hostease 的 WordPress（内容管理系统）相关方案适合需要中文支持和主机侧协助的站点，但具体配置仍应根据流量峰值、插件数量和数据库规模来评估。
