Fix "Read Timed Out" When Joining a Minecraft Server

Read timed out is the message text behind java.net.SocketTimeoutException, and it means your client already had an open connection to the server, then sat waiting for data that never showed up inside the read window, so Java stopped waiting and threw the error. The connecting part already worked; the stall came partway through, once the link was open.

Because this is a transport-layer event, nothing on your disk is wrong. Your account, worlds, and install are untouched, so reinstalling is the wrong first move — it won't get near the cause. What you want to do instead is understand the read window, separate this cleanly from Connection timed out (which is a completely different failure), then work the player-side network checks before you look at the server's tick.

One scope note before the steps: this is Java Edition wording. Java listens on TCP port 25565, while Bedrock is a separate engine on UDP 19132 that reports its failures differently, so if you're seeing this exact java.net text you're on Java. And if you're not certain the add-server flow itself went in right, how to join a Minecraft server covers that part separately.

What "read timed out" actually means

A socket read blocks — it just waits — until bytes arrive. When a read timeout (SO_TIMEOUT) is set on that socket, the read is only allowed to wait that long, and if the window elapses with nothing received, Java throws java.net.SocketTimeoutException carrying the text Read timed out. That's the whole event: a read that waited its allotted time and got nothing.

It helps to place it in the exception family, because that's where the confusion starts. SocketTimeoutException extends java.io.InterruptedIOException, which extends java.io.IOException — the same parent as the java.net.SocketException ("Connection reset") failures people lump it in with, but it means something different.

The detail that defines a read timeout is when it happens: after a connection is established. The handshake already succeeded and the link is open; the data stream went quiet mid-conversation. That timing is what separates it from a connect-phase failure, and it's also why the fix is different. On the client you'll see it as Internal Exception: java.net.SocketTimeoutException: Read timed out, and on the server console it shows up as a player losing connection or a failed packet read. Client and server are seeing the same stalled stream, just from their own end.

"Read timed out" vs "connection timed out" — the distinction that matters

Connection timed out is the connect phase. Your client tried to open the TCP connection and no reply ever came back, so it never reached a host that answers — a firewall in the way, a dropped outbound packet, a wrong address or port, an unreachable host. You were never connected at all. If that's the line you're actually looking at, fix connection timed out is the right page.

Read timed out is the read phase. The connection succeeded, then the stream went quiet long enough that the read gave up. You were connected, which is exactly why the troubleshooting diverges — the address and port are almost certainly already correct, since a wrong one would have failed at connect.

There's a near-cousin worth calling out so you route yourself correctly. The in-game keep-alive watchdog on the main game channel reports io.netty.handler.timeout.ReadTimeoutException, which is Netty's own read-timeout handler, not the java.net one. Same idea — no data inside a window — but a different networking layer, and the fixes overlap heavily. That wording is broken down in the io.netty channel errors post and the java.io.IOException family post.

What strands the read

Two things can starve that read, and they live at opposite ends of the wire.

The first is your path. If your line drops a chunk of packets, the bytes the server sent never fully arrive and the read window expires waiting for the rest. Sustained loss above roughly 5%, or ping climbing well past about 100 ms, is the band where joins turn unstable — what is a good ping for Minecraft puts numbers to it. A flaky connection does the same thing without dropping packets outright: Wi-Fi interference, a saturated uplink with a background download or cloud sync eating your bandwidth, or a brief route flap can freeze the stream just long enough to trip the timeout. And anything stateful in between you and the server keeps its own idle timeout — your router's NAT table, an ISP firewall, a load balancer, a VPN — so when one of those silently evicts a flow it decided was idle, your next read finds nothing and times out.

The second is the server, and this is the cause most write-ups skip. An overloaded tick is the big one. If the server's TPS collapses or it hits a long stop-the-world garbage-collection pause, it freezes for seconds and simply can't push data inside your read window, so the timeout fires even though your line is perfect. What TPS and MSPT mean explains why that freeze happens.

So the same error has a player-path cause and a server-tick cause. The next two sections are how you tell them apart and what to do about each.

Player-side checks, in order

Reconnect once before anything else. Read timeouts are often a one-off congestion blip or a server mid-restart, and an immediate retry clears the transient case for free — no point diagnosing a problem that's already gone.

