Nginx gzip压缩只依据Content-Type响应头，需显式配置gzip_types覆盖默认行为；必选text/html等文本类型，禁用通配符和已压缩二进制格式；须确保mime.types正确定义扩展名与MIME映射，并通过curl实测响应头验证。
直接在 http、server 或 location 块中写明要压缩的 MIME 类型即可，关键不是文件后缀，而是响应头里的 Content-Type —— Nginx 只认这个，不看 .js 或 .css 文件名。
必须显式列出所有需要压缩的类型
gzip_types 是覆盖式配置：一旦启用，就会完全替代 Nginx 默认仅压缩 text/html 的行为。漏掉 text/html，整个 HTML 页面就失去压缩，首屏加载明显变慢。
- 基础必选（建议直接复制）：
text/html text/plain text/css text/javascript application/javascript application/json application/xml text/xml application/xml+rss image/svg+xml - 现代前端可加：
text/markdown application/typescript application/font-woff2（注意 woff2 压缩需浏览器支持，且非所有场景都推荐） - 绝对不要写
text/*或application/*—— Nginx 直接忽略，配置无效
避开已压缩的二进制格式
JPEG、PNG、GIF、MP4、AVIF、ZIP、PDF、WOFF2 等本身已是高压缩编码，再套 Gzip 几乎不省带宽，反而增加 CPU 开销和传输延迟，甚至可能让体积略微变大。
- 明确排除：
image/jpeg image/png image/gif video/mp4 application/zip application/pdf font/woff2 -
application/octet-stream是“兜底类型”，常代表未识别资源（比如没在 mime.types 中声明的 .log、.md），误加进去会连带压缩图片或 PDF，务必剔除 - SVG 是例外：
image/svg+xml是纯文本 XML，必须且应当压缩
确保 MIME 类型真实匹配响应头
写了 text/markdown 没用，如果 .md 文件返回的是 application/octet-stream，Nginx 就不会压缩它 —— 因为它只比对 Content-Type 响应头。
- 先检查
/etc/nginx/mime.types（Linux）或/usr/local/etc/nginx/mime.types（macOS），确认扩展名已正确定义，例如：types { text/markdown md; application/typescript ts; } - 再在
gzip_types中加入对应项，名称必须完全一致（区分大小写） - 常见映射错误：.js 返回
application/x-javascript而不是application/javascript，需按实际响应头调整
验证是否真正生效
别只信 nginx -t 通过，要实测请求响应头：
- 执行：
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/style.css - 确认返回头含：
Content-Encoding: gzip和Vary: Accept-Encoding - 同时核对
Content-Type是否为你配置的类型（如text/css） - 若后端（如 CDN 或反向代理）已返回
Content-Encoding: gzip，Nginx 默认透传，不会重复压缩
