核心是厘清模块初始化顺序与共享库符号加载顺序冲突；错误表现为启动失败、指令未识别、段错误或功能静默失效，需通过nginx -v确认编译、objs/ngx_modules.c验证位置、ldd/objdump检查依赖库版本匹配，并用nginx -e stderr直出终端错误定位第一现场。
排查 Nginx 模块依赖库动态加载顺序错，核心是厘清“模块初始化顺序”和“共享库符号加载顺序”两个层面的冲突。错误表现常为启动失败、指令未识别、段错误或功能静默失效，而非直接报“顺序错”。关键不在于日志里找“顺序”二字，而在于验证依赖是否就位、符号是否可解析、初始化是否按需触发。
查清模块是否真被编译并注册
很多所谓“顺序问题”，根源其实是模块压根没进系统：
- 运行 nginx -V 2>&1 | grep -i "with-\|add-module"，确认目标模块（如 brotli、lua、stream）出现在编译参数中；若无，说明未参与编译，后续所有顺序讨论都无效
- 检查 objs/ngx_modules.c 文件，搜索模块名（如 &ngx_http_brotli_filter_module），看它是否在 ngx_modules[] 数组中、位置是否符合预期（应在 HTTP 框架模块之后、&ngx_http_write_filter_module 之前）
- 对动态模块（.so），确认 load_module 指令写在 events 和 http 块之外，并且路径正确；nginx -t 会校验文件是否存在，但不会校验符号兼容性
验证运行时依赖库是否就位且版本匹配
模块能加载 ≠ 依赖库能解析。常见错位发生在 OpenSSL、PCRE、Brotli 等底层库上：
- 用 ldd /path/to/module.so | grep -i brotli\|ssl\|pcre 查看模块依赖的 .so 是否全部 resolved；出现 not found 表示库缺失或路径未纳入系统搜索范围
- 对比 ldd $(which nginx) | grep ssl 和模块的 ldd 输出：若 nginx 链的是 libssl.so.1.1，而模块链接的是 libssl.so.3，即 ABI 不兼容，必然触发 undefined symbol 错误
- 用 objdump -T /usr/lib/x86_64-linux-gnu/libssl.so.1.1 | grep SSL_get0_alpn_selected 确认报错中缺失的符号是否真实存在于该库中；若不存在，说明库版本太低或模块编译时用了错误头文件
观察初始化时序与符号冲突线索
error_log 本身不记“谁先谁后”，但能暴露顺序错导致的典型症状：
- 启用 error_log /path/to/error.log debug;（仅调试阶段），启动后搜 "init_module"，看模块 init 调用是否按你期望的 ctx_index 递增；若某模块 init 日志完全缺失，很可能是其依赖模块（如 geoip2 依赖的 core 模块）未初始化成功就退出了
- 注意报错关键词："module is not binary compatible" 多因依赖模块未加载或版本不匹配；"undefined symbol: SSL_CTX_new" 表明 OpenSSL 符号未导出或被其他模块覆盖；"write filter must be last" 是明确的数组顺序硬约束违反
- 对疑似冲突的第三方模块（如 rtmp、headers-more），临时注释掉 load_module 行，单独测试 SSL 或 Brotli 是否恢复工作；再逐个加回，定位引发冲突的具体模块
强制终端输出启动期错误，绕过日志系统盲区
模块加载失败常发生在日志子系统就绪前，error.log 可能为空。此时必须让错误直出：
- 执行 nginx -c /path/to/nginx.conf -e stderr，所有早期错误（包括 dlopen 失败、symbol not found、init_module 返回非零）都会打印到终端，这是定位“加载失败第一现场”的最可靠方式
- 配合 strace -e trace=openat,open,openat64 nginx -t 2>&1 | grep -i ssl，可看到 Nginx 实际尝试打开哪些 .so 文件，确认它是否在找错路径下的库
- 若用 systemd 启动，先停服务，改用上述命令手动运行，避免 unit 文件中的环境变量或权限设置掩盖真实问题
