java 6客户端仅支持tlsv1，需在nginx中针对其user-agent精确启用tlsv1、兼容套件及rsa证书，并禁用ocsp和session tickets以确保握手成功。
Java 6 客户端（如 JDK 6u45 或更早）根本无法协商 TLSv1.2 及以上版本，因为其 SSL/TLS 实现完全不包含对应协议栈。当它尝试连接现代 Nginx（默认仅启用 TLSv1.2+）时，握手会在 ClientHello 阶段就失败——Nginx 收到不支持的协议请求后直接中断，日志中常见 ssl handshake failed 或 no protocols available。修复核心不是“升级 Java”，而是让 Nginx 在服务该类客户端时，主动降级并精确开放兼容协议。
确认 Java 6 的真实 TLS 能力
不要依赖文档或推测。直接用 Java 6 自带的 java 命令验证：
- 运行：
java -Dhttps.protocols=TLSv1 -Djavax.net.debug=ssl:handshake -jar test-client.jar https://your-nginx-domain/，观察是否完成握手； - 若失败，再试
TLSv1.1（极少数打过补丁的 JDK 6u141 可能支持）； - 几乎可以确定：Java 6 仅支持 TLSv1，且不支持 SNI、AEAD 加密套件（如 AES-GCM）、ECC 证书等现代特性。
在 server 块中精准启用 TLSv1（仅限该客户端）
不能全局放开低版本协议影响其他用户。应在匹配 Java 6 请求的 location 或通过 User-Agent 区分的条件下配置：
- 添加条件判断（例如识别 Java 6 的典型 UA）：
if ($http_user_agent ~* "Java/1\.6\.0") { set $java6_client "1"; }； - 在对应 location 中写：
ssl_protocols TLSv1;（注意是ssl_protocols，不是proxy_ssl_protocols，因为这是 Nginx 作为服务端响应客户端）； - 禁用所有高版本：不要写成
TLSv1 TLSv1.1 TLSv1.2，否则 Java 6 仍会因协议列表不匹配而失败； - 确保 OpenSSL 编译时未移除 TLSv1 支持（CentOS 7 默认 OpenSSL 1.0.2k 满足，但 Nginx 1.19.4+ 需确认编译参数）。
配套调整加密套件与证书行为
TLSv1 协议下，Java 6 只能使用传统非 AEAD 套件，且对证书链和签名算法敏感：
- 指定兼容套件：
ssl_ciphers 'ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA';（RC4 仅调试用，生产环境应避免）； - 禁用不兼容项：
ssl_prefer_server_ciphers on;确保服务端优先选择； - 使用 RSA 签名证书（非 ECDSA），且根证书需为 SHA-1 或 SHA-256（Java 6 不支持 SHA-384+）；
- 禁用 OCSP Stapling 和 TLS Session Tickets：
ssl_stapling off; ssl_session_tickets off;，避免 Java 6 解析异常。
验证与隔离建议
上线前必须做最小闭环验证：
- 用 Java 6 环境直连 Nginx：
curl -v --tlsv1 https://your-domain/，确认返回 200 且无 alert； - 同时用 Chrome/Firefox 访问同一域名，确认它们仍走 TLSv1.2+（检查 DevTools → Security 标签页）；
- 将 Java 6 流量路由到独立 server 块或子域名（如
legacy-api.example.com），避免混用配置； - 记录访问日志中的 TLS 版本：
log_format tls_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_protocol $ssl_cipher';。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
