Nginx 不支持 TLS 解密前的 Brotli 预处理，因 Brotli 是 HTTP 层压缩机制，必须在 TLS 解密后、应用层处理中进行；其仅支持响应体压缩和回源请求头声明 Accept-Encoding: br。
Nginx 本身
不提供“解密前预处理”功能
，也
不支持在 TLS 解密之前对 HTTP 请求体或头部做 Brotli 相关操作
。这个说法存在根本性误解。
Brotli 是一种
内容编码（Content-Encoding）机制
，作用于
HTTP 消息体（payload）的压缩/解压层面
，它必须发生在 TLS 解密
之后
、应用层处理
之中
——因为：
和
都是 HTTP 请求/响应头字段；
TLS 层只负责加密整个 TCP 报文流，不解析 HTTP 结构；
Nginx 只有在完成 TLS 握手、解密出明文 HTTP 请求后，才能读取
头，并决定是否用 Brotli 压缩响应体；
同样，客户端也只有在 TLS 解密后，才能从响应头中看到
并触发解压。
所以，“解密前用 Brotli 预处理入站流量”在协议栈和 Nginx 架构中
不可行，也不符合设计逻辑
。
Nginx
在宝塔面板中轻松管理Nginx高性能Web服务器。提供可视化配置反向代理、负载均衡、SSL证书及HTTP缓存功能，一键优化高并发性能，助您高效搭建稳定、快速的网站运行环境。
下载
✅ 正确的理解和做法是：
1. Brotli 压缩只作用于 Nginx 发给客户端的响应体（出向）
客户端请求带
；
Nginx 判断资源可压缩、类型匹配（如
）、大小达标（
），且启用
；
Nginx 动态压缩响应体，返回
+ 压缩后 body。
⚠️ 注意：这不会影响回源请求，也不会压缩入站请求体。
2. 若想降低回源带宽，需让 Nginx
主动向源站发带的请求
这属于「反向代理场景」，不是“解密前处理”，而是
控制 outbound 请求头
：
源站必须真正支持 Brotli（如 Nginx +
），并根据该头返回
；
边缘 Nginx 缓存时，必须把
加入
，否则 gzip 和 br 版本会互相覆盖（缓存污染）。
3. 入站请求体（如 POST 数据）默认不被 Nginx 解压
即使客户端用
发送压缩过的请求体，
标准 Nginx 不解析、不解压、不重写该请求体
；
这类需求极少见，且需定制模块（如
的逆向变种），官方不支持；
实际业务中，前端通常不压缩请求体；若真有需要，应在应用层（如 Node.js/Go 后端）自行解压。
总结关键点：
Brotli 是 HTTP 层压缩，依赖明文 HTTP 头，
必然发生在 TLS 解密之后
；
Nginx 的 Brotli 功能只用于
压缩它发出的响应
，或
识别并透传
入站
；
“解密前预处理”是概念错位，Nginx 没有钩子在 SSL handshake 完成前操作 HTTP 内容；
真正优化方向只有两个：
对客户端响应启用 Brotli（提升首屏速度）；
对源站回源请求声明
（节省回源带宽）。
不需要复杂改造，配置清晰、生效直接。
Accept-EncodingContent-EncodingAccept-Encoding: brContent-Encoding: brAccept-Encoding: br,gziptext/cssbrotli_min_lengthbrotli onContent-Encoding: brhttp {
brotli on;
brotli_comp_level 6;
brotli_min_length 512;
brotli_types text/plain text/css text/javascript application/javascript application/json;
}brlocation / {
proxy_pass https://origin.example.com;
proxy_set_header Accept-Encoding "br,gzip,deflate"; # 关键：声明支持 br
proxy_cache_key "$scheme$request_method$host$request_uri$http_accept_encoding";
}brotli onContent-Encoding: br$http_accept_encodingproxy_cache_keyContent-Encoding: brngx_http_brotli_filter_moduleAccept-EncodingAccept-Encoding: br