模块冲突导致nginx崩溃典型表现为worker反复退出、nginx -t静默失败、日志出现segmentation fault或undefined symbol，根源在符号重定义、内存覆盖或初始化错乱，需通过注释load_module、比对nginx_version、检查ldd依赖、strace加载顺序及nm符号导出等方式分层定位。
模块冲突导致 Nginx 核心崩溃，典型表现是 worker 进程反复退出、nginx -t 静默失败、错误日志中出现 Segmentation fault、undefined symbol 或 core dumped。这类问题不报明确错误，根源往往藏在符号重定义、内存结构覆盖或初始化顺序错乱中。排查需跳过猜测，直接分层验证。
确认是否真由模块引发崩溃
先排除配置、资源、SSL 证书等干扰因素：
- 临时注释
nginx.conf中所有load_module指令，只保留 Nginx 默认模块，执行nginx -t && nginx -s reload，确认基础服务能稳定运行 - 检查错误日志：
tail -n 50 /var/log/nginx/error.log，搜索segment、core dumped、double free、invalid pointer等关键词 - 若日志中出现类似
dlopen() "/path/to/module.so" failed: undefined symbol: ngx_http_upstream_create，说明模块依赖的核心符号未导出，大概率是加载顺序或编译环境不一致
比对模块与 Nginx 的 ABI 兼容性
两个第三方模块之间、或模块与当前 Nginx 二进制之间 ABI 不匹配，是冲突高发原因：
- 用
nginx -V查看完整编译参数，重点记录--with-openssl、--with-pcre、--with-zlib路径，以及built by（GCC 版本）和built with（OpenSSL 版本） - 对每个模块执行：
objdump -T module.so | grep nginx_version和strings module.so | grep "NGINX_VERSION"，提取内嵌版本号（如1024000对应1.24.0），必须与nginx -V输出的版本数字完全一致 - 运行
ldd module1.so和ldd module2.so，检查是否链接了不同路径或版本的libssl.so、libpcre.so；若有差异，说明 OpenSSL 或正则库层面已存在 ABI 冲突
定位加载时的符号覆盖或钩子冲突
某些模块会重定义全局函数（如 SSL_CTX_new）、篡改 ngx_http_phases 数组、或修改 upstream 结构体布局，造成运行时踩内存：
- 启用
strace观察加载行为：strace -e trace=openat,open,openat64 nginx -t 2>&1 | grep '\.so$'，确认两个模块是否被实际加载，以及加载顺序是否符合预期 - 若报错含
relocation error: symbol SSLv2_client_method version OPENSSL_1_1_0 not defined，说明一个模块使用旧版 OpenSSL 符号，而当前 Nginx 链接的是 OpenSSL 3.x —— 必须统一 OpenSSL 版本并重编两个模块 - 若崩溃堆栈指向
ngx_http_script_flush_complex_value等函数，且出现在第三方模块调用链中，基本可锁定该模块对 HTTP 脚本引擎的非法操作
获取并分析 core dump 定位具体代码位置
仅靠日志无法判断哪行 C 代码越界，必须依赖崩溃现场：
- 确保开启 core dump：
ulimit -c unlimited，并在nginx.conf的 main 块中设置working_directory /var/coredump;（路径需存在且 nginx 用户可写） - 用
gdb $(which nginx) /var/coredump/core.xxx加载 core 文件，执行bt full查看完整堆栈，重点关注 third-party 模块函数调用链 - 若堆栈显示在
ngx_http_lua_*或fastdfs_*函数内崩溃，基本可锁定模块；若出现在SSL_do_handshake或CRYPTO_add_lock，大概率是 OpenSSL 层兼容问题
