Linux怎么配置Nginx的Gzip静态预压缩-LINUX-PHP中文网

gzip_static生效需nginx编译时启用--with-http_gzip_static_module模块，且请求路径存在同名.gz文件、权限正确、mtime同步；其优先级高于gzip，content-length等于.gz文件大小，$gzip_ratio恒为"-"。

linux怎么配置nginx的gzip静态预压缩

没这个模块，gzip_static on 直接被当成无效指令，nginx -t 会报错 unknown directive "gzip_static"。这不是配置写错，是二进制根本不认识这个词。

运行命令验证：

nginx -V 2>&1 | grep -o with-http_gzip_static_module

如果输出为空，说明缺失模块。此时不能靠 reload 或改配置解决，必须重新编译 Nginx 并显式加上 --with-http_gzip_static_module 参数。Ubuntu/Debian 的 apt 包、CentOS 的 yum 包通常不带该模块，宝塔面板默认也不启用。

可以，而且推荐共存：前者负责已预压缩的静态文件（如 /js/app.js.gz），后者作为兜底处理动态响应或漏掉的资源。但二者行为完全不同，混用时容易误判生效路径。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

gzip_static 不受 gzip_types 控制，只要请求路径匹配、存在同名 .gz 文件、且原始文件与 .gz 文件的 mtime 一致，就直接返回 .gz —— 完全跳过 zlib 压缩过程
gzip 则严格检查 gzip_types、Accept-Encoding 头、gzip_min_length 等条件，满足才动态压缩
不要在 location 块里重复写 gzip on；gzip_static 建议只放在静态资源 location 中（例如 location ~* \.(js|css|svg)$）

最常见原因是 Nginx 找不到或拒绝使用 .gz 文件，导致它多做一次 stat 系统调用后回退到动态 gzip，反而增加延迟。

排查要点：

确认 .gz 文件真实存在，且与原始文件同目录、同名（如 style.css 对应 style.css.gz）
检查文件权限：nginx worker 进程用户（通常是 www-data 或 nginx）必须对 .gz 文件有读权限
核对修改时间：stat -c "%y" style.css 和 stat -c "%y" style.css.gz 输出必须完全一致；构建脚本更新源文件后，必须同步重生成 .gz（例如用 gzip -k -9 style.css）
确保没在 location 中错误地写了 try_files $uri $uri/ =404 之类语句——gzip_static 必须在 try_files 之前生效，否则会被绕过

不能只看响应头有没有 Content-Encoding: gzip，因为动态 gzip 也会加这个头。真凭实据是：

Content-Length 值等于本地 stat -c "%s" xxx.js.gz 的字节数，而不是原始文件大小
响应头中 ETag 值由 .gz 文件的 inode + mtime 计算得出（可用 curl -I 查看），而非原始文件
日志中 $gzip_ratio 变量恒为 "-"（该变量仅对动态 gzip 生效）
更底层可抓系统调用：strace -e trace=openat,stat -p $(pgrep nginx)，观察是否出现 openat(..., "app.js.gz", ...)