问题出现得很突然,日志倒是留得挺全。源站开了 brotli 但 Nginx 1.24 编译时没带对应模块 CDN 又默认转发 Accept-Encoding: br gzip 源站只认 gzip 却把 Content-Encoding 写成 br 蜘蛛解出来是乱码 抓取诊断显示编码错误
刚开始盯着「CDN 改写 Accept-Encoding 后没有同步响应头」,折腾了半个多小时,排掉了。
把日志和配置对完,能解释这个现象的基本就这几处。响应头声明的编码与实际压缩格式不一致。还有一种是brotli 模块没编译 但配置里写了 brotli on。
不容易想到的是,静态预压缩只生成了 .br 没有 .gz。
第一件事是看响应头里的编码声明
curl -sI -H 'Accept-Encoding: br,gzip' https://www.example.com/p/1 | grep -i content-encoding
再往下确认服务端是否真的支持 brotli
nginx -V 2>&1 | grep -o with-brotli
接着关闭 brotli 只保留 gzip
brotli off; gzip on; gzip_types text/html application/json;
等前面都确认过,再用蜘蛛 UA 解一次看正文
curl -s --compressed -A 'Baiduspider' https://www.example.com/p/1 | head -5
怎么算真的好了,看的是同一批现象。响应头编码与实际压缩一致 蜘蛛抓到的正文可读 抓取诊断里编码错误消失。
这里还有个坑。压缩协商看的是响应头 不是配置 配置写了 brotli 而模块没装 等于给蜘蛛发了一份坏文件。线上能稳定复现的问题都不算难,难的是只在大流量下才出现的那种。