If it keeps happening, run a live test instead of guessing. Open a continuous ping to the server's IP (ping -t on Windows, plain ping on macOS or Linux) or an mtr/tracert, and leave it running while you play. Watch the exact second you drop: a latency spike or a jump in loss right at that moment pins the stall to your path.

From there, stabilize the line. Wired Ethernet beats Wi-Fi for this, since interference and a weak signal are common stream-stallers; close whatever's eating bandwidth; and power-cycle the router and modem to clear a stale NAT entry or a wedged route. The path-quality fixes here are the same ones that lower ping generally.

To split local from remote, swap networks. Try the same server on a phone hotspot, or a second known-good server on your home network. If it works on the hotspot but not your home Wi-Fi, the fault is your router or ISP path. If it fails on both networks, the first server is the problem, not you. While you're at it, test the middleboxes: turn a VPN or proxy off (or on) and retry, and make sure a firewall or antivirus isn't throttling Java — a stateful device with a short idle timeout is a classic silent cause of a stranded read.

When it's the server lagging, not your line

Once your path checks out clean, confirm the split using the listing. Check the server's live status on the rankings or the full server list — the site pings it the same way your client does — then join a second populated, clearly-online server. If that one holds while the first keeps timing out, you've found your answer: it's the host.

The clearest tell of a tick stall is a row of players all dropping with Read timed out at the same timestamp. One player's bad connection doesn't do that; a server freezing does. A TPS collapse or a GC pause stops the main thread from sending packets to everyone at once, and everyone's read window expires together.

What can actually be done about that is on the owner's side, not yours. They'd reduce the lag and free up resources so the tick keeps up, audit recently-added plugins or mods that might be stalling the main thread, watch GC pauses and heap pressure, and restart to clear a degraded state. The broader pattern — a server that strands reads under load — is also covered in why Minecraft keeps disconnecting from servers.

From the client your only real levers are to wait and retry, or pick a steadier server. A chronically timing-out host shows it in its live status, and the rankings surface stabler alternatives in the same category, so when you test, test against something that's genuinely up and populated rather than a dead listing.

FAQ

How do I read an mtr or tracert to spot where the loss is?

The output is one row per hop between you and the server, each with its own loss and latency column. The thing that trips people up: loss that shows on a single middle hop and then vanishes on every hop after it is almost always harmless — that router is just de-prioritizing the ping replies you sent it, not dropping your game traffic. What you care about is loss that starts at some hop and then carries through to the bottom of the list, because the bottom row is the server itself. If only that final hop shows loss or a latency spike, the trouble is at the host or its immediate network. If loss appears partway and never recovers, the hop where it first appears is roughly where your path degrades.

Is "Read timed out" the same as io.netty.handler.timeout.ReadTimeoutException?

They mean the same thing — a read window expired with no data — but they come from different layers. java.net.SocketTimeoutException: Read timed out is a blocking-socket read hitting its SO_TIMEOUT, and you'll often see it in the server console or around login, query, and auth-side reads. io.netty.handler.timeout.ReadTimeoutException is Netty's watchdog on the live in-game channel, usually the keep-alive failing once you're already playing. The troubleshooting overlaps so much that you can work the same network and server-tick checks for either one; the Netty variant is broken down further in the io.netty channel errors post.

It only times out when a big base loads or there are tons of entities — why?

That timing points straight at server performance rather than your line. Loading a dense build, a mob farm, or a wave of chunk generation stretches the server's tick and can trigger a stop-the-world GC pause, and while the main thread is busy it stops pushing packets to you. If that stall outlasts the read window, your client times out even though your connection is perfectly healthy. It's the server's MSPT climbing, and only the owner can fix it by reducing tick load and freeing resources — from the client you can only retry or move to a steadier server.

Can my router or VPN specifically cause "Read timed out"?

Yes, and it's a common silent one. Anything stateful in the path — your router's NAT table, an ISP firewall, a VPN or proxy — keeps its own idle timeout, and when it quietly evicts a connection it has decided is idle, your next read finds nothing and times out even though both ends are still up. Reproduce it by turning the VPN off and testing on wired Ethernet; if the timeouts stop, that middlebox was dropping the flow. Power-cycling the router clears a stale NAT entry, and switching to a phone hotspot is the fastest way to confirm the home path is the one at fault.