PHP中SSL/TLS握手失败多数因OpenSSL版本不一致导致底层能力断层，需查php -i中“OpenSSL Library Version”（非Header Version），确认是否≥1.1.1；检查openssl_get_cipher_methods()是否含tls1_3；区分CLI与Web环境php.ini配置；升级时须重编译PHP并指定--with-openssl路径，避免ABI不兼容。
PHP中SSL/TLS握手失败，多数情况不是代码问题，而是OpenSSL版本不一致引发的底层能力断层——比如PHP编译时链接的是OpenSSL 1.0.2，但运行时系统已升级到3.4；或CLI和Web服务器加载了不同版本的openssl扩展。这种不一致会导致协议支持错位、加密套件不可用、甚至符号缺失报错。
确认PHP实际使用的OpenSSL版本
别只看openssl version命令输出，要查PHP自己绑定的库：
- 运行
php -i | grep -i "openssl library version"，重点看这一行（不是Header Version） - 若显示
OpenSSL Library Version => 1.0.2u，说明不支持TLS 1.3，且对现代加密套件兼容性差 - 运行
php -r "print_r(openssl_get_cipher_methods());"，检查输出是否含tls1_3或aes-256-gcm等关键词 - 若
OPENSSL_VERSION_TEXT为空或为OpenSSL 1.0.1e类旧值，基本可判定为版本老化
区分CLI与Web环境的配置差异
Apache、Nginx + PHP-FPM 和命令行PHP往往加载不同的php.ini，极易造成“网页能连HTTPS、Composer却报错”的现象：
- 执行
php --ini查看CLI加载的配置路径，记下“Loaded Configuration File” - 在Web环境中访问
phpinfo()页面，搜索“Loaded Configuration File”，对比路径是否一致 - 常见陷阱：Ubuntu下
/etc/php/8.2/cli/php.ini和/etc/php/8.2/apache2/php.ini是两个独立文件，需分别启用extension=openssl - Windows用户注意
php.ini-production和php.ini-development可能被重命名，php --ini才是唯一可信来源
修复ABI不兼容与动态库链接问题
升级系统OpenSSL后PHP报undefined symbol: SSL_CTX_set_max_proto_version，说明PHP是旧版OpenSSL编译的，却试图调用新版符号：
立即学习“PHP免费学习笔记（深入）”；
- 不要直接覆盖系统OpenSSL（尤其CentOS/RHEL），推荐多版本共存：编译安装OpenSSL 1.1.1+到
/usr/local/openssl1.1 - 编辑
/etc/ld.so.conf追加/usr/local/openssl1.1/lib，再运行ldconfig - 重新编译PHP时，必须指定
--with-openssl=/usr/local/openssl1.1，不能只写--enable-openssl - Docker中Alpine用户需显式安装：
RUN apk add openssl-dev && docker-php-ext-install openssl
强制TLS版本与验证CA证书路径
即使OpenSSL版本达标，仍可能因协商失败或证书链失效导致握手中断：
- cURL请求中加入
CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2，临时绕过TLS 1.3协商缺陷 - 检查
openssl.cafile配置：php -r "echo ini_get('openssl.cafile');"，若为空或路径无效，需手动设置（如openssl.cafile=/etc/ssl/certs/ca-certificates.crt） - 用
openssl s_client -connect example.com:443 -tls1_2 -servername example.com直连测试，观察Protocol和Cipher是否正常返回 - 若输出含
verify error:num=20:unable to get local issuer certificate，说明中间证书未下发或CA文件过期
