nginx 不应压缩 jpeg、png、mp4、pdf 等已压缩二进制文件，需在 gzip_types 中显式排除 image/、video/、application/pdf 等 mime 类型，并保留 text/html 等必要文本类型，同时校准 mime.types 以确保 content-type 准确识别。
图片、视频、字体、PDF 等二进制文件本身已是高压缩格式，Nginx 对它们启用 gzip 压缩不仅几乎不减小体积，还可能因添加 gzip 头部导致文件略微变大，同时白白消耗 CPU。误压缩的根源不是“开了 gzip”，而是 gzip_types 配置不当 或 MIME 类型识别错误。解决的关键是精准拦截，而非事后补救。
明确排除已压缩的 MIME 类型
nginx 的 gzip_types 只依据响应头中的 Content-Type 判断是否压缩，不看文件后缀。必须显式剔除所有已压缩格式：
-
image/jpeg、image/png、image/gif、image/webp、image/avif -
video/mp4、video/webm、audio/mpeg -
application/pdf、application/zip、application/x-rar-compressed -
font/woff2、font/woff、application/vnd.ms-fontobject -
application/octet-stream（万能兜底类型，极易误伤，务必移除）
确保 gzip_types 不覆盖默认行为且不漏关键文本类型
一旦你自定义 gzip_types，nginx 就会完全忽略其默认值（仅 text/html）。漏掉 text/html 会导致首页 HTML 完全不压缩。推荐直接使用经验证的基础组合：
-
text/html（必须） -
text/plain、text/css、text/javascript、text/xml、text/markdown -
application/javascript、application/json、application/xml、application/xml+rss -
image/svg+xml（SVG 是纯文本 XML，应压缩）
切勿使用 text/* 或 application/* —— nginx 直接忽略这类通配符配置。
校验真实 Content-Type 是否匹配
写了 text/markdown 却没生效？很可能是 .md 文件返回的是 application/octet-stream。需检查并修正 mime.types 文件：
- 打开
/etc/nginx/mime.types（Linux）或/usr/local/etc/nginx/mime.types（macOS） - 确认存在对应映射，例如：
text/markdown md;、application/typescript ts; - 重启 Nginx 使 mime 映射生效
之后再用 curl 或浏览器开发者工具查看响应头，确认 Content-Type 确实为预期值。
启用 gzip_static + 严格限制 fallback 范围
即使启用了 gzip_static on（优先返回预生成的 .gz 文件），若 gzip_types 错误包含图片类型，Nginx 在 fallback 到动态压缩时仍会尝试压缩它们。因此：
- 只保留真正受益的文本类型到
gzip_types中 - 禁用低效客户端的压缩兜底：
gzip_disable "MSIE [1-6]\."; - 配合
gzip_vary on和合理的proxy_cache_key（含$http_accept_encoding），避免缓存污染
这样，Nginx 在预压缩路径失效时，也不会把压缩逻辑扩散到不该碰的二进制资源上。
