问题出现得很突然，日志倒是留得挺全。抓取统计里下载大小只有 2KB，看日志所有请求都是 200，用 curl 复现发现响应体为空，Content-Length 是 0，只有带 Accept-Encoding: gzip 时才恢复正常。
真正麻烦的地方在于，几个原因的现象几乎一样。gzip 模块对空输出直接跳过，头部已经发出无法再补内容。也可能是页面缓存命中了一条写坏的缓存文件，长度记为 0。
另外，PHP-FPM 子进程内存耗尽被 kill，Nginx 仍按 200 结束响应。
带压缩头复现并比对长度
curl -s -H "Accept-Encoding: gzip" -o /dev/null -w "%{size_download} %{http_code}\n" https://www.example.com/再往下清掉写坏的页面缓存
wp cache flush && rm -rf wp-content/cache/*末了查 FPM 是否出现子进程异常退出
grep -i "child.*exit\|severe" /var/log/php8.2-fpm.log | tail -20这台环境是别人交接的，不少默认值被动过，只能一项项核。
别只看报错消失，验证要多做一步。同一条命令的 size_download 从 0 变成 68KB，日志里不再出现 200 配 0 字节的组合，GSC 抓取下载大小回到正常区间。
只查状态码看不出这个问题，抓取统计里的下载大小是更早的信号，建议一起纳进监控。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。