Netty集成BoringSSL报SSLHandshakeException WRONG_VERSION_NUMBER错误问询

• 端口与服务端属性校验
  首先确认访问的服务端端口确实是TLS加密端口，避免错连明文端口。可通过openssl命令直接验证服务端TLS1.3握手可用性：

  openssl s_client -connect 服务端地址:端口 -tls1_3
  

  如果命令执行握手失败，说明问题出在服务端配置或网络链路，和客户端代码无关。
• TLS协议与加密套件兼容性校验
  你当前配置了多版本TLS协议，可先简化配置仅保留TLSv1.3，排除低版本协议协商干扰。同时补充TLS1.3兼容的加密套件配置，避免因服务端强制指定加密套件导致协商失败：

  return SslContextBuilder.forClient()
          .sslProvider(SslProvider.OPENSSL)
          .protocols("TLSv1.3")
          .ciphers(Http2SecurityUtil.CIPHERS, SupportedCipherSuiteFilter.INSTANCE)
          .trustManager(InsecureTrustManagerFactory.INSTANCE)
          .keyManager(privateKey, certChain)
          .build();
  

• SslHandler加载顺序校验
  确保SslHandler是管道中第一个被添加的处理器，避免业务处理器先接收到SSL握手报文导致解析失败。可在管道初始化后打印处理器顺序验证：

  System.out.println(ch.pipeline().names());
  

• SSL Provider实现校验
  你使用的是BoringSSL原生Provider，不依赖JDK原生JSSE实现，理论上JDK8/17都不影响，但如果 native 库加载失败会自动 fallback 到JDK SSLEngine，低版本JDK8确实不支持TLS1.3。可通过以下代码确认实际使用的Provider：

  // 确认OPENSSL Provider可用
  System.out.println(SslProvider.isAlpnSupported(SslProvider.OPENSSL));
  // 确认生成的SslContext是OpenSslContext实例
  System.out.println(sslCtx.getClass().getSimpleName());
  

  如果确实出现fallback情况，可升级netty-tcnative-boringssl-static到2.0.56.Final及以上版本，匹配操作系统架构。
• 链路中间代理校验
  如果请求经过反向代理、WAF、HTTP代理等中间节点，可能中间节点返回了明文错误报文（如HTTP错误页），导致OpenSSL解析时识别为非法TLS版本。可通过tcpdump/Wireshark抓包确认握手阶段返回的报文是否为标准TLS Server Hello报文。

1. 错连明文端口：更换为服务端正确的TLS加密端口即可
2. 协议协商失败：调整协议列表和加密套件匹配服务端要求
3. 处理器顺序错误：调整管道添加逻辑，保证SslHandler第一个加入管道
4. 原生库加载失败：升级netty-tcnative版本，匹配运行环境的操作系统和CPU架构
5. 中间代理拦截：配置代理SSL穿透，或切换为直连链路访问服务端

内容的提问来源于stack exchange，提问作者CovaDax