Geyser NetherNet: Fix Bedrock Joins Before 27 October

If you run Geyser and leave its config alone, Bedrock players will not get into your server once Bedrock 26.60 is out. GeyserMC says Bedrock clients stop connecting over RakNet with that update, planned for 27 October 2026, and Geyser still defaults to RakNet. To fix it, you need a build from 1237 on, transport: nethernet in the config, and a Geyser port that is open for TCP as well as UDP.

If Geyser already has its own port, the switch is a config change, a restart and, on your own machine, one extra firewall rule. Servers that share the Java port through clone-remote-port have more to do, because built-in signaling needs a TCP port that the Java server is not using.

The short version

1. Update Geyser. NetherNet needs build 1237 or newer, and GeyserMC recommends the latest build. On 16 October 2026 that was 2.12.0 build 1259.
2. In the bedrock section of Geyser's config, set transport: nethernet.
3. Open the Geyser port for TCP and UDP. If clone-remote-port: true is set, give Geyser its own port or use external signaling.
4. Restart, look for Built-in signaling started on in the console and join from a current Bedrock client.
5. Update Geyser again once GeyserMC adds support for Bedrock 26.60.

What changes on 27 October, and who says so

The deadline comes from GeyserMC's post Preparing Your Geyser Server for NetherNet of 8 October 2026: "With Minecraft: Bedrock Edition 26.60, planned for October 27th, 2026, Bedrock clients will stop connecting over RakNet." The same post says "Any Geyser build from 1237 onward supports NetherNet, but it is not enabled by default yet", and ends its summary with "Do it before October 27th. After that date, Bedrock players can't join servers that haven't made the switch."

We found no Mojang post that names 27 October as the end of RakNet. Mojang calls RakNet deprecated and already made NetherNet the default for its own server software, so the direction is settled, but the date comes from GeyserMC and the wiki. GeyserMC ties the change to the 26.60 release itself, so the deadline moves if the release does.

What NetherNet changes on the network

With RakNet, a Bedrock client sent UDP packets straight to the server. NetherNet adds a step in front, which GeyserMC calls signaling: the client first sends the server a web request over TCP, asking how to connect, and the answer sets up a WebRTC connection that runs over UDP. The MOTD and player count in the server list now come through signaling as well.

Mojang's NetherNet onboarding guide describes that first request: the client calls GET /v1/join, and if the server does not answer with a success status, the client does not attempt the WebRTC connection.

For your server, that means:

• Geyser needs TCP and UDP on its port. By default it uses 19132 for both.
• No other program may use the Geyser port on either protocol. GeyserMC's setup guide names voice chat mods and Query on the UDP side, and another server, a web map or a website on the TCP side.
• Built-in signaling cannot share the Java server's port, because the Java server already listens on TCP there.

Step 1: check your Geyser build

Run this in the server console:

geyser version

Geyser replies with its version, where the number after -b is the build (for example 2.12.0-b1259), and checks whether a newer build exists. You need 1237 or newer. Later builds keep adding NetherNet fixes and options, such as the advertise-addresses setting in build 1250 on 9 October, and GeyserMC recommends always running the latest one. On 16 October 2026 the download API listed Geyser 2.12.0 build 1259 as the newest.

The 2.12.0 builds imitate a Java 26.3 client, so check the Java side too:

• Paper or Spigot not on 26.3: install ViaVersion, as the setup guide says.
• Velocity or BungeeCord: every server behind the proxy must accept 26.3 Java clients.
• Fabric or NeoForge: GeyserMC's supported versions page says Geyser-Fabric and Geyser-NeoForge only support the latest Java version. For a modded server that stays on 26.2, GeyserMC recommends ViaProxy with Geyser-ViaProxy.

Our 26.3 server update guide covers the Java update itself.

Then plan a second update. On 16 October the supported versions page reads "Geyser currently supports Minecraft Bedrock 26.30-26.52 and Minecraft Java 26.3." Bedrock 26.60 is not on that list yet, and GeyserMC's post says 26.30 support will be removed once 26.60 support is added. Bedrock updates automatically on all platforms, according to the same page, so soon after 26.60 is out your players will need a Geyser build that knows it.

