java.net.socketException：连接重置

Question

我正在遇到以下错误，试图从插座上读取。我正在该 readint（）上 inputStream ，我会遇到此错误。仔细阅读文档表明连接的客户端部分关闭了连接。在这种情况下，我是服务器。

我可以访问客户端日志文件，并且它没有关闭连接，其日志文件表明我正在关闭连接。那么，有人知道为什么会发生这种情况吗？还有什么检查？当有本地资源达到阈值时，这会发生吗？

---

我确实注意到我有以下行：

socket.setSoTimeout(10000);

在 readint（）之前。这是有原因的（长话），但只是好奇，这可能导致所指示的错误吗？我将服务器运行在IDE中，并且碰巧将IDE固定在断点上，然后我注意到我自己的IDE在我自己的日志中开始出现完全相同的错误。

无论如何，只是提到它，希望不是红鲱鱼。

Answer 1

有几种可能的原因。

1. 另一端故意重置连接，我不会在此处记录这种方式。对于应用程序软件来说，这样做的情况很少见，而且通常是不正确的，但对于商业软件来说，这种情况并不陌生。

2. 更常见的是，这是由于写入另一端已正常关闭的连接而导致的。换句话说，应用程序协议错误。

3. 也可能是由于套接字接收缓冲区中有未读数据而关闭套接字造成的。

4. 在 Windows 中，“软件导致连接中止”与“连接重置”不同，它是由您端发送的网络问题引起的。有一篇关于此问题的 Microsoft 知识库文章。

5. 如果进程存在但未关闭套接字，则 Windows（但 Unix、Linux 等除外）会重置连接。其他操作系统正确关闭它。

Answer 2

连接重置仅仅意味着收到了 TCP RST。当您的对等方收到它无法处理的数据时，就会发生这种情况，这可能有多种原因。

最简单的是关闭套接字，然后在输出流上写入更多数据。通过关闭套接字，您告诉您的对等方您已结束通话，并且它可以忘记您的连接。无论如何，当您在该流上发送更多数据时，对等方会使用 RST 拒绝它，让您知道它没有在监听。

在其他情况下，干预防火墙甚至远程主机本身可能会“忘记”您的 TCP 连接。如果您长时间不发送任何数据（2 小时是常见的超时），或者因为对等方重新启动并丢失了有关活动连接的信息，则可能会发生这种情况。在这些失效连接之一上发送数据也会导致 RST。

---

更新以响应其他信息：

仔细查看您对 SocketTimeoutException 的处理。如果在套接字操作被阻止时超出配置的超时，则会引发此异常。抛出此异常时，套接字本身的状态不会更改，但如果异常处理程序关闭套接字，然后尝试写入它，您将处于连接重置状态。 setSoTimeout() 旨在为您提供一种干净的方式来中断 read() 操作，否则该操作可能会永远阻塞，而无需执行诸如从另一个套接字关闭套接字之类的肮脏操作线。

Answer 3

每当我遇到这样的奇怪问题时，我通常会坐下来使用 WireShark 这样的工具来查看原始数据被来回传递。您可能会对事情被断开连接感到惊讶，并且只有当您尝试阅读时才会通知。

Answer 4

您应该非常仔细地检查完整的跟踪，

我拥有一个服务器套接字应用程序，并修复了 java.net.socketexception：Connection RESET RESET 案例。

在我的情况下，由于某种原因，它是从clienterocket socket 对象读取时发生的。 （网络丢失，防火墙或应用程序崩溃或打算关闭）

实际上，当我从此套接字对象阅读时出现错误时，我正在重新建立连接。

Socket clientSocket = ServerSocket.accept();
is = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
int readed = is.read(); // WHERE ERROR STARTS !!!

有趣的是，如果客户端连接到我的 serversocket 并关闭其连接而不发送任何内容 is.read is.read（）反复称呼。这似乎是因为在无限的循环中读取此插座，您尝试从封闭的连接中读取。
如果您使用下面的内容进行读取操作；

while(true)
{
  Receive();
}

然后，您在下面和

