TL;DR：WordPress 搬家刚结束，域名一切换，前台迎面一排 502 Bad Gateway——数据都在、后台能登，就是页面打不开。这篇帮你解决这类问题的排查链：先用 Nginx 错误日志分清”连接失败”和”upstream 超时”，再做 PHP-FPM 进程池调优与超时参数对齐，最后核对数据库、DNS（域名解析服务）与缓存三个迁移检查点。
前言（502 到底断在哪一环）
先弄清动态页面在服务器上的旅程：请求先到 Nginx，静态文件直接返回，PHP 页面转发给 PHP-FPM 进程池执行，结果再送回浏览器；两者靠 socket 或 TCP 端口通信。所谓 502 Bad Gateway，含义很具体：Nginx 作为网关，没从上游（upstream，即 PHP-FPM）拿到有效响应——要么对方没应答，要么应答太慢。搬家高发 502，正因为迁移集中了所有诱因：PHP 版本不同导致 socket 路径变化、配置路径没同步、内存规格差异造成进程数不足、数据库连接还指向旧主机。
第一步：让错误日志说话
猜测是排查的大敌，日志才是事实。出现 502 先看 Nginx 错误日志：
tail -n 100 /var/log/nginx/error.log
日志里会出现两类关键信息。第一类形如 connect() to unix:/run/php/php8.1-fpm.sock failed，是连接失败——Nginx 找不到 PHP-FPM 的 socket 文件，说明服务未启动或监听路径不匹配。第二类形如 upstream timed out (110: Connection timed out) while reading response header，才是 upstream 超时——PHP-FPM 在运行，但执行太慢，Nginx 默认只等 60 秒就放弃了。前者查服务与路径，后者查性能与资源；搬家前从未超时、搬家后频繁超时，通常指向第二类。想系统规划迁移流程，可参考WordPress 网站迁移指南。
第二步：连接失败型 502，三个检查当场解决
面对 No such file or directory，按顺序做三件事。先确认服务状态：systemctl status php8.1-fpm，没启动就用 enable –now 把它拉起来并设为开机自启。再核对监听地址：/etc/php/8.1/fpm/pool.d/www.conf 中 listen = 一行，要与 Nginx 配置里 fastcgi_pass 指向的路径逐字符比对——旧服务器 PHP 7.4、新服务器 8.1，socket 路径版本号不同是最常见根因。最后确认 socket 属主与 Nginx 运行用户（通常是 www-data 或 nginx）匹配，对应 listen.owner 与 listen.group。做完这三步，这类 502 基本能当场解决。
第三步：PHP-FPM 进程池调优，用内存算出进程数
确认服务在运行、502 依然间歇性出现后，问题多半落在资源分配上。PHP-FPM 的核心参数是 pm（进程管理模式）、pm.max_children（最大子进程数）、pm.max_requests（进程重启阈值）。搬家后最容易踩的坑是配置原样搬来，但新旧机器内存规格不同，旧参数要么浪费、要么不足。pm.max_children 的估算很直接：可用内存除以单进程平均占用。先看实际占用：
ps --no-headers -o "rss,cmd" -C php-fpm8.1 | awk '{sum+=$1; n++} END {printf "%d 个进程, 平均 %.1f MB\n", n, sum/n/1024}'
假设一台 2 GB 内存的 VPS（虚拟专用服务器），系统占 400 MB、剩约 1.6 GB，单进程平均 60 MB，则 pm.max_children = 1600 / 60 ≈ 26，保守取 24 留余量。写进 pool 配置并重启：pm = dynamic、pm.max_children = 24、pm.start_servers = 6、pm.min_spare_servers = 4、pm.max_spare_servers = 12。dynamic 模式的含义是进程数随负载在上下限之间浮动：空闲时不占内存、高峰时自动扩容，比 static 更适合流量波动明显的站点。再设 pm.max_requests = 500 让子进程定期重启、回收内存泄漏。如果日志出现 server reached pm.max_children setting，说明并发超过进程上限，要么上调（前提内存允许），要么升级主机规格。
进程数不是越大越好。内存耗尽时系统会触发 OOM（内存溢出终止机制）直接杀掉 php-fpm 进程，Nginx 立刻收到连接拒绝，502 反而更凶猛；稳定做法是让进程数匹配真实流量，内存、CPU 与线路对 VPS（虚拟专用服务器）速度的影响，可参考影响服务器速度的核心因素。
第四步：双向对齐超时与缓冲参数
upstream 超时的修复需要两侧同时动手，只改一边往往顾此失彼。Nginx 侧在 location 块中重点设 fastcgi_read_timeout 300，连接与发送超时同理补齐即可。这个参数默认 60 秒，而 WordPress 后台的导出、更新、重型插件页面经常超过这个时长，300 秒是兼顾可用性与故障暴露的常见取值——设得太短会把慢任务全部打断，设得太长则故障暴露变慢。PHP-FPM 侧确认 request_terminate_timeout = 300 且不小于 Nginx 侧——PHP-FPM 先杀进程，Nginx 记录 connection reset；Nginx 先放弃，PHP 侧还在空跑；对齐后慢请求要么成功返回、要么统一被切断并留下清晰日志。缓冲区是另一个隐性来源：页面较大而 fastcgi_buffer 偏小时，日志出现 upstream sent too big header，同样以 502 呈现；加入 fastcgi_buffer_size 32k 与 fastcgi_buffers 8 32k 可解决多数场景。改完 nginx -t 验证语法，再平滑重载即可生效。
第五步：搬家场景专属的三个检查点
通用调优之外，迁移本身还会引入三类易被忽略的诱因。一是 wp-config.php 的 DB_HOST 仍指向旧数据库——旧主机停机后，每个页面都在等连接超时，Nginx 记录的就是 upstream timed out；这是搬家后最经典的 502，与性能无关，纯属配置遗漏。二是新服务器的 DNS（域名解析服务）解析与 hosts 记录不干净——外部对象存储、邮件等依赖解析失败，同样让 PHP 卡在等待，用 dig 或 curl -v 逐一验证可达性比反复重启有效。三是 Redis 或 Memcached 连接配置没同步迁移——object-cache.php 被复制过来、但新环境缓存服务缺失或地址已变；临时把它改名移除，502 立刻消失就说明问题在缓存层。
完成上述检查后，用错误日志观察收尾：tail -f /var/log/nginx/error.log | grep --line-buffered "upstream"，观察半小时无新增超时，再用无痕模式刷新几个重型页面，即可确认修复到位。
总结与行动建议
回顾整个排查链：先用错误日志区分连接失败与 upstream 超时，前者核对服务状态、socket 路径与权限，后者从进程池内存估算入手，再双向对齐两侧超时参数，最后补上 DB_HOST、DNS、缓存三个搬家专属检查点，每步都有日志证据，避免”重启试试”的循环。如果反复调整后 502 仍间歇出现，或日志频繁出现 pm.max_children 告警，说明主机资源已难以支撑流量，可以考虑升级到更高配置的 Hostease VPS（虚拟专用服务器）方案。调优没有一劳永逸，流量增长、插件变更都会让昨天的参数变成明天的瓶颈，建议每季度复查一次进程平均内存与错误日志趋势；迁移与排障的更多经验与踩坑总结也可参考WordPress 建站部署入门。
微信扫一扫打赏
支付宝扫一扫打赏
