先看现象。缓存 key 默认包含完整请求头 同一篇文章 gzip 和 br 各存一份 蜘蛛请求 gzip 用户浏览器请求 br 命中率被砍半 缓存空间翻倍 回源量也上去了
排查方向其实有限，先把可能性排一排。缓存键包含完整 query 和请求头。还有一种是压缩格式在缓存层之前就已经确定。
不容易想到的是，CDN 没有开启压缩归一化。
还有一种情况，不同客户端协商结果不同 各存一份。
第一件事是对比两次不同编码请求的缓存状态
curl -sI -H 'Accept-Encoding: gzip' https://www.example.com/p/1 | grep -i cache随后把缓存键里的编码维度去掉
proxy_cache_key $scheme$host$request_uri;接着在边缘统一做压缩
gzip on; brotli on;剩下的就是观察命中率变化
curl -sI https://www.example.com/p/1 | grep -i -E 'x-cache|age'同一份数据我导出了两份，一份留底，一份拿来试。
恢复的判定其实很直接。不同编码请求命中同一份缓存 回源量下降一半 缓存占用同步减少。
缓存键每多一个维度 命中率就按倍数下降 编码这种可归一化的东西不该进键。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。