Fix "End of Stream" Disconnect on a Minecraft Server

"End of stream" is a Java Edition disconnect reason that shows up when the connection to the server closed mid-conversation — usually during the handshake or login — without your client ever getting a normal Disconnect packet. So you got far enough to reach a live host and start talking to it. This isn't a can't-find-the-server failure; it's a drop partway through the login, which is a useful thing to know because it narrows what you're looking for.

It's close kin to a connection reset and a read timeout, but it's a distinct socket event with its own causes. If you're new to the connect flow, the baseline is over in how to join a server; everything below assumes you got past that and the connection died on the way in. The job from here is working out whether the close came from your side — a content filter, a VPN, a firewall, a flaky link — or the host's side, like a crash or a proxy that timed out mid-login.

What "End of stream" actually means

Java's networking runs through Netty, which reads the socket as a stream of bytes. "End of stream" fires when that read hits the end of its input — an EOF, a read that comes back with -1 — meaning the remote side closed the TCP connection and there's no more data coming. The stream literally ended.

The detail that separates it from a kick is the missing packet. When a server bans you, whitelists you out, or rejects your version, it sends a Disconnect packet carrying a reason string, and you read that string on screen. End of stream is the absence of that packet. Nobody told the client why; the stream just stopped, so the client falls back to its generic "End of stream" label instead of showing a real reason.

Where it lands in the sequence is telling too. A connection goes handshake, then login, then configuration, then play, and End of stream clusters in those early phases, before you're fully in the world. That's why you see it on the connect screen rather than after you've spawned.

This is also a Java message. Java runs over TCP on port 25565, and Bedrock runs over UDP on 19132 with its own wording for connection trouble, so the exact phrase "End of stream" means you're on Java.

End of stream vs connection reset vs read timed out

These three all describe a connection that dropped after it was already live, but they're three different socket events, and the wording is what tells them apart — not the java.* suffix, which looks similar across all of them.

End of stream is a clean end-of-input: the read hit EOF because the far side closed the socket, often without sending a Disconnect packet. A connection reset is a TCP RST — an abrupt, ungraceful tear-down that surfaces as "Internal Exception: java.net.SocketException: Connection reset." Read timed out is silence rather than a close: it's a java.net.SocketTimeoutException, a read during the login exchange that waited out its window and got nothing back, so it's a stall, not an active drop — and it's a separate error from the in-world "Timed out" keep-alive watchdog, which only fires once you've already spawned.

Here's the honest part. Depending on your operating system and the timing, the kernel can report either a reset or an end-of-stream for what is really the same far-side close. So the two overlap a lot, and the troubleshooting steps overlap with them. If you want the wider view of the network-error family these all belong to, that's the java.io.IOException writeup.

Player-side: isolate your own connection first

Start by retrying once. A good share of End-of-stream drops are one-offs — a server finishing a restart, a filter cutting the socket for a moment — and reconnecting clears them before you've changed anything.

If a retry doesn't take, work down your own connection. Wired beats Wi-Fi here, because a single dropped Wi-Fi burst during the login exchange is enough to end the stream, so plug into Ethernet or at least move closer to the router. Then restart the client, restart the PC, and power-cycle the router to clear a wedged socket or a stale route. Turn off any VPN and test the same server directly, since a congested endpoint or the tunnel timing out mid-handshake closes the socket before the game finishes logging in.

The highest-value step for End of stream specifically is the firewall and antivirus check. Allow javaw.exe or your launcher through the firewall, and temporarily disable third-party antivirus to test — security software cutting the game socket is the signature cause of this error, more so than for a plain reset. While you're at it, test a phone hotspot against a known-good, busy server pulled from the monthly rankings or the full list. That split is what tells you whether the problem rides with you or with one specific server.

Last on the player side, confirm your Java is current and your versions match. A newer client isn't backward-compatible with an older server — 26.3 runs protocol 777 and 26.2 runs protocol 776 — so updating right before a server does will break the join. You can filter for your exact version when you go looking (note the dotted form; the hyphenated URLs 404).

When a network filter or proxy is cutting the socket

