关键在于精准匹配java微服务实际支持的tls版本：先用openssl s_client实测-tls1/-tls1_1/-tls1_2握手能力；再在proxy_pass块中配置proxy_ssl_protocols（如tlsv1），禁用tlsv1.2+；同步启用proxy_ssl_server_name、指定proxy_ssl_name，并调整ssl_ciphers适配旧套件。
要解决 Nginx 与旧版 Java 微服务之间因 TLS 协议不兼容导致的握手失败（如 502、SSL handshake failed），关键不是全局调协议，而是让 Nginx 在 作为客户端连接上游时 使用微服务实际支持的 TLS 版本。这由 proxy_ssl_protocols 控制，必须精准匹配，不能靠猜。
第一步：实测后端真实支持的 TLS 版本
别信文档或 JDK 版本推测，直接用 openssl 验证：
-
openssl s_client -connect your-microservice:8443 -tls1→ 若成功打印证书和 Verify return code: 0，说明支持 TLSv1 -
openssl s_client -connect your-microservice:8443 -tls1_1→ 同理测试 TLSv1.1 -
openssl s_client -connect your-microservice:8443 -tls1_2→ 若报错ssl3 alert handshake failure或连接立即关闭，基本确认不支持 TLSv1.2
常见情况：JDK 7 或 JDK 8u60 以前的微服务往往只支持 TLSv1，个别支持到 TLSv1.1；JDK 8u161+ 默认启用 TLSv1.2，但若启动参数里写了 -Dhttps.protocols=TLSv1，仍会强制降级。
第二步：在 proxy_pass 上下文中配置 proxy_ssl_protocols
该指令只对 upstream 连接生效，不能写在 http/server 块里，否则无效。根据实测结果选择对应配置：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 仅支持 TLSv1：
proxy_ssl_protocols TLSv1; - 支持 TLSv1 和 TLSv1.1：
proxy_ssl_protocols TLSv1 TLSv1.1; - 禁用 TLSv1.2 及更高版本——哪怕 Nginx 默认启用，也必须显式排除，否则握手必败
注意：Nginx 1.19.4+ 默认已移除 TLSv1 支持。如需启用，需确认编译时 OpenSSL ≥ 1.0.1（CentOS 7 的 1.0.2k 通常满足）且未加 --without-openssl 等禁用选项。
第三步：同步调整加密套件与 SNI 行为
光调协议不够，旧版 Java 默认不支持 AEAD 类套件（如 AES-GCM），还可能依赖 SNI 才能选对证书：
- 匹配弱套件（临时调试可用）：
proxy_ssl_ciphers 'ECDHE-RSA-AES128-SHA:AES128-SHA';（避免 RC4，生产环境禁用） - 若微服务启用了 SNI（例如 Spring Boot + Tomcat 配了多个域名证书），必须开启：
proxy_ssl_server_name on; - 同时指定 SNI 域名：
proxy_ssl_name "your-service-domain.com";（upstream 场景下不可省略，不能只靠 $host） - 若证书非权威 CA 签发或自签，需临时关闭校验：
proxy_ssl_verify off;（上线前务必推动证书更新）
第四步：验证与日志定位
配置后 reload，重点看 error.log：
- 出现
SSL_do_handshake() failed或tlsv1 alert internal error→ 多为 SNI 缺失或协议/套件不匹配 - 出现
peer closed connection in SSL handshake→ 常见于协议版本被拒绝（如发了 TLSv1.2 给只认 TLSv1 的服务） - 开启 debug 日志（需 Nginx 编译含
--with-debug）可精准看到协商使用的协议和 SNI 值
最终验证方式：用 openssl s_client -connect ... -servername ... 模拟 Nginx 行为，确保能稳定完成握手并返回正确证书。
