Preparing Your Geyser Server for NetherNet

8 ottobre 2026 · 10 min read

onechris

Project Lead

With Minecraft: Bedrock Edition 26.60, planned for October 27th, 2026, Bedrock clients will stop connecting over RakNet. From then on, every Bedrock server has to speak NetherNet, the new transport Mojang has been rolling out since 26.40. Any Geyser build from 1237 onward supports NetherNet, but it is not enabled by default yet. This post covers what changes with NetherNet, how to switch over on a hosting provider or on your own machine, and how to check that everything works.

TL;DR​

• Update Geyser by downloading the latest build from https://geysermc.org/download, and turn on NetherNet in your Geyser config.
• Your server needs a TCP port in addition to the usual UDP port, unless you use external signaling. See our setup guide for detailed instructions!
• If your server is on a hosting provider for which we do not have an updated setup guide, contact their support. You can send them a link to this post.
• clone-remote-port only works with external signaling. If you use it, read this section below.
• Do it before October 27th. After that date, Bedrock players can't join servers that haven't made the switch.

What Changes​

With RakNet, Bedrock players connected directly to the server over UDP. NetherNet adds a step before that, called signaling. Bedrock clients now send the server a web request over TCP, asking how to connect. The signaling server then responds with the server information needed to connect over WebRTC (which runs on UDP), finishing the join process.

The MOTD and player count shown in the server list are now also fetched through signaling. This allows Geyser's built-in signaling server to receive the address initially pinged by the client, and forward it to the Java server for MOTD passthrough. Players who connect through an IP address, or through a domain without HTTPS, will see a "trust on first use" prompt on their first join.

In practice, this means your Geyser instance now needs a TCP port for signaling, in addition to the UDP port for gameplay. By default, Geyser uses port 19132 for both. As long as your address and port stay the same, your players can keep using the server entry they already have. However, if Geyser previously ran on the same port as your Java server, as it does on many hosts, players will need to change the port in their saved server.

Geyser also supports using HTTPS to avoid the "trust on first use" prompt. See the HTTPS section for details.

Enabling NetherNet​

Start by downloading the latest build from https://geysermc.org/download. Any build from 1237 onward supports NetherNet, but newer builds include a number of fixes, so we recommend always using the latest one.

RakNet is currently still Geyser's default, so NetherNet has to be turned on in the config. For this, take a look at our setup guide: it shows the exact config changes needed. Also, check the server console for any errors or warnings!

If you need help with the migration, please join our Discord and ask for help. Provide the following information:

• Where you host the server
• A Geyser dump (get it by running /geyser dump in the server console)
• A description of the issues you are seeing

HTTPS and the Trust Prompt​

Built-in signaling uses plain HTTP by default. While this works, players see a "trust on first use" prompt the first time they join your server. Serving signaling over HTTPS removes the prompt. We strongly recommend configuring HTTPS if you can!

There are two ways to enable HTTPS signaling. You can point Geyser to a TLS certificate in its built-in signaling config, and it will serve HTTPS instead of HTTP on the same port. Alternatively, you can put a reverse proxy in front of the signaling port and let it handle HTTPS. See our HTTPS guide for detailed information.

If neither option is available, you can use an external signaling service that provides HTTPS, such as Warden.

Checking That It Works​

After restarting, try joining from a Bedrock client on version 26.40 or newer. If the connection fails, the Geyser console is the first place to look, since Geyser reports most NetherNet problems there. The table below covers the most common ones.

If none of these apply, please join our Discord and share a /geyser dump, along with any other useful information about your setup.

Notes For Hosting Provider Users With clone-remote-port Enabled​

Many hosts have relied on clone-remote-port, which makes Geyser use the same port as the Java server. This does not work with built-in signaling. Signaling needs a TCP port, and the Java server already uses TCP on that port, so the two cannot share it. If your server only works with clone-remote-port, you have two options: ask your host for a separate port for Geyser that is open for both TCP and UDP, or use external signaling, which does not need a TCP port.

When Geyser detects that the Java server already uses its port, it falls back to external signaling through Warden, a free service run by Ziax, the creators of CubeCraft, and the console shows where players can join. If your host has no notes in our setup guide, pick "Not listed": it covers both options, including keeping a single port with clone-remote-port and Warden. Keep in mind that with this setup, players no longer join with your Java server's address, but with the address and port Geyser shows in the console unless a custom domain is registered on Warden. It also takes care of HTTPS for you, so users will not see a "trust on first use" prompt.

You may also notice that the "Supported hosting providers" list is gone from our website. Soon, it will be replaced with a list of hosts that support our work through the Open Collaboration program, and work with us to automatically configure Geyser for their users. This is also highlighted in the setup guide. However, a host's absence from that list will not mean Geyser won't run there, and the setup guide will continue to include community-collected setup instructions.

If You Run a Hosting Provider​

If you offer Minecraft servers, we recommend automatically configuring Geyser for your users, so NetherNet works without them touching the config. For this purpose, Geyser reads system properties that can be set in the server's startup command, and take priority over the config. The most important ones are:

• -DgeyserTransport=nethernet turns on NetherNet.
• -DgeyserUdpPort sets the Bedrock port. If you give each server its own port that is open for both TCP and UDP, built-in signaling works without further changes.
• -DgeyserSignalingPort and -DgeyserWebrtcPort split signaling (TCP) and gameplay (UDP) onto different ports, if your network hands them out separately.
• -DgeyserSignalingMode=nxs switches to external signaling, if you cannot give servers a TCP port. You can also run your own NXS-compatible signaling service.
• -DgeyserAdvertiseAddresses tells players which public address to connect to, if servers run in containers or behind a NAT and do not hold their public address themselves.

Once you have set this up, please let us know by opening a pull request or reaching out on Discord, so our setup guide can tell your users that there is nothing for them to do. In case you need further system properties, please reach out to us! If you would also like to support Geyser's development and be featured on our upcoming hosting page, have a look at Open Collaboration.

NetherNet External Signaling (NXS)​

Geyser supports using external signaling providers which follow the NetherNet External Signaling (NXS) standard. It can be useful for load-balancing between multiple Geyser instances, central certificate management, or avoiding running multiple built-in signaling servers, amongst other benefits. See the Open Collaboration blog post to find out more about NXS. Note that NXS does not support live forwarding of the MOTD and player count. Instead, they are updated periodically.

HAProxy Support​

HAProxy headers are currently supported for RakNet and for built-in signaling, but not yet for NetherNet gameplay over WebRTC. This feature will be added soon. Update 26.10.2026: As of Geyser build 1272, Geyser supports HAProxy headers for NetherNet gameplay over WebRTC. Note that unlike RakNet HAProxy support, you must configure trusted HAProxy speaking IPs in the config.

Further Reading​

• Geyser setup guide: setup steps, including notes for individual hosts
• HTTPS for NetherNet: removing the trust prompt with a certificate or a reverse proxy
• NetherNet HTTP Signaling onboarding guide: Mojang's official documentation
• Open Collaboration blog post: detailed information about NetherNet and the external signaling specification
• System properties supported by Geyser: every NetherNet setting you can set at startup

Acknowledgements​

We thank Mojang for documenting NetherNet and signaling ahead of the switch, and Ziax for running Warden, a free external signaling service open to every Geyser server. NetherNet support in Geyser would not have been possible without 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. Thank you as well to the community members who tested NetherNet support in Geyser and reported issues along the way. We would also like to thank all donors, and Open Collaboration and its members, for their continued support of the project.