网关崩溃主因是Brotli模块未真正加载或编译，导致Nginx处理br请求时触发空指针或非法调用而segfault；需依次验证nginx -V含--with-http_brotli_module、load_module正确配置且.so存在可读、ldd确认libbrotlidec.so.1链接正常。
网关崩溃往往不是 Brotli 本身出错，而是模块加载失败后，Nginx 在处理带 Accept-Encoding: br 的请求时触发未定义行为——比如访问空指针、调用不存在的函数，最终导致 worker 进程 segfault，主进程反复拉起又崩溃，表现为服务不可用或 502/503 频发。
确认模块是否真正编译进 Nginx
模块未编译是最隐蔽的根源：配置写了 brotli on，但 Nginx 根本不认识这个指令，也不报错，直到某次请求触发内部调用才崩。
- 运行
nginx -V 2>&1 | grep --with-http_brotli_module，有输出才说明编译时启用了该模块 - 若无输出，说明当前二进制不支持 Brotli，需重新编译或换用 OpenResty 1.25+ 等集成版本
- 注意：仅安装
libbrotli-dev或源码编译了 Brotli 库，不等于 Nginx 就支持它
验证动态模块是否成功加载
即使编译了模块，若没正确加载，Nginx 启动时不会报错，但运行时一用就挂。
- 检查配置文件中是否存在
load_module modules/ngx_http_brotli_filter_module.so;，且必须写在events块之前 - 确认该
.so文件真实存在：ls -l $(nginx -V 2>&1 | grep "prefix" | awk '{print $2}')/modules/ngx_http_brotli_filter_module.so - 检查文件权限：属主需为 Nginx 运行用户（如
nginx），且至少具备可读可执行（-r-x）
定位崩溃是否由 Brotli 模块引发
不要只看日志里有没有 “brotli” 字样——关键要看崩溃现场是否关联到该模块。
- 查错误日志：
tail -n 50 /var/log/nginx/error.log，搜索segmentation fault、core dumped、signal 11 - 若日志中同时出现
ngx_http_brotli_filter_module或brotlidec相关路径，基本可锁定 - 进一步验证：临时注释掉所有 Brotli 配置（
brotli on、brotli_static等），再nginx -t && systemctl reload nginx，观察是否恢复稳定
检查运行时依赖库是否就绪
Brotli 模块是动态链接的，若其依赖的 libbrotlidec.so.1 在运行时找不到，worker 进程加载模块时可能静默失败或崩溃。
- 用
ldd检查模块是否链接正常：ldd $(nginx -V 2>&1 | grep "prefix" | awk '{print $2}')/modules/ngx_http_brotli_filter_module.so | grep brotli - 若显示
not found，说明运行时库缺失；此时即使nginx -t成功，启动后也可能崩 - 补救方式：将 Brotli 库路径加入系统缓存（
echo "/opt/brotli/lib" > /etc/ld.so.conf.d/brotli.conf && ldconfig）或通过LD_LIBRARY_PATH临时指定
