Key takeaways
- Minecraft 26.4 Snapshot 5 changes the login handshake so encryption and compression are applied only after the client acknowledges them.
- Previously both sides switched immediately, which could produce malformed packets if the timing did not line up.
- Server software, proxies and protocol translators all sit on this code path, so this is the kind of change that breaks tooling before it fixes anything.
Most snapshot coverage stops at the blocks. The technical sections get a sentence and a link, which is fine when the technical section is a pack format bump. Snapshot 5 contains something different – a change to how a client and server establish a connection in the first place, and that is a change every piece of third-party server software has to follow.
If you run a Paper server, a Velocity proxy, a Bedrock translator or a version-compatibility layer, this is the item in the 26.4 cycle most likely to generate a support thread. Here is what changed and why.
What the handshake did before
When a client connects, two settings get turned on during login: encryption, which secures the connection, and compression, which shrinks packets above a size threshold.
Previously both were applied immediately. The server decided to enable compression, sent the packet that said so, and switched its own outgoing stream to compressed at that moment. The client read the packet and switched its own stream at the moment it finished reading.
The problem is that “at that moment” is not the same moment on both sides. There is a window – however small – where the server is already writing compressed data and the client has not yet switched to reading it. In normal conditions the ordering works out. In abnormal conditions, the patch notes say plainly, it might have led to malformed packets.
What it does now
The new flow adds an acknowledgement step. In Mojang’s description, encryption and compression must now be explicitly applied by the server by sending one of two packets that carry connection options, and the client must acknowledge the change with a matching packet. Every packet sent and received after the acknowledgement uses the new settings.
Two packet pairs can carry these options:
- login_finished from the server, acknowledged by login_acknowledged from the client.
- apply_options from the server, acknowledged by options_applied from the client.
So the switch now has a defined boundary that both sides agree on, rather than two independent decisions that happen to land close together. Everything before the acknowledgement uses the old settings, everything after uses the new ones, and there is no window where the two sides disagree.
This is a textbook fix for a race condition and it is the right shape. The cost is that anything which implemented the old behaviour now implements the wrong thing.
Who this affects
Server software. Paper, Spigot, Fabric and NeoForge servers all inherit the vanilla networking code, so they get this when they update. No action for an operator beyond updating.
Proxies. This is where it gets interesting. A proxy sits between client and server and has to speak both sides of the handshake itself, including deciding when to enable compression on each leg independently. A proxy that applies compression immediately while talking to a client that now waits for an acknowledgement will desync. Our proxy and network guide covers what a proxy is actually doing on that path.
Protocol translators. Anything speaking a different edition’s protocol and translating has to reimplement login entirely. Our Geyser crossplay guide covers that layer, and a login-sequence change is exactly the kind of thing that breaks it until the project ships an update.
Version compatibility layers. Mods that let older clients connect to newer servers have to translate between two different login flows. Our notes on version compatibility layers cover how those normally track a release.
The practical timeline
This is a snapshot, which means the change is not live for anyone running a release version yet. The sequence that usually follows looks like this:
- Snapshot ships the change. Third-party projects that track snapshots break immediately and start adapting.
- Pre-releases arrive and the protocol stabilises. Projects publish snapshot-compatible builds.
- The release lands. Server software updates within days, proxies within days to a week, translators and compatibility layers last.
The order is consistent and it is why a server network usually cannot move to a new Minecraft version on day one even when the server jar is ready. Our version migration guide covers planning around that gap.
What an operator should actually do
Nothing yet, and that is the honest answer. This is a snapshot change on a version that is not out.
What is worth doing is noting it, because when 26.4 releases and your proxy refuses connections with a vague handshake error, this is the first thing to check rather than the last. Specifically:
- Do not update the backend servers to 26.4 before the proxy supports it. The proxy is the component that has to change most.
- Expect the Bedrock translation layer to lag the rest. It always does, and a login-flow change is one of the harder things for it to absorb.
- Keep a rollback. Our backup routine guide covers the part people skip.
Our read
Mojang has been doing a lot of this lately – the 26.3 cycle moved the input backend, 26.4 Snapshot 1 made Vulkan the default renderer, and now the login sequence gets a correctness pass. Our Vulkan coverage and input backend notes cover the other two.
Read together, that is a team spending its budget on foundations rather than features for two consecutive versions. Players do not get anything from a handshake fix. What they get is a smaller chance that a connection drops for reasons nobody can reproduce, and over a long enough window that is worth more than another block. The people who pay for it in the short term are the third-party developers who have to chase every one of these changes, and that cost is real even when the change is correct.
Images: Sildur’s Vibrant Shaders project gallery.