Step 2: see how your Bedrock port works today

Geyser's config file sits here:

Open it and find the part that starts with bedrock:. You are in one of three situations:

• clone-remote-port: true. Geyser runs on the Java server's port. In GeyserMC's words: "Signaling needs a TCP port, and the Java server already uses TCP on that port, so the two cannot share it." You need a separate port that is open for TCP and UDP, or external signaling (see the Warden section below). Either way, Bedrock players will join with a different port or address than before.
• Geyser has its own port: clone-remote-port is false and port is not the Java port. Keep that port and make sure it is open for TCP too. Players keep their saved server.
• Self-hosted on 19132. Allow and forward 19132 for TCP as well as UDP.

Check the startup command as well. Geyser's system properties "take priority over the config", says GeyserMC. -DgeyserUdpPort=server puts Geyser on the Java server's port just like clone-remote-port, and then, according to the system properties page, "built-in signaling cannot run and Geyser uses external signaling instead", unless -DgeyserSignalingPort gives signaling a port of its own. -DgeyserTransport overrides transport in the config.

Older Geyser guides, some of ours included, recommend clone-remote-port because it saved a port under RakNet. With NetherNet it only works together with external signaling.

Step 3: switch Geyser to NetherNet

On a hosted server where you can allocate ports, GeyserMC's setup guide gives this config. If your host has no notes in that guide, GeyserMC says to pick "Not listed", and this is its "I can allocate ports" option:

bedrock:
  clone-remote-port: false
  port: TCP_UDP_PORT
  transport: nethernet

Replace TCP_UDP_PORT with a port allocated to your server that is open for both TCP and UDP. Change only these lines and leave the rest of the bedrock section alone.

On your own machine or VPS, the self-host version is shorter:

bedrock:
  port: 19132
  transport: nethernet

19132 is the default. You can pick another port, as long as it is not the Java server's port.

Then:

1. Leave address at 0.0.0.0. GeyserMC's HTTPS guide warns that NetherNet does not work if Geyser only listens on 127.0.0.1.
2. Restart the server.
3. Watch the console. Built-in signaling logs a line that starts with Built-in signaling started on http://, followed by the address and port.

Platform notes

• Paper and Spigot: Geyser-Spigot.jar goes in plugins. If the server is not on 26.3, add ViaVersion.
• Velocity and BungeeCord: install Geyser only on the proxy. GeyserMC says Floodgate can go on all servers. The NetherNet settings go in the proxy's Geyser config, and the Geyser port, TCP and UDP, has to reach the proxy. If you pass real player IPs with HAProxy headers, GeyserMC says those work for RakNet and built-in signaling, but not yet for NetherNet gameplay over WebRTC.
• Fabric and NeoForge: the same bedrock lines go in config/Geyser-Fabric/config.yml or config/Geyser-NeoForge/config.yml. Geyser-Fabric also needs Fabric API. Both run only on a 26.3 server and only alongside server-side mods. The setup guide lists nothing else for NetherNet on these platforms.

Which ports Geyser needs: TCP and UDP

GeyserMC's port forwarding page puts it this way: "players find the server over TCP (signaling), and play on it over UDP", and "With external signaling, such as Warden, only UDP for WebRTC is needed."

On a Linux VPS with ufw, the page gives these two rules for the default port:

sudo ufw allow 19132/tcp
sudo ufw allow 19132/udp

At home, forward the port for both protocols in your router. In Docker, publish it twice, as 19132:19132 and 19132:19132/udp, because Docker exposes TCP only when there is no suffix. GeyserMC points playit.gg users to playit's own NetherNet status page, and Ngrok does not work because it has no UDP.

Test before 27 October with transport: both

both makes Geyser accept NetherNet and RakNet side by side. The two cannot share a UDP port, so NetherNet gets its own one through webrtc-port:

bedrock:
  clone-remote-port: false
  port: TCP_UDP_PORT
  webrtc-port: UDP_PORT
  transport: both

