开启brotli后nginx内存飙升主因是配置不当导致的非线性内存增长，而非模块泄漏；需重点检查压缩级别、响应类型、静态文件处理、请求特征及版本兼容性，并通过降级验证归因。
开启 Brotli 后 Nginx 内存飙升，往往不是模块本身“泄漏”，而是压缩行为在特定配置或流量下触发了内存的非线性增长。排查重点不在找“Brotli 内存泄漏代码”，而在识别它如何被不当使用、放大资源消耗。
检查 Brotli 相关配置是否引发高频/大块内存分配
Brotli 压缩比高，但代价是 CPU 和内存开销显著高于 gzip，尤其在高压缩级别或处理大响应体时：
- 确认
brotli_comp_level是否设为过高的值（如 11）——建议生产环境用 4~6，级别每+1，内存峰值可能翻倍 - 检查
brotli_types是否包含易产生大响应的内容类型（如application/json、text/html），若后端返回未分块的 5MB JSON，Brotli 会尝试全量缓冲再压缩，极易撑爆 worker 内存池 - 确认未启用
brotli_static on却又大量提供静态资源 —— 动态压缩每个请求，比预压缩复用消耗高数倍内存
观察内存增长是否与特定请求强相关
Brotli 的内存压力通常有明显请求特征，需联动日志分析：
- 在
access.log中筛选含brotli的响应头（如$sent_http_content_encoding），再按$request_time和$body_bytes_sent排序，找出响应体 >2MB 且耗时 >1s 的请求 - 对比这些请求发生时段的
error.log：是否同步出现pool alloc日志激增、upstream timed out或worker process X exited on signal 9 - 特别关注 User-Agent 为爬虫或自动化工具的请求——它们常不支持 Brotli 却仍发起 Accept-Encoding 请求，导致 Nginx 白做压缩后又丢弃
验证是否因 Brotli 模块与 Nginx 版本/编译参数不兼容
不匹配的构建环境会导致内存管理异常，而非单纯性能差：
- 运行
nginx -V，确认版本 ≥ 1.9.11，且 configure 参数中明确包含--add-module=/path/to/ngx_brotli（不是--with-http_brotli_module，后者不存在） - 检查是否启用了
--with-debug编译，若启用，error.log中会出现大量ngx_palloc、ngx_pcalloc调用痕迹，可辅助判断是否某类响应反复创建大内存池 - 若使用动态模块（.so），确认加载顺序：Brotli filter 必须在
gzip之后、chunked之前，否则可能触发重复缓冲或内存拷贝
临时隔离验证与降级方案
快速止血并确认因果关系：
- 注释掉所有
brotli_*指令，reload 配置，观察内存曲线是否回归基线 —— 这是最直接的归因证据 - 若必须保留 Brotli，可先关闭对大响应体的压缩：
brotli_types text/plain text/css application/javascript;，排除 JSON/HTML 等高风险类型 - 设置硬性限制：
proxy_buffering off;（配合proxy_max_temp_file_size 0;）可避免代理场景下 Brotli 与 proxy buffer 双重内存叠加
