Nginx无法原生压缩CSS，仅支持Gzip通用文本压缩；需在http块启用gzip并添加text/css到gzip_types，确保CSS响应头为Content-Type: text/css。
在 Nginx 的 http 块中无法直接“开启 CSS 压缩”，因为 Nginx 本身不解析或重写 CSS 内容，也不具备类似 HTML/CSS/JS 的语法感知型压缩能力（如去除空格、注释、合并规则等）。它不提供原生的 CSS 文件内容压缩功能。
真正起作用的是 Gzip 压缩（通用文本压缩）
Nginx 支持对响应体启用 Gzip 压缩，这是一种通用无损压缩算法，适用于所有文本类资源（包括 CSS、JS、HTML、JSON 等）。它在传输前压缩响应体，在客户端解压，显著减少带宽占用——这才是实际生效、推荐配置的方式。
- 确保
gzip已开启（默认可能关闭） - 显式添加
text/css到gzip_types中（早期版本默认不含） - 建议启用
gzip_vary on，让代理和浏览器知道响应可能被压缩
典型 http 块 Gzip 配置示例
在 /etc/nginx/nginx.conf 的 http 块内添加或修改：
gzip on;<br>gzip_vary on;<br>gzip_min_length 1024;<br>gzip_types text/plain text/css text/xml text/javascript application/javascript application/x-javascript application/xml application/xml+rss application/json;<br>gzip_comp_level 6;<br>gzip_disable "MSIE [1-6]\.(?!.*SV1)";
✅ 这样配置后，所有匹配 MIME 类型的 CSS 文件（如 style.css 返回 Content-Type: text/css）将自动启用 Gzip 压缩。
立即学习“前端免费学习笔记（深入）”；
注意：CSS 文件需正确设置 Content-Type
Nginx 要根据响应头中的 Content-Type 判断是否压缩。确保 CSS 文件被识别为 text/css：
- 静态文件服务时，Nginx 默认通过后缀映射 MIME 类型（
.css → text/css），一般无需干预 - 若用
add_header Content-Type手动覆盖，务必设为text/css，否则 gzip_types 不会匹配 - 可通过
curl -I https://yoursite/style.css检查响应头是否含Content-Type: text/css和Content-Encoding: gzip
不推荐的“CSS 压缩”误区
以下方式不属于 Nginx 原生能力，需额外工具或架构配合，不应在 http 块中尝试：
- 用 Lua 模块（如
ngx_http_lua_module）实时读取、解析、压缩 CSS —— 性能差、不稳定、维护难 - 依赖
sub_filter替换空格/注释 —— 不安全（可能破坏字符串、正则、URL）、不完整、不标准 - 期望 Nginx 自动 minify CSS —— 它没有 CSS 解析器，做不到语义级压缩
真正的 CSS 压缩（minify）应在构建阶段完成（如 Webpack、PostCSS、esbuild），Nginx 只负责高效、安全地传输已压缩的文件。