On a hosted server, GeyserMC's guide says UDP_PORT can be the Java server's port, since the Java server only uses it over TCP, or any other available UDP port. Only use the Java port if nothing else, such as Query or a voice chat mod, uses UDP on it. On your own machine, pick a second free port and open it for UDP.

Then test in this order:

1. Restart and read the console. Port problems show up there first.
2. From a machine outside your network, run curl http://YOUR_SERVER_IP:TCP_UDP_PORT/v1/join. That is the request from Mojang's guide, and a NetherNet server answers it with JSON that holds the server name, version and player count. A timeout means TCP does not reach Geyser. With HTTPS set up, use https:// and your domain.
3. Join from a Bedrock client on 26.40 or newer, as GeyserMC suggests.
4. Before the 27th, switch to transport: nethernet for one more test. Mojang's 26.40 notes describe the client checking a server for NetherNet support first, and until 26.60 a client whose check fails can still get in over RakNet. A good join under both does not prove that NetherNet works.

GeyserMC's plan for both: once 26.60 is out and everyone has updated, switch to nethernet and close the old RakNet port.

Who needs both in the meantime? The setup guide says NetherNet "is supported fully by 26.50+", while some versions, "such as 26.40, fetch the server's MOTD and player count over RakNet". GeyserMC's post recommends both if some of your players are still on versions older than 26.40.

The trust prompt and HTTPS

Built-in signaling uses plain HTTP by default, so the first time a player joins, Minecraft asks "Trust on First Use?". According to Mojang's onboarding guide, the client then remembers the server's key and connects silently as long as that key stays the same. The key, not the address, is what the player trusted. Mojang's 26.50 changelog also fixed trusted servers asking again after a client restart.

Geyser keeps that key in nethernet/identity.pem inside its config folder, and its source code warns that "a new identity means every player has to confirm this server again". Keep the nethernet folder in your backups and take it along when you move the server.

HTTPS removes the prompt. GeyserMC's HTTPS guide offers two ways: a certificate in Geyser's own config, served on the same port, or a reverse proxy such as Caddy or nginx in front of the signaling port. Both need a domain that points to your server, and players must connect with that domain, not the IP. The certificate version:

bedrock:
  signaling:
    builtin:
      https:
        certificate: /path/to/fullchain.pem
        private-key: /path/to/privkey.pem
        password: ''

Paths can be absolute or relative to Geyser's config folder. Geyser reads the certificate when it starts, so restart or run geyser reload after every renewal, and keep in mind that GeyserMC's command list says a reload kicks all players. The HTTPS guide is written for people who host Geyser themselves and tells hosted users to ask their host. If you already have a certificate for your domain, you can upload the files and use the config above. Without one, Warden is the other way to avoid the prompt, at the cost of a different join address.

No spare port? External signaling with Warden

If your host cannot give Geyser a second port, use external signaling. Geyser supports providers that follow the NetherNet External Signaling (NXS) standard, and its default is Warden, which GeyserMC describes as "a free service run by Ziax, the creators of CubeCraft". When Geyser sees that the Java server already uses its port, it falls back to Warden by itself and logs where players can join. The "Not listed" guide's option "I only have the Java server port" sets it explicitly:

bedrock:
  clone-remote-port: true
  transport: nethernet
  signaling:
    mode: nxs

Players then no longer join with your Java server's address but with the address and port Geyser shows in the console, unless you register a custom domain on Warden. Warden handles HTTPS, so there is no trust prompt. Game traffic still goes straight to your server over UDP: Warden's site says it does not relay game traffic or hide the server's IP.

Two limits. GeyserMC notes that NXS "does not support live forwarding of the MOTD and player count", which are updated periodically instead, and Warden describes itself as still in active development. The console command geyser nethernet shows signaling status and diagnostics for this setup.

What your players notice

