With Minecraft: Bedrock Edition 26.60, planned for October 27, Bedrock clients will stop connecting over RakNet. From then on, every Bedrock server has to support NetherNet, the new transport Mojang has been rolling out since 26.40. This affects everyone who runs Bedrock or crossplay servers, from a single self-hosted Geyser instance to large networks and hosting providers.
At Open Collaboration, the organization behind Geyser, CloudburstMC, and Boar, we have been working on NetherNet support since early 2026. The result is an implementation in CloudburstMC/Network, the networking library used widely across the Bedrock ecosystem. Geyser has supported NetherNet through it since build 1237.
This post explains what NetherNet changes and what we built to help: NetherNet External Signaling (NXS), an open standard for running signaling outside the game server. Our reference implementation is open source and part of the same library.
What's changing?
Under RakNet, a client sent UDP packets directly to a server's address and port. NetherNet adds a step before that, called signaling. Before joining, the client sends an HTTP(S) request to the server to ask whether it supports NetherNet. The server answers with the details the client needs to establish a connection. The game connection itself then runs over WebRTC, an open standard browsers use for things like video calls.
Similarly, MOTD and player count shown in the server list are fetched using HTTP(S) from a different endpoint.
Mojang documents this in its NetherNet HTTP Signaling onboarding guide.
Introducing NetherNet External Signaling (NXS)
Signaling adds complexity to existing setups. Servers must expose another TCP port for signaling, and they must provide a certificate for TLS. But it also opens up new possibilities: Server-list pings include more details about the client, such as its version, platform and the full address it used. And because the server can directly tell the client where to connect, routing players is now much easier.
To better support these new use cases, we wrote a specification for moving signaling out of the game server: NetherNet External Signaling (NXS). With it, a game server can hand its signaling to a separate service, a "provider," chosen by the server's operator. Players still connect directly to the game server, so the provider only handles signaling and MOTD/player count queries, and never handles gameplay traffic.
The NXS protocol has three parts. When a server starts, it registers with its provider. While it runs, it sends regular heartbeats reporting whether it is accepting players, its capacity, and which public addresses it can be reached on. When a player wants to join, the provider answers their signaling request and issues a short-lived encrypted ticket. The player presents that ticket to the game server in their first packet, and the server later reports to the provider whether the join succeeded.
With NXS, a game server no longer needs a TCP port or a certificate of its own, only a reachable UDP port. This could also be used by game server hosting providers to route users based on a custom domain or subdomain and handle certificate management centrally. If you're interested in building your own NXS provider or would like to collaborate with us to build an open implementation, feel free to contact us.
Technical notes on external NetherNet signaling
It is worth noting that player joins do not depend on a live connection of the server to the external signaling provider. The server independently checks the encrypted ticket a player receives from the provider to confirm that it is genuine, unexpired, and issued for this connection, before anything is set up for the player. The signaling provider verifies the player's identity during signaling and ties the ticket to it. Tickets automatically expire 120 seconds after they are issued. This means that, even though the game server is exposed to the internet, it can easily drop connections not going through the provider.
Further, the game server stays in control even when signaling is done externally. A provider can stop routing new players to a server, but it can never tell the server to drain or shut down. If a provider goes offline, players who are already connected stay connected.
For larger deployments, it is also possible to let the provider route players to a registered server based on the health and capacity reported by each server.
The full V1 specification is published on the CloudburstMC/Network repository under the Apache-2.0 license. Geyser fully supports it and uses Warden, operated by Ziax, as its default configured NXS provider.
Finally, the NXS standard is vendor-neutral. Any provider or server software that implements the specification will work interchangeably. In Geyser, switching providers is a single config setting.
Our implementation
Our NetherNet work can be found in CloudburstMC/Network.
The library contains the NetherNet transport, built-in HTTP and HTTPS signaling, and the NXS specification and documentation. It uses libdatachannel, an open-source WebRTC library, through libdatachannel-java bindings. Beyond that, it supports running RakNet alongside NetherNet to make supporting older versions that don't support NetherNet possible. It multiplexes WebRTC connections, so all players share one UDP port. This is worth noting, as Google's default WebRTC implementation handles only one connection per IP address and port, which is also why the Bedrock Dedicated Server (BDS) currently needs a separate port per player.
What this means for Geyser users
Please see the Geyser blog post for detailed information. Geyser has supported NetherNet since build 1237, and will enable NetherNet by default with the 26.60 release. We encourage users to migrate early and recommend that server hosts contribute updated configuration instructions to our setup guide.
Thank you
Getting support out early, including a new standard, would not have been possible without the members of Open Collaboration, who supported and funded it. We also want to thank Kas-tle, whose early NetherNet transport in NetworkCompatible and first NetherNet support in CloudburstMC/Network got this started; rtm516, for HTTP signaling and the move to libdatachannel; and irrld, for bringing NetherNet and NXS into Geyser and improving the existing work. Thanks as well to Ziax for their support in developing the specification and for providing a free Warden tier, and to the many people helping out users with migrating from RakNet to NetherNet.