java.net.SocketException: Connection reset

[iliuwenbo]

已断开连接 (32109) - java.net.SocketException: Connection reset
如何去排查该问题，由什么引起的

[zhongwencool]

“已断开连接 (32109) - java.net.SocketException: Connection reset” 这个报错表明 Java 应用程序的 TCP 连接被对方（服务器或客户端）异常关闭了。错误代码 “32109” 并非一个标准的 TCP/IP 或 Java 错误代码，它更可能是应用程序内部自定义的错误标识或者特定环境下的错误码。核心问题在于 java.net.SocketException: Connection reset。

这个错误通常意味着：

• 对方应用程序崩溃或异常退出：连接的另一端可能遇到了错误，导致其进程终止，进而关闭了所有打开的网络连接。
• 对方主机重启或网络中断：服务器或客户端的操作系统重启，或者两者之间的网络设备（如路由器、防火墙）发生故障或重启，都可能导致连接被重置。
• 防火墙或网络设备干预：防火墙（无论是本地还是网络上的）或其它网络中间设备（如负载均衡器、代理服务器）可能会因为策略、超时或其他原因主动关闭了连接。
• 写入到一个已关闭的连接：如果一方已经关闭了连接（可能正常关闭或异常关闭），而另一方仍然尝试向这个连接写入数据，就会收到 “Connection reset” 错误。这种情况比较常见。
• TCP Keep-Alive 超时：如果开启了 TCP Keep-Alive 机制，并且在设定的时间内没有收到对方的响应，连接也可能被重置。
• 应用程序逻辑错误：例如，连接池管理不当，导致使用了已经失效的连接。
• 操作系统层面问题：操作系统网络堆栈的问题也可能导致连接重置，虽然这种情况相对少见。

---

如何排查该问题：

排查 “Connection reset” 问题通常需要从多个层面入手，以下是一些常见的排查步骤：

1. 分析错误发生的上下文 contexte️

• 错误发生频率：是偶然发生还是频繁发生？固定时间点发生吗？
• 错误发生场景：是在进行特定操作时发生，还是随机发生？涉及到哪些服务或组件？
• 客户端还是服务端报错：明确是连接的发起方（客户端）还是接收方（服务端）报了这个错。这有助于定位是哪一方主动关闭了连接。

2. 检查日志信息

• 应用程序日志：
  • 报错方日志：查看详细的异常堆栈信息，以及报错前后的业务逻辑日志，看是否有其他相关的错误或警告。
  • 对方应用程序日志：如果可能，检查连接另一端应用程序的日志。看对方是否有崩溃、重启、或主动关闭连接的记录。
• 系统日志：
  • 检查服务器和客户端的操作系统日志（如 Linux 的 /var/log/messages 或 journalctl，Windows 的事件查看器），看是否有网络相关的错误、硬件故障或系统重启的记录。
• 中间件日志：
  • 如果连接经过了负载均衡器、代理服务器、消息队列等中间件，检查这些中间件的日志，看是否有连接被中断或重置的记录。

3. 网络层面排查

• 网络连通性测试：
  • 使用 ping 测试基本的网络连通性。
  • 使用 telnet <对方IP> <对方端口> 或 nc -zv <对方IP> <对方端口> 测试端口是否可达。
• 防火墙检查：
  • 检查本地防火墙（如 iptables, firewalld, Windows Firewall）和网络防火墙的策略，确保没有阻止相关的IP和端口通信。注意是否有基于连接状态或超时的策略。
• 网络抓包分析：
  • 这是最有效的手段之一。在报错的客户端和服务器（如果可能的话，在中间网络设备上）同时使用 tcpdump (Linux) 或 Wireshark (Windows/Linux/macOS) 抓取网络包。
  • 分析抓包数据，寻找 RST (Reset) 包。查看 RST 包是由哪一方发出的，以及在 RST 包出现之前是否有其他异常（如大量的重传、零窗口等）。
  • 命令示例 (Linux): sudo tcpdump -i <network_interface> -w capture.pcap host <对方IP> and port <对方端口>
• 路由和网络设备：
  • 检查路由表 (route -n 或 ip route)，确保路由正确。
  • 排查NAT设备、负载均衡器等，看是否有会话超时或连接数限制等问题。

4. 应用程序层面排查

• 代码审查：
  • 检查socket连接和关闭的逻辑是否正确。是否有忘记关闭连接、或者在连接已关闭后仍然尝试读写数据的情况。
  • 检查连接池的实现和配置，确保连接的获取、释放和有效性检查是正确的。
  • 检查是否有长时间的阻塞操作导致连接超时。
• 超时设置：
  • 检查应用程序的 Socket 连接超时、读取超时设置是否合理。
  • 检查对方服务是否有相关的超时设置。
• 资源限制：
  • 检查操作系统允许的最大文件描述符数量（ulimit -n），如果连接数过多，可能会导致无法建立新连接或现有连接异常。
  • 检查应用程序的线程池、内存等资源使用情况，资源耗尽也可能间接导致连接问题。

