基于Netty的WebSocket客户端/服务端WSS模式连接失败求助

• WS（非安全）模式运行正常：客户端、Postman均可正常连接通信。
• WSS模式异常：服务端可正常启动（netstat显示端口监听），但Java客户端启动时抛出StacklessClosedChannelException无法连接；用telnet测试WSS服务端时，服务端代码会被触发，但Java客户端连接无反应。
• 调试限制：因Eclipse问题无法调试Java 1.6项目（报UnsupportedClassVersionError）。
• 实现参考：曾参考Netty WebSocket SSL相关示例，完整服务端与客户端代码已托管在GitHub仓库。

排查建议 #

服务端SSL配置检查 #

• 确认SslContext初始化使用的证书、密钥有效，且格式适配Java 1.6。Java 1.6对SSL/TLS协议支持有限，需显式指定协议版本为TLSv1或SSLv3，避免因协议不兼容导致握手失败。
• 检查ChannelPipeline中SslHandler的添加顺序，必须将其放在WebSocket相关处理器之前，确保SSL握手完成后再进行WebSocket协议握手。

客户端SSL配置检查 #

• 客户端需配置匹配的SslContext，若使用自签名证书，必须添加信任管理器信任该证书，否则会因证书验证不通过直接关闭通道。
• 同步客户端与服务端的SSL协议版本，Java 1.6默认可能未启用高版本TLS，需显式设置兼容的协议版本。

网络与协议验证 #

• 使用openssl s_client -connect <host>:<port>命令测试WSS服务端，该命令可输出完整的SSL握手日志，能直接定位握手过程中的错误（如证书不被信任、协议不支持等）。
• 确认WSS端口（默认443，自定义端口需对应）已被防火墙、安全组放行，排除网络拦截导致的连接失败。

Java 1.6兼容性修复 #

• 确认使用的Netty版本支持Java 1.6：Netty 3.x全版本支持，Netty 4.0早期版本支持，Netty 4.1及以上版本不再兼容Java 1.6，需对应调整依赖版本。
• 解决UnsupportedClassVersionError：将项目编译级别设置为Java 1.6，同时确保所有依赖库（包括Netty）均为基于Java 1.6编译的版本，避免跨版本编译问题。

内容的提问来源于stack exchange，提问作者Gaetan L.