排查Nginx Brotli预压缩文件未被读取，关键在于确认.br文件真实存在且权限可读、brotli_static置于对应location块内、Content-Type与原始文件严格一致、charset utf-8及完整性校验（响应体字节数等于.br文件大小）。
排查 Nginx Brotli 静态预压文件（如 .html.br、.js.br）未被正确读取，关键不是“有没有压缩”，而是“Nginx 是否真正找到并返回了 .br 文件”——它不生成、不协商、不降级，只做存在即返回的硬匹配。常见现象是响应仍是未压缩内容、响应头无 Content-Encoding: br、或浏览器报解码失败，根源多在路径、权限、配置作用域或 MIME 继承上。
确认 .br 文件真实存在且可被 worker 进程读取
Nginx 不会报错提示文件缺失，只会静默回退到原始文件（若启用常规 gzip）或直接 404（若禁用所有压缩）。必须人工验证：
- 检查文件是否物理存在：
ls -l /usr/share/nginx/html/app.js.br，注意后缀必须严格为.br（不是.brotli或其他） - 确认 worker 进程用户（如
nobody或www-data）有读权限：sudo -u nobody cat /path/to/app.js.br | head -c 20 > /dev/null - 确保目录有执行权限（
x）：worker 需进入目录才能读文件，namei -l /path/to/app.js.br可逐级检查权限链
验证 brotli_static 指令是否在正确的 location 块中启用
brotli_static 和 gzip_static 类似，仅在能精确匹配请求路径的 location 块内生效，全局配置（http 块）无效：
- 必须写在覆盖目标资源的
location内，例如：location /static/ { brotli_static on; } - 避免放在
if、upstream或map块中——这些上下文不支持该指令 - 用
curl -I https://example.com/static/app.js查响应头；若无Content-Encoding: br，大概率是配置未命中或文件不存在
检查 Content-Type 是否与原始文件一致
Brotli 静态服务不改 Content-Type，它完全继承自对应非压缩文件（如 app.js → application/javascript）。若类型错误，浏览器可能拒绝解析或乱码：
- 确认 Nginx 的
types块包含对应映射，例如：application/javascript js; - 检查是否有
default_type text/plain;等覆盖性指令，尤其在该location内误设会强制覆盖 MIME - 对比请求
/app.js和/app.js.br的响应头：curl -I https://host/app.js与curl -I https://host/app.js.br—— 两者Content-Type必须完全相同
排除 charset 与响应完整性干扰
即使 Content-Encoding: br 出现，若字符集缺失或响应体不完整，仍会导致渲染异常：
- 在
server或http块添加：charset utf-8;，并确保brotli_types中的关键类型（如text/html）被charset_types覆盖 - 验证响应体字节数是否等于
.br文件大小：curl -s https://host/app.js | wc -c对比wc -c /path/to/app.js.br；不等说明被截断（常见于proxy_buffering on且缓冲区不足时） - 若使用反向代理，确认未开启
proxy_buffering off或proxy_max_temp_file_size 0，这类设置可能绕过静态文件直送逻辑