• Same address and port as before: they keep their saved server. GeyserMC: "As long as your address and port stay the same, your players can keep using the server entry they already have."
• Geyser used to share the Java port: they need the new Geyser port, or the Warden address.
• First join over plain HTTP: a one-time "Trust on First Use?" prompt. With HTTPS on your domain, or with Warden, there is none.
• TCP blocked: the server does not show up in their list. The setup guide says "without TCP your server will not show up".
• Players on Bedrock older than 26.40 can only get in while you run both and Geyser still supports their version.
• Once 26.60 is out, everyone needs your Geyser to support it, which means another Geyser update on your side.

When Bedrock players still cannot join

Most problems show up in the Geyser console. The first four rows come from GeyserMC's post, the rest from its HTTPS guide, setup guide and system properties page:

About that last row: GeyserMC's post says servers that "run in containers or behind a NAT and do not hold their public address themselves" need to tell players which public address to use. In the config, that is advertise-addresses in the builtin part of the signaling section. Without a port, Geyser uses its NetherNet UDP port:

bedrock:
  signaling:
    builtin:
      advertise-addresses:
        - 203.0.113.5

Replace the example address with your server's public IP.

If none of this fits, GeyserMC asks for three things on its Discord: where you host the server, a Geyser dump from geyser dump in the console, and a description of what you see.

Doing this on a Space-Node server

Our game panel is Pterodactyl. You add ports yourself in the panel's Network tab, free of charge: three allocations are included, and up to five on request. Pterodactyl's Wings daemon opens every allocation for both TCP and UDP (the Bindings function in allocations.go creates a TCP and a UDP binding for each port), so one extra port number carries NetherNet signaling over TCP and gameplay over UDP.

1. Open the Network tab, create an allocation and note its port.
2. Open Geyser's config and check whether it uses clone-remote-port. If it is true, set it to false.
3. Put the new port in port and set transport: nethernet. While you test, use both with a third allocation, or the Java port, as webrtc-port.
4. Restart and look for the built-in signaling line in the console.
5. If the Bedrock port changed, give your players the new one before 27 October.

Pterodactyl runs each server in a Docker container, so if players see your server in the list but time out when joining, try advertise-addresses with your server's public IP. Java, Geyser, a test webrtc-port and a voice chat port make four allocations, so ask us when you need more than three. Our support team is available from 08:00 to 20:00 UTC every day. Starting fresh? See our Minecraft server hosting plans.

FAQ

Why can't Bedrock players join my Geyser server? From Bedrock 26.60 on, the most likely reason is that Geyser still runs on RakNet, which GeyserMC says 26.60 clients no longer use. Set transport: nethernet on build 1237 or newer and open the Geyser port for TCP as well as UDP. If the server is missing from the list, TCP is blocked. If it shows up but joins time out, check UDP and advertise-addresses. Also check that your Geyser build supports your players' Bedrock version.

Does Geyser support Bedrock 26.60? Not yet on 16 October 2026: the supported versions page lists Bedrock 26.30 to 26.52. NetherNet itself works from build 1237, and the newest build that day was 2.12.0 build 1259. GeyserMC says 26.30 support goes once 26.60 support is added, so update Geyser again after 26.60 comes out.

Do players have to change their saved server? Not if the address and port stay the same. They do if Geyser used to share the Java port through clone-remote-port: give them the new Geyser port, or the Warden address from the console if you use external signaling. With HTTPS, they must connect with your domain name rather than the IP.

Does Floodgate need a change for NetherNet? GeyserMC's NetherNet post and setup guide list no Floodgate step. The switch happens in Geyser's bedrock section. The setup guide still describes Floodgate as the way to let Bedrock players join without a paid Java account, and on a proxy Floodgate can go on all servers while Geyser goes only on the proxy.

Can I keep RakNet running next to NetherNet? Yes, with transport: both, as long as webrtc-port is a separate UDP port. It helps players on versions before 26.40, and 26.40 clients that read the MOTD over RakNet. RakNet stops mattering once your players are on 26.60, and GeyserMC suggests switching to nethernet when everyone has updated.

Related guides: Geyser and Floodgate crossplay setup | GeyserMC crossplay tutorial | Connect mobile players with GeyserMC | Minecraft 26.3 server update guide