我把GEO问句库的gzip编码对齐后，日志里的引用计数缩水了12%

上周跑批校验，发现一个诡异现象：同一批问句，服务端gzip压缩和客户端解压后统计的AI引用条数差12%。

先说背景。我们GEO问句库走的是CDN，源站返回的Content-Encoding、Vary头、ETag都没问题。但我在日志里抓包比对时发现，同一批问句在压缩前和压缩后的字节流里，被AI引用的URL编码变了。

具体场景：问句库里有大量中文关键词，URL编码后带%。gzip压缩是字节级操作，本身不改字符。但问题出在链路中间——某层代理对已压缩的响应又做了一次URL重写，把%XX当成了%25XX。

我做了三组对照：

• A组：源站直接返回gzip，不经代理。引用计数基准=100%。
• B组：过一层代理，代理配置了rewrite规则。引用计数=88%。
• C组：代理rewrite规则里加上[NE]（noescape）标志。引用计数回到99.6%。

差异来源是编码对齐：AI抓取时按URL原文匹配，但编码被二次转义后，匹配不上原问句，引用就丢了。12%的缩水不是抽样误差，是编码污染。

我的判断依据：把A组和B组的响应体解压后做字节diff，发现B组所有%都变成了%25。这不是压缩问题，是压缩后又被改写的复合问题。

踩坑细节：

1. gzip压缩比别拉太高，level 9会把URL里的%和字母混在一起，某些中间件解析时容易误判。我降到level 6后，误判率降了。
2. Vary头必须带Accept-Encoding，否则CDN缓存会把压缩版和未压缩版混着发，统计口径就乱了。
3. 日志采样时，压缩前和压缩后的字节数要分别打点。我一开始只记了压缩后的，分母口径对不上。

现在我把gzip编码对齐加进了跑批前置检查：源站、代理、CDN三段的Content-Encoding必须一致，不一致就告警。另外，URL编码在入库前统一做一次规范化，避免%25XX这种二次转义。

这套下来，引用计数波动从12%压到了0.4%以内。

想问下社区里做GEO基础设施的：你们在CDN回源那层，是怎么保证gzip压缩后URL编码不被中间件二次改写的？有没有遇到过类似%25XX的污染？