关键不是看配置写了没，而是验证模块是否真被nginx识别、加载并参与请求处理链；需依次执行nginx -v | grep ngx_brotli确认编译集成、nginx -t检查指令识别、load_module路径与权限校验、指令位置及拼写排查，并最终用curl -h "accept-encoding: br" -i验证响应头content-encoding: br。
排查 Brotli 压缩失效是否由模块未正确加载引起，关键不是看配置写了没，而是验证模块是否真被 Nginx 识别、加载并参与请求处理链。很多“brotli on;”配置看似完整，但模块根本没进内存，压缩自然不会发生。
确认 Nginx 启动时是否加载了 ngx_brotli 模块
模块未加载是压缩失效最直接的原因。不能只依赖配置存在，必须查运行态：
- 执行 nginx -V 2>&1 | grep -o ngx_brotli —— 若无输出，说明 configure 阶段就没引入模块，编译时已排除
- 若输出有 ngx_brotli，再检查实际进程是否加载：运行 nginx -t，观察是否有 “unknown directive ‘brotli’” 报错；有则代表模块虽编译进去了，但运行时未启用（如动态模块路径错误或 load_module 指令缺失）
- 对动态模块（.so），确认 load_module modules/ngx_http_brotli_filter_module.so; 出现在配置的 http 块顶部，且 .so 文件真实存在、权限可读、架构匹配（如 x86_64）
验证 brotli 指令是否被识别且无语法错误
即使模块加载成功，指令位置或上下文错误也会让配置静默失效：
- brotli 相关指令（如 brotli on;、brotli_comp_level 4;）必须放在 http、server 或 location 块内，不能出现在 if、map 或 event 块中
- 检查是否有拼写错误：比如写成 brotil on; 或 brotli_enable on;，Nginx 不报错但忽略
- 运行 nginx -t 后，留意 warning 级提示，例如 “directive is not terminated by semicolon”，这类问题常导致后续 brotli 指令整体不生效
检查响应头是否真正携带 Content-Encoding: br
这是最终验证环节，绕过所有中间判断，直击结果：
- 用 curl 发起明确支持 Brotli 的请求：curl -H "Accept-Encoding: br" -I https://your-domain.com/test.js，查看响应头中是否有 Content-Encoding: br
- 对比同一请求去掉 Accept-Encoding 头的结果，确认差异仅在编码头，而非状态码或 body 变化
- 若始终返回 Content-Encoding: gzip 或无该头，且已确认 gzip 和 brotli 同时开启，则大概率是模块未参与协商流程——常见于模块加载顺序错误（如 brotli filter 被其他 filter 覆盖）、或配置被更高优先级 location 覆盖
排除模块与 Nginx 版本 ABI 不兼容
升级 Nginx 后出现压缩失效，很可能是模块二进制不匹配：
- 运行 nginx -v 查版本（如 1.25.3），再查该版本下 ngx_brotli 官方 README 是否声明支持；不支持时模块可能加载成功但函数调用失败，指令被跳过
- 检查 error.log 中是否有 module version mismatch、undefined symbol ngx_http_brotli_filter 类报错，这是 ABI 断裂的典型标志
- 稳妥做法：用当前 Nginx 源码重新编译 ngx_brotli，生成新 .so 替换旧文件，再 reload
