关键在于验证Brotli模块与Nginx主程序的ABI对齐：需比对二者NGINX_VERSION数字（如1024000）、检查load_module是否真实加载、确认ldd依赖版本一致，并通过curl验证Content-Encoding: br响应头。
排查 Brotli 模块与 Nginx 主程序版本不匹配，关键不是看“有没有加载”，而是验证二者在编译期 ABI 层是否真正对齐——因为 Brotli 模块（ngx_brotli_module）是静态或动态链接进 Nginx 的，一旦版本号、结构体布局或符号导出不一致，就会在启动时静默失败或运行中崩溃。
检查模块内嵌的 NGINX_VERSION 是否一致
Brotli 模块在编译时会将当前 Nginx 版本硬编码进二进制，若与运行中的 Nginx 主程序版本不符，nginx -t 可能不报错，但模块实际未生效。需手动提取比对：
- 查 Nginx 主程序版本数字：
nginx -V 2>&1 | grep "built by" | grep -oE 'nginx/[0-9]+\.[0-9]+\.[0-9]+' | sed 's/nginx\///' | awk -F. '{printf "%d%02d%02d", $1,$2,$3}'（例如1024000表示 1.24.0） - 查 Brotli 模块内嵌版本：
strings /path/to/ngx_http_brotli_filter_module.so | grep -E 'NGINX_VERSION|1[0-9]{5,}'或更准：objdump -t /path/to/ngx_http_brotli_filter_module.so | grep nginx_version - 两者输出必须完全相同；差一位（如
1024000vs1025000）即不兼容，不能混用
确认模块是否被真正加载且无符号冲突
即使配置写了 load_module，模块也可能因 ABI 不匹配被跳过或引发段错误：
- 执行
nginx -t -v（加-v显示详细加载过程），观察是否打印loading module "/path/to/ngx_http_brotli_filter_module.so" - 若没出现该行，说明模块路径错误、权限不足，或版本校验失败后被内核拒绝加载
- 用
nm -D /path/to/ngx_http_brotli_filter_module.so | grep ngx_http_brotli确认核心符号存在；若大量U（undefined）开头的符号（如U ngx_http_top_body_filter），说明模块编译时所依赖的 Nginx 头文件版本偏低
验证运行时行为是否符合预期
版本匹配 ≠ 功能可用。最终要落到真实请求响应上：
- 发起带
Accept-Encoding: br的请求：curl -H "Accept-Encoding: br" -I https://yoursite.com/style.css - 检查响应头是否有
Content-Encoding: br，且Content-Length显著小于未压缩值（Brotli 压缩率应比 Gzip 高 15–20%） - 若返回
Content-Encoding: gzip或无压缩头，且配置中已明确关闭gzip on并启用brotli on，大概率是模块未加载成功，根源仍在版本不匹配
排除 OpenSSL 和 zlib 等底层依赖错位
Brotli 模块依赖 libbrotlienc，而 Nginx 主程序又依赖 OpenSSL/zlib —— 若模块编译时链接了旧版 libbrotlienc.so.1，但系统运行时加载的是新版 libbrotlienc.so.2，会导致 undefined symbol: BrotliEncoderCreateInstance 类错误：
- 运行
ldd /path/to/ngx_http_brotli_filter_module.so | grep brotli，确认链接路径正确且版本号匹配 - 对比
nginx -V中的--with-zlib=...路径，确保 Brotli 模块编译时使用的 zlib 头文件与主程序一致（尤其涉及内存操作函数） - 若使用自定义 OpenSSL，务必保证 Brotli 模块和 Nginx 主程序都用同一份
--with-openssl=编译，否则 TLS 握手阶段可能因结构体偏移错乱而崩溃
