brotli是http响应体的无损压缩算法，不参与加解密；其在tls加密之后执行，nginx的brotli模块仅作用于output_body_filter钩子，无法介入tls握手或加解密流程。
Brotli 压缩本身不涉及加密或解密，它只是无损压缩算法；Nginx 中的 brotli 模块只负责压缩响应体，不能用于“加密前预处理”或“解密后预处理”——这个前提不成立，直接按此思路配置必然失败。
为什么 Nginx 的 brotli 无法参与加解密流程
Brotli 是应用层（HTTP body）的压缩编码，运行在 TLS 加密之后、HTTP 解析之前。真实链路是：原始内容 → brotli 压缩 → HTTP response body → TLS 加密 → 网络传输。也就是说：
- TLS 加密发生在 TCP 层之上，对整个 HTTPS 报文（包括 header 和已压缩的 body）整体加密，
brotli压缩结果是它的输入，不是它的前置步骤 - Nginx 没有机制在 TLS 握手前后拦截并修改加密/解密行为；
brotli_filter只监听ngx_http_output_body_filter钩子，作用域仅限于响应体编码 - 所谓“边缘节点加解密前预处理”，如果指客户端密钥协商或服务端私钥操作，Nginx 根本不暴露该层面的接口
如果你实际想做的是「压缩后再由边缘节点统一 TLS 终结」
这是常见且可行的架构：源站输出 brotli 压缩内容 → CDN 或边缘 Nginx 接收 → 直接转发（不重新压缩）→ TLS 终结。关键点在于避免二次压缩和 MIME 类型错配：
- 确保源站响应头包含
Content-Encoding: br，且Content-Type是可压缩类型（如text/html、application/json） - 边缘 Nginx 必须禁用自身压缩：设置
brotli off和gzip off，否则可能触发重复压缩或 header 冲突 - 确认边缘节点透传
Content-Encoding：默认会透传，但若启用了proxy_buffering on且未配置proxy_buffering off，某些旧版 Nginx 可能误删该 header - 客户端必须声明支持：
Accept-Encoding: br, gzip；若边缘节点看到请求不含br，就不能返回 brotli 压缩内容
如果真需要在边缘做加解密相关预处理（比如 JWT 校验、请求体解密）
那和 brotli 完全无关，应使用 Nginx 的其他模块，且必须明确阶段：
- 解密请求体（如 AES-GCM 加密的 payload）：需在
access_by_lua_block（OpenResty）或auth_request子请求中完成，且要求请求体已读入内存（client_body_buffer_size足够大，client_max_body_size合理） - 加密响应体：只能在输出过滤阶段（
body_filter_by_lua_block）中实现，但此时brotli已执行完毕——二者不可叠加，必须二选一：要么先加密再压缩（不推荐，破坏压缩率），要么先压缩再加密（需自定义 filter，Nginx 官方不提供） - 注意：TLS 层加解密永远由 OpenSSL 处理，Nginx 仅配置证书和协议版本，无法插入自定义密码逻辑
真正容易被忽略的是：Brotli 压缩是否生效，不取决于你开了 brotli on，而取决于客户端 Accept-Encoding、服务端 MIME 类型白名单、响应体大小（默认 brotli_min_length 20）、以及是否被缓存或代理提前截断了 header。别在加解密场景里强行套用 brotli，它压根不在那个数据平面里。
