Minecraft Bedrock Edition 26.60, released October 27, 2026, connects to servers through NetherNet instead of the old RakNet. Servers running Geyser without NetherNet enabled have stopped letting 26.60 players in, even though those servers still show up in the server list, while older Bedrock versions still connect normally. Only the server admin can fix this, by enabling NetherNet in Geyser.
- Cause: Bedrock 26.60 connects through NetherNet, but the server only accepts RakNet.
- Symptom in the log: a "NetherNet support is NOT enabled" warning and no connection attempt at all from 26.60 players.
- Fix: Geyser build 1237 or later,
transport: both, a separatewebrtc-port, the Bedrock port open on both TCP and UDP, then restart. - The player can't fix anything on their end, the admin is the one who enables NetherNet.
Why won't Bedrock 26.60 connect to the server?
Until now, Bedrock Edition connected to servers through RakNet, a protocol running over UDP. Its successor is NetherNet, which Mojang has been rolling out since version 26.40, according to the GeyserMC blog. In NetherNet, the connection starts with signaling over TCP, while the actual gameplay runs through WebRTC over UDP. You can find the history of Bedrock releases in our Minecraft version overview.
A GeyserMC post from October 8, 2026 announced that starting with 26.60, Bedrock clients would stop connecting through RakNet, meaning every Bedrock server has to support NetherNet. This also applies to Java servers running Geyser, which acts as a bridge for Bedrock players. Mojang only devotes one sentence to this in the Bedrock 26.60 changelog, in the Dedicated Server section:
Updated the warning that suggests trying NetherNet to instead be an error when users are not using NetherNet, as RakNet is deprecated
In other words: Bedrock Dedicated Server now shows an error instead of a warning when NetherNet isn't being used, because RakNet is deprecated. The changelog doesn't mention any gradual rollout of the change, nor servers running Geyser.
Why did the problem only show up on October 29?
In the logs of servers running RakNet only, 26.60 players still managed to connect for about 2 days after launch, until around 3:35 PM Polish time on October 29, when they stopped connecting entirely, while servers with NetherNet enabled kept accepting them without interruption. Why the delay happened is unclear: we couldn't find any announcement from Mojang or GeyserMC explaining it.
What can a Bedrock 26.60 player do?
If the server doesn't support NetherNet, there's no workaround on the player's side, since NetherNet has to be enabled by the server admin. Still, there are a few things you can do:
- Enter the address and port in separate fields: the address in the "Server Address" field, and 19132 (or whatever port the server provides) in the "Port" field. Don't type "address:19132" into a single field.
- If the game shows "Outdated Bedrock client!", update it. You can find version numbering and the version list on the Minecraft Bedrock Edition page.
- Let the server admins know that 26.60 players can't connect while older versions can, and send them a link to this guide.
How do you spot a missing NetherNet setup in server logs?
For an admin, the symptom can be misleading. The server responds to pings, shows up in the server list, the RakNet handshake goes through, and players on older versions can connect just fine. But from 26.60 clients, there's no connection attempt in the log at all, not even visible in a network traffic capture.
A clue comes from Geyser's startup log. When NetherNet is disabled, this warning appears on startup:
WARNING! NetherNet support is NOT enabled.
Players will not be able to connect to your server,
starting October 27th, when NetherNet is scheduled to release.
Please see our blog post over at https://geysermc.org/blog/preparing-for-nethernet
on how to enable NetherNet support.About the ports, there's only one line at that point, with no mention of signaling:
Started Geyser on UDP port 19132"Outdated Geyser proxy!" is a different error
With new Bedrock versions, there's another common error unrelated to NetherNet: an outdated Geyser build. The player then gets the message "Outdated Geyser proxy!", and the log shows:
Bedrock user with ip: /<ip> has disconnected for reason Outdated Geyser proxy! This server supports the following Bedrock versions: 26.30, 26.31, …So the symptoms break down like this:
- "Outdated Geyser proxy!": Geyser is outdated, just update it.
- "Outdated Bedrock client! This server supports the following Bedrock versions: …": the game is outdated, and only the player can fix that by updating.
- No connection attempt at all in the log, plus a "NetherNet support is NOT enabled" warning on startup: NetherNet is missing, fix below.
How do you enable NetherNet in Geyser?
These steps are based on the blog and the GeyserMC wiki, and the settings are changed in Geyser's config.yml file.
- Update Geyser to build 1237 or newer, ideally the latest build. NetherNet isn't enabled by default yet, so updating alone isn't enough.
- In
config.yml, settransport: both, and enter a free UDP port different fromportinwebrtc-port. - Open the Bedrock port for both TCP and UDP, and the
webrtc-portfor UDP, on your router and firewall. Previously UDP alone was enough, but now signaling runs over TCP, and according to the wiki, without TCP the server won't show up for players at all. - If the server is behind NAT or in a container, enter the public address with the port in
signaling.advertise-addresses. These are the addresses Geyser gives players to connect through NetherNet. - Restart the server, or just Geyser if you're running it as a standalone.
A config snippet might look like this (port 19133 is just an example):
bedrock:
port: 19132
webrtc-port: 19133
transport: both
signaling:
mode: builtinAfter restarting, you should see a line in the log about the built-in signaling:
Built-in signaling started on http://0.0.0.0:19132, with NetherNet on UDP port 19133The first 26.60 players might connect just seconds after the restart. You can recognize a NetherNet connection by the thread name in the first parentheses, with the number at the end being the client protocol (2225 means Bedrock 26.60):
[NetherNet Built-in Signaling-9-2/INFO] [Geyser-BungeeCord]: Player connected with username <nick> (2225)RakNet connections show a thread like GeyserServerChild-…, with the second part of the parentheses depending on the platform Geyser is running on.
Why "transport: both" instead of "nethernet"?
Setting transport: nethernet disables RakNet, and some versions, like 26.40, still fetch the MOTD and player count through it. According to the GeyserMC wiki, full NetherNet support only exists in versions 26.50 and newer. The both mode handles both older and newer versions at once, even though the comment in config.yml calls RakNet a deprecated method meant to be removed.
The GeyserMC blog allows switching to nethernet only once all players are on 26.60. As long as someone's still on an older version, stick with both. You can find more on setting up and configuring servers in our Guides section.
What errors does the console show after enabling NetherNet?
The GeyserMC blog describes the symptoms of the most common configuration mistakes. The first three are console messages:
Built-in signaling cannot use port … because the Java server already uses it: Bedrock and Java share a single port, usually through theclone-remote-portoption, which many hosting providers use. Signaling needs TCP, but the Java server already occupies TCP on that port. Ask your host for a separate port open on both TCP and UDP. Without this, Geyser automatically falls back to external signaling through the free Warden service and shows the address players should use to connect in the console.RakNet and NetherNet each need their own UDP port: withtransport: both, thewebrtc-portfield has the same number as the Bedrock port. Enter a different free port there.… is a loopback address: the Bedrock address in config.yml is 127.0.0.1 or similar. Set it to0.0.0.0instead.- A "Trust on First Use?" prompt the first time a player connects: the built-in signaling defaults to plain HTTP. To avoid this, serve signaling over HTTPS (the wiki describes this in the "HTTPS for NetherNet" section).
If none of these cases match your situation, GeyserMC asks you to report it on their Discord along with the output of the /geyser dump command.