nginx启动失败报libssl.so.1.1找不到，本质是运行时库路径未被系统识别；需通过ldd确认缺失库、readelf查runpath、验证新版库存在后，优先用ldconfig配置或patchelf修复rpath，再排除软链冲突与selinux干扰。
升级 SSL 库（如 OpenSSL）后 Nginx 启动失败，报错类似 error while loading shared libraries: libssl.so.1.1 或 libcrypto.so.1.1: cannot open shared object file，本质是 Nginx 二进制在运行时找不到新版动态库——不是没装，而是“看不见”。关键不在重装，而在让系统正确发现并加载它。
确认 Nginx 实际依赖的库版本和路径
先搞清它到底要什么：
- 运行
ldd $(which nginx) | grep ssl，看输出中缺失的是哪个库（如libssl.so.1.1）、是否显示not found，以及已找到的库来自哪条路径（比如/usr/local/openssl/lib/） - 用
readelf -d $(which nginx) | grep RUNPATH或objdump -x $(which nginx) | grep RUNPATH查看 Nginx 编译时硬编码的运行时库搜索路径（RUNPATH），这比环境变量更优先 - 执行
openssl version -a和pkg-config --modversion openssl，对比命令行可用版本与 Nginx 所需版本是否一致
检查新版库是否真实存在且可被定位
别只信 find /usr -name "libssl.so*" 的结果，要验证：
- 进入新版 OpenSSL 安装目录（如
/usr/local/openssl-1.1.1w/lib），确认libssl.so.1.1和libcrypto.so.1.1文件存在、非空、权限为644或755 - 检查是否存在符号链接断裂：运行
ls -l /usr/local/openssl/lib/libssl.so*，确保libssl.so.1.1指向的源文件（如libssl.so.1.1.1w）真实存在 - 若新版库放在非标准路径（如
/opt/openssl/lib），系统默认不会搜这里——必须显式加入搜索范围
让系统“看见”新库的三种可靠方式
按优先级从高到低选择一种：
-
写入 ldconfig 配置（推荐）：新建
/etc/ld.so.conf.d/openssl-1.1.1w.conf，内容只有一行：/usr/local/openssl-1.1.1w/lib；然后执行sudo ldconfig -v | grep ssl确认生效 -
设置 RUNPATH（编译时更优，升级后补救也可）：若你控制 Nginx 编译过程，configure 时加
--with-ld-opt="-Wl,-rpath,/usr/local/openssl-1.1.1w/lib"；若已编译，可用 patchelf 工具临时修复：patchelf --set-rpath "/usr/local/openssl-1.1.1w/lib" $(which nginx) -
临时环境变量（仅调试）：启动前设
LD_LIBRARY_PATH=/usr/local/openssl-1.1.1w/lib:$LD_LIBRARY_PATH，但 systemd 服务中需在 service 文件里用Environment=LD_LIBRARY_PATH=...，不建议长期使用
排除常见干扰项
这些看似无关的操作常掩盖真正问题：
- 删掉旧版 OpenSSL 的残留软链（如
/usr/lib64/libssl.so.1.1指向已卸载的老版本），避免系统误加载 - 检查 SELinux 是否拦截：CentOS/RHEL 上执行
ausearch -m avc -ts recent | grep nginx，若看到open或read被拒绝，临时设setenforce 0测试是否恢复 - 确认 Nginx 不是静态链接的（
file $(which nginx)输出含statically linked则不受动态库路径影响，此时报错另有原因）
