正文（约 800 字，采用“他”之口吻）
当凌晨 3:17 的监控曲线第一次刺穿 5xx 阈值时，他正站在机房玻璃幕前，手里那杯美式已经凉透。不到 72 小时，整站就要从独立机房迁往弹性云，而此刻返回的 500 像一记闷棍——它既未携带 stack trace，也未留下任何可追踪的 PHP error_log。
他先让灰度流量回滚到旧集群，再拉起新集群的 strace，像剥洋葱一样层层逼近：第一层是 Nginx，access.log 显示 upstream 响应 500，但时间戳与 PHP-FPM 的 slow log 并不对齐；第二层是 PHP-FPM，master 进程存活，而子进程在 fork 之后 30 ms 内即被 SIGKILL；第三层是内核，dmesg 弹出 oom-killer 的刀口，指向 PHP 内存池突增至 512 MiB。
问题的根因并不在代码，而在迁移脚本：rsync 同步时把 .user.ini 遗漏了，导致 memory_limit 回退到默认 128 MiB；新环境启用了 OPcache，旧转义函数在 JIT 缓存里与新版插件产生重入冲突，引发递归膨胀。
他用了三步止血：
在 Ansible 的 post-task 里追加 .user.ini 的校验哈希，确保 memory_limit 恒为 512 MiB；
关闭 opcache.revalidate_path，改用 validate_timestamps=1 并配 60 s 的 refresh，防止 opcode 与文件系统时差；
在 wp-config.php 顶部显式声明 WP_DEBUG_LOG + WP_DISABLE_FATAL_ERROR_HANDLER，把致命错误写进 /wp-content/debug.log，而非默认地吞进黑洞。
灰度流量再次切回时，500 曲线在 90 秒内归零。他在 Grafana 上画了一条红色注释：迁移不是文件级别的复制，而是运行时可观测性的整体迁移。随后，他把这次复盘写进团队的《云原生故障辞典》，标签只有两个词：「边界条件」「可观测性」。
教程：迁移 WordPress 出现 500 错误的系统化排查与解决
下面给出一份面向一线运维与开发者的“可落地”教程，完全对应上文所述故障场景，可直接照搬到 CentOS 7 + PHP 7.4 + Nginx 1.20 的新集群。
步骤 1：快速止血
1.1 回滚流量
• 若使用 SLB：在控制台把权重切 0。
• 若使用 DNS：把 A 记录 TTL 改成 30 s，并指回旧 IP。
步骤 2：开启全链路日志
2.1 Nginx
sudo vim /etc/nginx/nginx.conf
在 http 段加入：
log_format debug 'remoteaddr【time_local】 "request" '
'status=status upstream=upstream_addr '
'rt=request_time uct="$upstream_connect_time"';
access_log /var/log/nginx/access_debug.log debug;
error_log /var/log/nginx/error_debug.log warn;
2.2 PHP-FPM
sudo vim /etc/php-fpm.d/
www.confcatch_workers_output = yes
php_admin_value【error_log】 = /var/log/php-fpm/error.log
php_admin_flag【log_errors】 = on
2.3 WordPress
wp-config.php 顶部追加：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );
ini_set( 'log_errors', 1 );
ini_set( 'error_log', '/var/www/html/wp-content/debug.log' );
步骤 3：复现并抓取底层信号
3.1 复现
curl -I
https://your-domain.com/wp-admin/3.2 dmesg
sudo dmesg -T | egrep -i "killed process|oom"
3.3 strace
sudo strace -f -p $(pgrep php-fpm | head -1) -o /tmp/php.strace
步骤 4：核对迁移差异
4.1 文件级
rsync -avn --delete /old/ /new/ | grep "^.user.ini"
4.2 配置级
diff /old/.user.ini /new/.user.ini
若 memory_limit 不同，立即：
echo "memory_limit = 512M" > /new/.user.ini
步骤 5：OPcache 冲突专项修复
5.1 临时关闭
sudo vim /etc/php.d/10-opcache.ini
opcache.enable=0
systemctl restart php-fpm
若 500 消失，则确认为 OPcache 问题。
5.2 永久配置
opcache.enable=1
opcache.revalidate_path=0
opcache.validate_timestamps=1
opcache.revalidate_freq=60
6.2 预置监控
• Prometheus + Grafana：
- nginx_http_requests_total{status=~"5.."}
- phpfpm_process_request_duration_seconds_bucket
步骤 7：灰度 & 验证
7.1 权重 5% → 20% → 50% → 100%，每步观察 10 分钟。
7.2 若 5xx 持续为 0，且 p99 < 500 ms，则标记发布成功。
附：一键检查脚本（保存为 check_wp500.sh）
#!/bin/bash
LOGDIR=/var/log
echo "=== Nginx 5xx ==="
awk '$9>=500' $LOGDIR/nginx/access_debug.log | tail -5
echo "=== PHP Fatal ==="
grep -i "fatal" $LOGDIR/php-fpm/error.log | tail -5
echo "=== Kernel OOM ==="
dmesg -T | egrep -i "killed process" | tail -5
chmod +x check_wp500.sh && ./check_wp500.sh
至此，迁移导致的 WordPress 500 错误已被系统化拆解、定位并永久修复。
