SSL异常：未收到peer的close_notify就关闭入站的排查与解决咨询

1. 该异常的具体含义是什么？ #

这个SSLException: closing inbound before receiving peer's close_notify异常，本质是违反了SSL/TLS协议的连接关闭规范：

• SSL/TLS连接需要优雅关闭，双方必须互相发送close_notify告警报文，告知对方要关闭连接。
• 客户端在关闭自己的接收通道（inbound）时，没有收到服务器发来的close_notify报文，触发了协议合规性检查，抛出这个致命错误。

2. 此问题是第三方服务器导致还是客户端自身问题？ #

结合你提到的「同一时间其他客户端无此问题」的情况，大概率是客户端自身的问题，原因可能包括：

• 客户端连接池配置不合理，比如空闲连接超时设置过短，导致连接在服务器还未发送close_notify时就被强制关闭。
• 客户端框架（Reactor Netty/Jetty）的SSL关闭逻辑存在异常，比如并发场景下通道关闭时机处理不当。
• 客户端的并发请求过载，导致连接池资源耗尽，连接被粗暴回收，跳过了SSL优雅关闭流程。

3. 如何规避该异常？有哪些进一步调试的方法？ #

规避方案 #

• 调整连接池配置：针对使用的客户端框架（Reactor Netty/Jetty），设置合理的连接超时、空闲超时时间，确保连接在服务器完成close_notify发送后再关闭。比如Reactor Netty可通过connectionProvider配置连接存活时间，Jetty可调整HttpClient的idleTimeout参数。
• 临时关闭严格检查：通过JVM系统属性jdk.tls.acknowledgeCloseNotify=false禁用该合规性检查，这是临时绕过方案，不推荐长期使用，仅用于快速验证问题。
• 升级客户端框架版本：排查当前使用的Reactor Netty/Jetty是否存在已知的SSL关闭bug，升级到最新稳定版修复潜在问题。
• 优化并发请求量：控制短时间内的请求发送速率，避免连接池过载导致连接异常关闭。

调试方法 #

• 开启详细SSL日志：添加JVM启动参数-Djavax.net.debug=ssl:handshake:verbose:record，记录完整的SSL握手、数据传输和连接关闭日志，定位具体哪一步缺少close_notify报文。
• 抓包分析：用Wireshark抓取客户端与服务器之间的TCP/SSL流量，查看连接关闭阶段的报文，确认服务器是否发送了close_notify，客户端是否提前关闭了连接。
• 监控连接池状态：添加客户端连接池的监控指标（活跃连接数、空闲连接数、连接关闭次数），排查是否存在连接泄漏或异常回收的情况。
• 代码逻辑排查：检查客户端代码中是否存在主动关闭连接的逻辑，比如未正确处理响应就提前关闭通道，导致SSL优雅关闭流程中断。

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