检查Nginx模块符号导出，核心是确认动态模块是否正确定义所需函数符号，避免缺失、重定义或ABI不匹配；需用nm/objdump查看.so导出符号，比对nginx与模块的OpenSSL符号一致性，并用strace/LD_DEBUG定位运行时加载问题。
检查 Nginx 模块的符号导出，核心是确认模块（尤其是动态模块 `.so` 文件）是否正确定义并导出了所需函数符号，避免因符号缺失、重定义或 ABI 不匹配导致加载失败或运行时崩溃——这在排查 SSL、GeoIP2、RTMP 等第三方模块异常时尤为关键。
查看动态模块导出的公开符号
使用 objdump 或 nm 工具直接读取 `.so` 文件的动态符号表：
-
列出所有导出的全局符号（含函数和变量）：
nm -D /usr/lib/nginx/modules/ngx_http_geoip2_module.so -
只显示与 SSL 相关的符号（如调试 TLS 模块冲突）：
objdump -T /usr/lib/nginx/modules/ngx_http_ssl_module.so | grep -i "ssl\|tls" -
检查是否导出模块入口函数（每个 Nginx 动态模块必须提供
ngx_module_t ngx_http_xxx_module）：nm -D your_module.so | grep -E "(ngx_http_|ngx_stream_)module$"
验证 Nginx 主程序链接的 OpenSSL 符号一致性
SSL 模块故障常源于主程序与动态模块对 OpenSSL 符号的引用不一致。需比对两者依赖的符号版本：
-
查 Nginx 二进制实际链接的 OpenSSL 库及符号需求：
ldd $(which nginx) | grep sslobjdump -T $(which nginx) | grep -i "SSL_get_version\|SSL_CTX_new" -
查目标模块所依赖的 OpenSSL 符号（尤其注意版本后缀）：
objdump -T /path/to/module.so | grep -i "SSLv2_client_method\|SSL_get0_alpn_selected"
若出现version OPENSSL_1_1_0 not defined，说明模块编译时用的 OpenSSL 头文件与当前系统库 ABI 不兼容
检测符号冲突：多个模块重复导出同一符号
当多个动态模块（如自编译的 `nginx-rtmp-module` 和 `headers-more-nginx-module`）都封装了 OpenSSL 调用，可能同时导出 SSL_CTX_new，引发 dlopen 冲突：
-
批量检查多个模块是否导出相同敏感符号：
for m in /usr/lib/nginx/modules/*.so; do echo "== $m =="; nm -D "$m" 2>/dev/null | grep -w "SSL_CTX_new\|sk_SSL_CIPHER_num"; done -
运行时捕获符号加载错误：
LD_DEBUG=symbols,bindings nginx -t 2>&1 | grep -i "SSL_CTX_new"
可观察该符号是从哪个 `.so` 中首次绑定，后续重复绑定会触发警告
结合 nginx -t 和 strace 定位加载阶段符号问题
仅靠静态分析不够，需观察运行时行为：
-
用 strace 跟踪模块 dlopen 过程中的 open 和 symbol 查找：
strace -e trace=openat,open,openat64,bind -f nginx -t 2>&1 | grep -i "\.so\|ssl" -
若 nginx -t 报错 “undefined symbol: XXX”，说明该符号未被任何已加载模块导出——此时应检查：
• 对应 OpenSSL 库是否已安装且路径在LD_LIBRARY_PATH中
• 模块是否为 x86_64 编译却运行在 arm64 环境（架构不匹配导致符号不可见）