java.net.SocketException: Socket is closed
    at java.net.ServerSocket.accept(ServerSocket.java:494)

我所做的事情上获得了一个堆栈Trace，只是关闭了求助物，更新了我的连接并等待进一步的客户连接，

String Receive() throws Exception
{
try {                   
            int readed = is.read();
           ....
}catch(Exception e)
{
        tryReConnect();
        logit(); //etc
}


//...
}

这会重新建立我对未知客户端套接字丢失的连接，

private void tryReConnect()
        {
            try
            {
                ServerSocket.close();
                //empty my old lost connection and let it get by garbage col. immediately 
                clientSocket=null;
                System.gc();
                //Wait a new client Socket connection and address this to my local variable
                clientSocket= ServerSocket.accept(); // Waiting for another Connection
                System.out.println("Connection established...");
            }catch (Exception e) {
                String message="ReConnect not successful "+e.getMessage();
                logit();//etc...
            }
        }

我找不到另一种方法，因为正如您从中看到的那样在图像下方，您无法理解如果没有> catch ，连接是否丢失，因为一切似乎都正确。当我连续地获得连接重置时，我得到了此快照。

Answer 5

说起来很尴尬，但是当我遇到这个问题时，这只是我在读取所有数据之前关闭连接的错误。在返回小字符串的情况下，它可以工作，但这可能是因为在我关闭它之前整个响应已被缓冲。

如果返回的文本量较长，则会引发异常，因为返回的文本量超过了缓冲区。

您可以检查一下是否存在这种疏忽。请记住，打开 URL 就像打开文件一样，一旦完全读取，请务必将其关闭（释放连接）。

Answer 6

我有同样的错误。我现在找到了问题的解决方案。问题是客户端程序在服务器读取流之前完成。

Answer 7

我遇到了用Java编写的SOA系统的问题。我在不同的物理机器上同时运行客户端和服务器，并且它们工作良好，然后这些讨厌的连接重置出现在客户端日志中，并且服务器日志中没有任何奇怪的东西。重新启动客户端和服务器无法解决问题。最终，我们发现服务器端的堆已经很饱了，因此我们增加了JVM可用的内存：解决问题！请注意，日志中没有OutofMemoryError：记忆只是稀缺，没有用尽。

Answer 8

检查服务器的Java版本。发生在我身上，因为我的博客10.3.6在TLSV1上的JDK 1.7.0_75上。我试图消费的其余端点是关闭TLSV1.2以下的任何内容。

默认情况下，WebLogic试图协商最强的共享协议。请参阅此处的详细信息：与设置httpsocols system property有关对于HTTPS连接。

我添加了详细的SSL记录以识别受支持的TL。这表明TLSV1用于握手。
-djavax.net.debug = ssl：握手：hardshake：冗长：keymanager：trustmanager -djava.security.debug = access = access：stack

我通过将功能推向我们的JDK8兼容产品Jdk8 compatible产品，到TLSV1.2。对于仅限于JDK7的人，我还通过升级到TLSV1.2，成功地测试了Java 7的解决方法。我使用了以下答案：如何在Java 7

Answer 9

我还收到 HTTP 500 错误“java.net.SocketException：连接重置”，经过几天的分析，发现问题是由 AWS NAT 网关引起的。我希望它能帮助某人节省时间并解决问题。

基础设施：

AWS API 网关 (HTTP)、AWS CloudMap、AWS Fargate。

问题调查：

经过深入调查后发现，该问题是由 AWS NAT Gateway 引起的，该网关会将有关特定 NAT 转换的信息保留 350 秒，并在该时间段内没有流量时将其删除。
我的应用程序使用 Java HTTP 客户端，它保持连接 20 分钟。因此，350 秒后的前 1 或 2 个请求会以 HTTP 500 连接重置结束。 NAT 网关没有有关该特定转换的信息，并且它以 RST 标志进行响应 - 这就是我在日志中看到“连接重置”的原因。

实施的解决方案：

