CDN回源乱码主因是Nginx压缩配置与CDN支持格式不匹配。需检查Accept-Encoding和Content-Encoding头，统一仅启用gzip并禁用Brotli，通过map指令对CDN UA清空Accept-Encoding头，确保Vary头准确且CDN正确识别。
CDN 回源时出现乱码，常见原因是客户端（如浏览器）通过 CDN 请求资源，CDN 向源站（Nginx）回源时携带了 Accept-Encoding 头（例如 gzip, br, deflate），而 Nginx 没有启用对应压缩模块或未正确配置压缩响应，导致返回未压缩内容却被 CDN 错误标记为已压缩，或返回了不兼容的压缩格式（如 Brotli 但 CDN 不支持），最终解压失败、显示乱码。
确认问题根源：检查请求头与响应头
先抓取 CDN 回源请求的实际 Header，重点关注：
-
客户端请求中的
Accept-Encoding：看是否包含br（Brotli）、gzip等； -
Nginx 响应中的
Content-Encoding：是否与请求的编码匹配？是否为空却声明了Vary: Accept-Encoding？ -
响应体是否真被压缩：用
curl -I -H "Accept-Encoding: gzip" https://your-domain/file.js查看状态码和头；再用curl -H "Accept-Encoding: gzip" https://your-domain/file.js | gunzip -t验证能否正常解压。
统一并限制回源支持的压缩算法
CDN 回源行为不可控，最稳妥方式是让 Nginx 只响应 CDN 能正确处理的压缩格式（通常仅 gzip）。在 Nginx 配置中禁用 Brotli 或其他非通用压缩：
- 确保未加载
ngx_http_brotli_filter_module（如使用第三方 Brotli 模块），或注释掉brotli on;相关配置； - 显式关闭非必要压缩：不要依赖模块默认开关，主动控制；
- 在
http或server块中设置：
gzip on; gzip_types text/plain text/css application/javascript application/json image/svg+xml; gzip_vary on; gzip_min_length 1024; gzip_comp_level 6; <h1>彻底禁用 Brotli（即使模块已编译）</h1><p>brotli off; # 若支持该指令</p><h1>或更彻底：不加载 brotli 模块，或移除相关配置行</h1><p></p>
针对 CDN 回源请求，强制忽略 Accept-Encoding
某些 CDN（如 Cloudflare、阿里云全站加速）回源时会带 Accept-Encoding: br, gzip, ...，但源站无需响应 Brotli。可利用 map 指令清空回源请求的编码头：
- 在
http块顶部添加：
map $http_user_agent $disable_accept_encoding {
~*^(Cloudflare|AliYun|AWSALB|AzureCDN|CDN77) 1;
default 0;
}
map $disable_accept_encoding $accept_encoding {
1 "";
0 $http_accept_encoding;
}
- 然后在
server或location中使用：
proxy_set_header Accept-Encoding $accept_encoding;
这样，当检测到 CDN UA 时，回源请求不带 Accept-Encoding，Nginx 就不会尝试压缩，避免格式错配；真实用户请求仍可正常协商 gzip。
补充：确保 Vary 头准确且缓存友好
若开启 gzip_vary on，Nginx 会加 Vary: Accept-Encoding。CDN 必须据此区分缓存——否则可能把 gzip 版本缓存后返回给不支持 gzip 的客户端，造成乱码。务必确认：
- CDN 控制台已开启对
Vary头的识别（如 Cloudflare 默认开启，阿里云需手动勾选“遵循源站 Vary”）； - 避免在静态资源上错误添加
add_header Vary *，导致冗余或冲突； - 对明确不压缩的路径（如
/api/），可单独关闭 gzip：
location /api/ {
gzip off;
add_header Vary "";
}
