事情本身不复杂，线索都在日志里。日志里 Googlebot 抓首页返回 200，GSC 抓取统计却报解析错误，用 curl 加 Accept-Encoding: gzip 手工请求，拿回来的是一堆二进制乱码。
第一反应是「CDN 对已压缩内容再压缩一次，解压只解掉最外层」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。Nginx 的 gzip_types 漏了 text/html，压缩头和实际内容不匹配。还有一种是PHP 里又调了一次 ob_start(‘ob_gzhandler’)，和 Nginx 形成双层压缩。
少数情况下是响应头写了 Content-Encoding: gzip 但 body 是明文。
请求压缩版本并检查响应头
curl -sI -H 'Accept-Encoding: gzip,deflate' https://www.example.com/ | grep -i 'content-encoding\|content-length'再往下关掉 PHP 层的二次压缩
grep -rn 'ob_gzhandler' /www/wwwroot/lu0.cn/末了用解压参数验证拿到的是完整 HTML
curl -s --compressed https://www.example.com/ | head -c 200我习惯把每一步的执行时间和结果记在一边，后面复盘省事。
怎么算真的好了，看的是同一批现象。带 –compressed 请求能正常输出 HTML 首屏源码，日志里抓取大小回到 20KB 上下，GSC 的解析错误逐日减少。
只删 PHP 的压缩还不够，CDN 若是 gzip 加 br 双写，得到响应头里看 Vary 与 Content-Encoding 是否只有一项，再逐层排。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。