将 HTTP Java 客户端更改为 HTTP Apache 客户端。
HTTP Apache 客户端正确保持连接处于活动状态。
您可以选择调整本机 Java HTTP 客户端以发送 TCP keep-alive，或在 350 秒之前关闭非活动连接。

Answer 10

我在 Java 程序尝试通过 SSH 在服务器上发送命令时也遇到了这个问题。问题出在执行 Java 代码的机器上。它没有连接到远程服务器的权限。 write() 方法运行正常，但 read() 方法抛出 java.net.SocketException：连接重置。我通过将客户端 SSH 密钥添加到远程服务器已知密钥来解决此问题。

Answer 11

根据我的经验，我经常遇到以下情况。

1. 如果您在公司公司工作，请联系网络和安全团队。因为在对外部服务的要求中，可能有必要授予相关端点的许可。

2. 另一个问题是服务器上的 ssl证书可能已过期您的应用程序正在运行。

Answer 12

在我的情况下是 DNS问题。
我放入主机文件已解决的IP，一切正常。
当然，这不是一个永久的解决方案，这使我有时间解决DNS问题。

Answer 13

我已经看到了这个问题。就我而言，在特定Java类中重复使用相同的客户端对象引起的错误。该项目使用。

1. 最初，只有一种方法是使用/调用对象client request（将作为班级中的全局变量放置）在特定URL中执行请求。
2. 之后，创建了另一种使用另一个URL获取数据的方法，但是请重复使用相同的客户端对象。

解决方案：在同一类中创建了另一个客户端对象，并且不被重复使用。

Answer 14

就我而言，这是 TSL 版本的问题。我正在使用带有 OkHttp 客户端的 Retrofit，在服务器端更新 ALB 后，我应该删除带有 connectionSpecs 的配置：

OkHttpClient.Builder clientBuilder = new OkHttpClient.Builder();
        List<ConnectionSpec> connectionSpecs = new ArrayList<>();
        connectionSpecs.add(ConnectionSpec.COMPATIBLE_TLS);
  //      clientBuilder.connectionSpecs(connectionSpecs);

因此尝试删除或添加此配置以使用不同的 TSL 配置。

Answer 15

我曾经在 Netbeans7.4 设置的 Apache 控制台中收到“NotifyUtil::java.net.SocketException: Connection Reset at java.net.SocketInputStream.read(SocketInputStream.java:...”消息。

我尝试了很多解决方案为了摆脱这个问题，对我有用的是在 Tomcat 上启用 TLS，

具体方法如下：

创建一个密钥库文件来存储服务器的私钥和
通过执行以下命令来获得自签名证书：

Windows：

“%JAVA_HOME%\bin\keytool”-genkey -alias tomcat -keyalg RSA

Unix：

$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA

并指定密码值“changeit”。

根据 https://tomcat.apache.org/tomcat-7.0- doc/ssl-howto.html
（这将在您的本地用户目录中创建一个 .keystore 文件）

然后编辑 server.xml （取消注释并编辑相关行）文件 (%CATALINA_HOME%apache-tomcat-7.0.41.0_base\conf\server.xml) 以启用 SSL 和 TLS协议：

 <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
                maxThreads="150" scheme="https" secure="true"
                clientAuth="false" sslProtocol="TLS" keystorePass="changeit" />

我希望这有帮助

Answer 16

总体而言，为了找到问题的根本原因，我发现使用TCPDUMP等工具来追踪传入/发出的TCP数据包。
我发现这篇文章有助于通过真实的会话显示连接重置问题通过使用示例复制器。

Answer 17

我遇到了类似的插座异常。我们已经设置了一个MFT SFTP连接，并使用两个顺序控制M作业，每个连接每个将10个文件发送10 mO，1分钟向外部服务器发送1分钟。有时，外部服务器上缺少一个文件，其中MFT日志中存在以下错误：

Error writing data to final destination. | Proxy error in reading file.
(...)
Failed to connect to ssh server. Exception: java.net.SocketTimeoutException

我们通过在两个控制M作业的调度之间添加2分钟的延迟来修复此异常。