java.net.SocketException: Connection Reset — What It Means and How to Fix It

Connection reset is one of the most common Java networking errors: you'll see it in HTTP clients, JDBC drivers, message brokers, and game clients (Minecraft shows it as Internal Exception: java.net.SocketException: Connection reset). The message comes from the operating system's TCP stack, so the cause is rarely in the line of Java code that throws it. This guide explains what a reset is, reproduces one in a few lines, and walks through the causes in order of how often they happen.

FIN vs RST: Why 'Reset' Is Different

TCP has two ways to end a connection. A FIN is a polite close: the other side finishes sending, and your read returns -1 (end of stream). A RST is an abort: the connection is torn down immediately, and the next read or write on your side throws SocketException: Connection reset.

Something sends RST when it receives data for a connection it no longer knows about, when an application closes a socket with linger set to 0, or when a firewall or proxy decides to kill the connection.

Reproduce It in 20 Lines

This program starts a tiny server that accepts a connection and aborts it with a RST (linger 0), then reads from the client side. It produces exactly the exception you see in production.

import java.io.InputStream;
import java.net.ServerSocket;
import java.net.Socket;

public class ResetDemo {
    public static void main(String[] args) throws Exception {
        try (ServerSocket server = new ServerSocket(0)) {
            int port = server.getLocalPort();

            // The "server" accepts, then aborts the connection instead of closing it politely.
            Thread t = new Thread(() -> {
                try (Socket s = server.accept()) {
                    s.setSoLinger(true, 0);   // linger 0 = send TCP RST on close, not FIN
                } catch (Exception ignored) { }
            });
            t.start();

            try (Socket client = new Socket("localhost", port)) {
                t.join();                      // wait until the server has reset us
                InputStream in = client.getInputStream();
                in.read();                     // reading from a reset connection
            } catch (java.net.SocketException e) {
                System.out.println("Caught: " + e);
            }
        }
    }
}

The Common Causes

1. Idle connections killed in the middle: load balancers, NAT gateways and firewalls drop idle connections; reusing one from a pool triggers a reset.
2. The server closed or crashed: a restart, an out-of-memory kill, or a deliberate abort.
3. The server rejected the request: an unsupported TLS version or cipher, a request or header over a size limit, or plain HTTP sent to an HTTPS port.
4. Too many connections: the server's backlog or connection limit is full.
5. Network or security software: VPNs, antivirus, or a router dropping the connection (common for desktop and game clients).

Fixes That Work

Match timeouts: keep your connection pool's idle/keep-alive timeout below the shortest idle timeout on the path. Validate connections: most pools (HikariCP for JDBC, Apache HttpClient, OkHttp) can test or evict idle connections. Retry safely: retry idempotent requests (GET, PUT with the same body) once or twice with backoff; don't blindly retry payments or other non-idempotent calls. Match TLS: if a handshake is reset, check both sides support a common TLS version.

import java.net.SocketException;
import java.util.concurrent.Callable;

public final class RetryOnReset {
    // Retry an idempotent call a few times when the connection is reset.
    public static <T> T call(Callable<T> op, int attempts) throws Exception {
        for (int i = 1; ; i++) {
            try {
                return op.call();
            } catch (SocketException e) {
                if (i >= attempts) throw e;
                Thread.sleep(200L * i);   // simple linear backoff
            }
        }
    }
}