5. 环境和配置检查

• JDK/JVM 版本：确认使用的 JDK 版本是否存在已知的与网络相关的 Bug。
• 操作系统网络参数：检查操作系统的 TCP/IP 栈参数配置，如 tcp_keepalive_time, tcp_fin_timeout 等，是否合理。
• 负载情况：检查服务器和客户端的 CPU、内存、网络I/O负载。高负载可能导致应用程序响应缓慢，进而引发超时和连接重置。

---

由什么引起的 (总结) penyebab

总的来说，“Connection reset” 是一个非常通用的网络错误，根本原因在于 TCP 连接的一方在数据传输过程中，由于某种原因，不再期望收到或发送数据，于是发送了一个 RST 包来强制关闭连接。具体原因多种多样，主要可以归纳为：

1. 对端异常：对方应用崩溃、主机宕机/重启。
2. 网络设备干预：防火墙、负载均衡器等中间设备基于策略或超时主动关闭连接。
3. 写入已关闭的连接：一方已关闭连接，另一方仍尝试写入。
4. 网络不稳定：网络丢包严重，导致TCP重传失败，最终连接被重置。
5. 资源耗尽：服务器或客户端资源不足（如文件描述符、内存、线程），导致无法正常处理连接。
6. 配置不当：应用程序或操作系统的网络相关参数配置不合理（如超时时间设置过短）。

通过上述排查步骤，逐步缩小范围，通常能够定位到问题的根源。网络抓包分析 是定位此类问题的最有力的工具。

[iliuwenbo]

在日志中是否可以查看该问题 现在返回的数据中就职提示了一个这个错误，排查方向太大了

[iliuwenbo]

@zhongwencool

固定时间点发生吗？

现在是固定出现，每次程序重新启动，另一个客户端推送数据后，该客户端消费时，就会出现该错误

[zhongwencool]

有日志就更好了。

[iliuwenbo]

@iliuwenbo

已断开连接 (32109) - java.net.SocketException: Connection reset
如何去排查该问题，由什么引起的

日志怎么看 现在日志只有提示这个 项目内部也不报错

[zhongwencool]

1. 打开百度搜索引擎，如果打不开，就打开 bing。
2. 搜索 “emqx 日志”
3. 找到官方文档中的链接emqx.com 的域名。
4. 点开就是了：日志 | EMQX文档

[iliuwenbo]

日志如下
2025-05-21T08:18:06.993636+08:00 [warning] tag: AUTHN/WEBHOOK, msg: start_resource_failed, reason: nxdomain, resource_id: <<“emqx_authn_http:1”>>
2025-05-21T08:18:22.008798+08:00 [warning] tag: AUTHN/WEBHOOK, msg: start_resource_failed, reason: nxdomain, resource_id: <<“emqx_authn_http:1”>>
2025-05-21T08:18:22.009063+08:00 [warning] tag: CONNECTOR/WEBHOOK, msg: start_resource_failed, reason: nxdomain, resource_id: <<“connector:http:fastbee_hook”>>
2025-05-21T08:18:37.024208+08:00 [warning] tag: CONNECTOR/WEBHOOK, msg: start_resource_failed, reason: nxdomain, resource_id: <<“connector:http:fastbee_hook”>>
2025-05-21T08:18:37.024576+08:00 [warning] tag: AUTHN/WEBHOOK, msg: start_resource_failed, reason: nxdomain, resource_id: <<“emqx_authn_http:1”>>
2025-05-21T08:18:38.220164+08:00 [warning] clientid: paho424589192800500, msg: socket_error, peername: 192.168.50.29:7054, username: admin, reason: timeout
2025-05-21T08:18:52.048290+08:00 [warning] tag: AUTHN/WEBHOOK, msg: start_resource_failed, reason: nxdomain, resource_id: <<“emqx_authn_http:1”>>
2025-05-21T08:18:52.048290+08:00 [warning] tag: CONNECTOR/WEBHOOK, msg: start_resource_failed, reason: nxdomain, resource_id: <<“connector:http:fastbee_hook”>>

[zhongwencool]

你的配置的授权 webhook 连不上了。

@iliuwenbo

nxdomain

NXDOMAIN 响应表示域名不存在 (Non-Existent Domain) 。当 DNS 解析器（resolver）尝试解析一个域名，但无法在 DNS 系统中找到该域名对应的 IP 地址时，

[iliuwenbo]

@iliuwenbo

2025-05-21T08:18:38.220164+08:00 [warning] clientid: paho424589192800500, msg: socket_error, peername: 192.168.50.29:7054, username: admin, reason: timeout

应该是这行报错，我这边好像解决了

业务逻辑中是这么监听的，但是实际的实体类中未书写@Async 导致所有请求过来后一直在等待 然后就超时了，我理解的是这样，但是不知道是不是这个原因