配置Brotli的Nginx未对大体积JSON响应压缩，大请求仍采用Gzip编码的问题排查

嘿，我来帮你梳理下这个问题！从你的描述来看，小请求能用Brotli但大请求自动 fallback 到Gzip，大概率是这几个配置或编译细节没处理好：

1. 确认Nginx是否正确编译了动态Brotli压缩模块 #

你提到是源码编译Nginx，而Brotli有两个核心模块：

• ngx_brotli_static_module：处理预压缩的静态文件（对应你开启的brotli_static on）
• ngx_brotli：处理动态生成的内容（比如你的Django JSON响应）

如果编译时只加了静态模块、没加动态压缩模块，那动态生成的大JSON就无法触发Brotli，只能 fallback 到Gzip（哪怕你全局设了gzip off，可能某些隐性配置或模块自带的默认值又开启了Gzip）。

你可以通过nginx -V命令查看编译参数，确认是否包含了--add-module=path/to/ngx_brotli（注意是主模块，不是static子模块）。如果没加，需要重新编译Nginx，同时包含两个Brotli模块。

2. 检查是否存在局部Gzip配置覆盖 #

虽然你全局设了gzip off，但如果在server或location块（尤其是代理Django的那个location）里单独开启了gzip on，就会优先触发Gzip压缩。

建议检查所有配置块，确保没有局部的gzip on配置。可以用nginx -T命令查看完整的生效配置，搜索gzip on看看有没有意外开启的地方。

3. 开启Brotli对分块响应的支持 #

当Django返回大JSON时，通常会用**分块传输编码（chunked）**来发送内容。而Nginx的Brotli模块默认不会对chunked响应做压缩（brotli_chunked参数默认是off）。

你可以在配置里添加：

brotli_chunked on;

这样Brotli就能处理分块的大响应了。

4. 确认brotli_min_length没有被错误设置 #

虽然Brotli的默认brotli_min_length是20字节，但如果你的配置里（或继承的配置）不小心设了一个高于300的值，就会导致超过该长度的请求不触发Brotli。

可以显式设置这个参数确保覆盖默认：

brotli_min_length 20;

5. 检查反向代理的头传递（如果Nginx代理Django） #

如果Nginx是作为反向代理指向Django，要确保没有修改Accept-Encoding头。比如如果配置了proxy_set_header Accept-Encoding gzip;，就会强制Nginx只请求Gzip压缩的内容，忽略浏览器的Brotli请求。

正确的做法是要么不修改这个头，要么传递完整的浏览器头：

proxy_set_header Accept-Encoding $http_accept_encoding;

最后，修改配置后记得重启Nginx（nginx -s reload），然后用浏览器的开发者工具查看响应头的Content-Encoding，确认大请求是否触发Brotli。

内容的提问来源于stack exchange，提问作者rep_movsd