This is the End-of-stream cause that catches the most people. Web and content-filtering software, and security suites, will terminate a long-lived game socket because it doesn't look like ordinary HTTP traffic. The classic offender on school and office networks was BlueCoat K9, and consumer suites like Norton, Kaspersky, and McAfee do the same thing on a home machine.

School, dorm, and corporate networks block or proxy non-web TCP all the time. So if a server fails on that network but connects fine off a phone hotspot, the filter is your answer, and there's no client-side fix for it beyond a different network. A VPN or proxy endpoint that times out the session, or a captive-portal intercept on public Wi-Fi, ends the stream in the same way.

The practical move is to whitelist Minecraft and Java in the antivirus and firewall where you can. On a managed network you don't control, you can't change the filter, so a hotspot or a home connection is the only reliable way through.

Server-side: when the host closes the socket

Plenty of End-of-stream drops aren't yours to fix. If the server crashes or restarts while your connection is open, the OS closes the socket out from under you, and you get End of stream instead of a clean kick. Wait a minute for it to finish booting and retry — once the console reaches "Done," the join usually goes through.

Proxies handle this differently. BungeeCord disconnects a player when the backend link drops, while Velocity tries to fall the player back to another server (except on read timeouts), so a backend that keeps flapping behind BungeeCord shows up as End of stream for everyone connected to it.

Two settings are worth an owner's check. The first is the proxy read-timeout: in velocity.toml you can raise read-timeout (60000 ms is a reasonable bump), and large Forge modpacks need a matching -Dfml.readTimeout flag on the backend so the long login burst doesn't get cut. The second is compression. network-compression-threshold defaults to 256, meaning packets above that size get compressed, but backends sitting behind a proxy are commonly set to -1 so the proxy handles compression instead. A mismatch there, or a buggy ViaVersion or proxy in the path, can mangle the compressed login burst and trigger the far side to close the socket.

Working out whose problem it is comes down to the pattern. If the listing shows the server flapping offline, or a row of players drop at once, it's the host — don't go chasing client settings you can't change from there. Check that the console reached "Done," and look for a crash loop or a plugin you added recently that's stalling the boot. For a server that's chronically unstable, the rankings surface steadier alternatives in the same category.

What won't fix it

Changing your DNS does nothing for this. A DNS failure throws an UnknownHostException, not End of stream — you already resolved the host and reached it, so the name lookup clearly worked.

Reinstalling Minecraft or Java is almost never the answer either. End of stream proves the client launched, resolved the host, and opened a connection, so the install is plainly working; the connection died after all of that, not because of it.

Lowering render distance is a band-aid borrowed from the large-chunk-burst reset case. End of stream lands during the small login packets, not the big world data, so it does little here, and even when it seems to help, all it's done is confirm you're on a marginal path, not fix anything.

FAQ

Is it worth retrying before I start changing settings?

Yes, but treat it as a test, not a fix. Reconnect once or twice — a lot of End-of-stream drops are a server finishing a restart or a filter that cut one socket, and the next attempt just goes through. The signal is in what happens when it doesn't: if three quick retries all fail the same way at the same point, it isn't a transient drop, so stop reconnecting and start working down the steps above.

How do I tell a flapping backend from a one-off drop?

Watch the cadence. A one-off is a single drop that a retry clears and that doesn't come back. A flapping backend repeats — you connect, get a few seconds in or never spawn, drop, and the same thing happens on every try, often at a steady interval as the server crashes and reboots on a loop. If you can see the listing, that settles it: a server bouncing offline and back, or several players reporting the same drop times, is the backend, not your link.

What should I grep for in the server console?

Search for lost connection — Paper and Spigot log every disconnect as a <player> lost connection: <reason> line, so that string plus the player's name lands you on the exact event and timestamp. On a BungeeCord or Velocity proxy, search the backend server's name instead to find the connect-then-drop pairs for it. One name on its own points at that player's link or a filter on their end; a stack of names at a single timestamp points at the proxy or the backend.

Does where it freezes on the connect screen tell me anything?

A fair amount. If it dies on "Logging in" or right after, before any terrain loads, that fits the login-phase close the rest of this covers — a filter, a crash, a compression mismatch. If instead you get most of the way in and drop as the world starts streaming chunks, that's more likely the large-burst case that reads as a reset, so follow that error's path rather than this one. The phase where it dies is a free hint at which cause to chase.