Nginx反向代理旧版Java后端时SSL握手失败，根本原因是TLS版本不兼容：Java旧版本（如JDK 7u95或JDK 8u31前）仅默认支持TLSv1/TLSv1.1，而现代Nginx默认启用TLSv1.2+并禁用低版本；需在proxy_pass作用域内精准配置proxy_ssl_protocols（如TLSv1 TLSv1.1）、匹配弱加密套件、启用proxy_ssl_server_name，并仅在可信内网临时禁用证书校验。
当 Nginx 作为反向代理访问旧版 Java 后端（如 JDK 7u95 或 JDK 8u31 之前版本）时，常因 TLS 协议不兼容导致 SSL handshake failed。根本原因是：Java 旧版本默认仅支持 TLSv1 和 TLSv1.1，而现代 Nginx（尤其搭配新版 OpenSSL）默认启用 TLSv1.2+ 并禁用低版本协议，双方无法协商出共同支持的 TLS 版本。
确认 Java 后端实际支持的 TLS 版本
不要依赖文档推测，直接验证后端能力：
- 用
openssl s_client测试握手兼容性：openssl s_client -connect your-java-backend:8443 -tls1（尝试 TLSv1）openssl s_client -connect your-java-backend:8443 -tls1_1（尝试 TLSv1.1）
若其中某条命令能完成握手并打印证书，说明该版本被支持；-tls1_2失败则基本确认后端不支持 TLSv1.2。 - 检查 Java 启动参数是否显式限制了协议，例如：
-Dhttps.protocols=TLSv1或-Djdk.tls.client.protocols=TLSv1—— 这会强制只用 TLSv1。
在 proxy_pass 块中精准配置 proxy_ssl_protocols
该指令控制 Nginx **作为客户端**连接上游时使用的 TLS 版本，必须与 Java 后端对齐。不能全局修改 ssl_protocols（那是给客户端连 Nginx 用的），要限定在 upstream 或 location 内：
- 若后端仅支持 TLSv1：
proxy_ssl_protocols TLSv1; - 若支持 TLSv1 和 TLSv1.1（常见于 JDK 8u60 以前）：
proxy_ssl_protocols TLSv1 TLSv1.1; - 避免写
TLSv1.2或更高版本，否则握手必然失败。
⚠️ 注意：Nginx 1.19.4+ 默认已移除 TLSv1 支持，如需启用，需确保编译时 OpenSSL ≥ 1.0.1 且未禁用旧协议；CentOS 7 默认 OpenSSL 1.0.2k 通常满足要求。
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
立即学习“Java免费学习笔记（深入）”；
配套关键配置不可遗漏
仅调 proxy_ssl_protocols 不够，还需同步调整加密套件和 SNI：
-
匹配弱加密套件：旧 Java 默认不支持 AEAD 套件（如 AES-GCM）。添加：
proxy_ssl_ciphers 'ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA';
（RC4 已不安全，仅临时调试用；生产环境优先选 AES128-SHA） -
确保 SNI 正确传递：若后端是多域名共用 IP 的 HTTPS 服务（如 Spring Boot + Tomcat 配了 SNI 证书），必须开启：
proxy_ssl_server_name on;<br>proxy_ssl_name $host;
-
跳过证书校验（仅限内网可信环境）：
proxy_ssl_verify off;
避免因自签名、过期或链不全引发二次失败。
验证与回滚建议
修改后 reload 并观察日志：
- 检查 Nginx error log 是否仍有
SSL_do_handshake() failed或no protocols available类错误； - 用
curl -v --proxy-insecure https://nginx-proxy/api看响应是否成功； - 若仍失败，临时改用
http://测试——若 HTTP 成功，则 100% 是 TLS 层问题； - 长期方案应升级 Java 运行时（JDK 8u161+ / JDK 11+ 默认启用 TLSv1.2），而非维持脆弱的旧协议。
