多域名共享静态资源时Gzip冲突本质是同一预压缩资源被各Nginx实例用不一致逻辑处理;解决核心是统一压缩责任边界:前端构建完成全部预压缩并保留原始文件,Nginx仅启用gzip_static on且禁用所有动态压缩指令,确保各域名对同名文件返回完全一致的Content-Encoding、Content-Type与Vary头。
多域名共享静态资源库(如公共 CDN 或内部统一静态资源服务)时,Nginx 的 Gzip 压缩策略冲突,本质不是“多个域名打架”,而是同一份预压缩资源被不同域名的 Nginx 实例用不一致的压缩逻辑处理——有的启用了动态 gzip,有的只认 .gz 文件,有的还加了 Brotli,导致客户端收到内容编码混乱、缓存失效或响应异常。解决关键在于:统一压缩责任边界,让压缩行为与域名解耦,由资源源头决定压缩形态。
所有静态资源(JS/CSS/JSON/SVG 等)必须在构建阶段完成 Gzip(及可选 Brotli)压缩,并保留原始文件。Nginx 不做任何运行时压缩,只做条件化分发。
vite-plugin-compression 或 compression-webpack-plugin,设置 threshold: 1024(1KB 以上才压缩)和 deleteOriginalAssets: false
main.js 和 main.js.gz;style.css 和 style.css.gz
gzip on、gzip_types、gzip_comp_level 等任何动态压缩指令无论 mathcoding.top、api.example.com 还是 cdn.internal,只要它们指向同一份静态资源物理路径(如 /data/static/),其 Nginx 的静态资源 location 块就必须使用相同、极简的压缩策略:
--with-http_gzip_static_module(主流发行版默认包含)gzip_static on;(可选值为 on 或 always;always 强制返回 .gz 即使请求头无 Accept-Encoding: gzip,一般不用)gzip on、gzip_vary 等干扰指令——这些由构建工具生成的 Vary: Accept-Encoding 已随 .gz 文件一同写入响应头多个域名共用同一套静态文件,但浏览器按完整 URL 缓存资源。若不同域名对同一文件(如 https://a.com/lib/vue.js 与 https://b.com/lib/vue.js)返回不同 Content-Encoding 或 Content-Type,会导致缓存错乱甚至解析失败。
Content-Type(查 mime.types)、相同的 Content-Encoding: gzip(由 gzip_static 自动添加)、不额外覆盖 Vary
types_hash_max_size 或 default_type,防止 MIME 类型识别偏差Content-Encoding 头——应配置 CDN “透传源站编码头”并禁用其自身压缩功能不能只看单个域名,要交叉比对多个域名下同一资源的实际响应行为:
curl -I -H "Accept-Encoding: gzip" https://a.com/js/app.js 和 curl -I -H "Accept-Encoding: gzip" https://b.com/js/app.js,确认两者都返回 200 OK、Content-Encoding: gzip、且 Content-Length 相同Vary、Content-Type、ETag(若 ETag 不一致,说明某域名配置了额外的 hash 计算逻辑,需排查)open() "/path/app.js.gz" failed (13: Permission denied) —— 权限不一致也会导致部分域名回退到未压缩版本