Bedrock friends cannot join your existing Geyser server
Java players may still join while Bedrock players see NetherNet, Door, or extra details such as InitialConnection-83. The official error reference describes NetherNet as a multiplayer connection error. Record the full error and client/server versions. Check TCP signaling first, then gameplay UDP. If both work, check versions and authentication.
For your official Bedrock Dedicated Server, use the BDS NetherNet guide.
NetherNet is now required: Bedrock 26.60 was released on 27 October 2026. According to Geyser, clients from 26.60 onward no longer connect over RakNet. Update Geyser and use transport: nethernet; switching back to RakNet does not fix current clients.
Configure a direct NetherNet connection
A port is a numbered connection endpoint. TCP and UDP are different traffic types, so permitting TCP does not permit UDP with the same number. NetherNet joins happen in two stages:
- The game makes an initial TCP connection, called signaling. Geyser sends the address and UDP port for gameplay.
- The game connects to that UDP destination. A successful TCP port check only helps with the first stage.
Hosting on your PC or NAS? Find your public IP without renting a server explains checking from the home network and comparing the router WAN address. Do not advertise a local PC address as your public endpoint.
Update Geyser from the official downloads, back up your config.yml, and edit its existing bedrock section. Replace YOUR_PUBLIC_IP with your reachable public IP before saving; Geyser does not fill this placeholder automatically:
bedrock:
address: 0.0.0.0
port: 19132
clone-remote-port: false
transport: nethernet
webrtc-port: 0
signaling:
mode: builtin
advertise-addresses:
- "YOUR_PUBLIC_IP:19132"
Allow TCP 19132 and UDP 19132 for this configuration. webrtc-port: 0 uses bedrock.port. Geyser uses one WebRTC UDP listener for this setup; it does not require one allocated UDP port per player. WebRTC is the technology behind the game connection, not a separate service you must install.
A public IP is reachable from outside your network. A LAN IP, often starting with 192.168. or 10., is local. The advertised address is the destination Geyser tells players to use. The bind address is where Geyser listens locally. Keep address: 0.0.0.0 for local interfaces; do not bind to a public IP your machine does not own, or to loopback 127.0.0.1 for NetherNet.
NAT is address and port translation by your router or provider. If public UDP 20132 reaches Geyser UDP 19132, advertise YOUR_PUBLIC_IP:20132. The TCP signaling mapping remains separate. You can also set -DgeyserAdvertiseAddresses=YOUR_PUBLIC_IP:20132 before -jar; that JVM setting overrides the configuration list. Check startup flags if your edits seem ignored.
Allow both paths and restart
Allow TCP 19132 and UDP 19132 in the server firewall, router forwarding and provider firewall. The router's forwarding rule sends incoming traffic to the server's local address. For rented hosting, ask for matching panel allocations.
For Docker, add these publications to the existing service without replacing its data mounts:
ports:
- "19132:19132/tcp"
- "19132:19132/udp"
Keep the existing Java TCP publication too. For translated gameplay ports, use 20132:19132/udp. Docker runs Geyser in a container which may otherwise advertise a private container address.
Stop the running server or proxy gracefully, then start it normally after configuration changes. Do a full restart, not just /geyser reload. For Docker port changes, recreate the service with docker compose up -d while preserving its existing volume. For hosted servers, use the panel restart and inspect its startup logs.
Do you still need transport: both?
Use nethernet for clients from 26.60 onward. To also accept older, Geyser-supported clients over RakNet, choose both and reserve a separate UDP port. First check the supported version range.
Check versions and authentication before blaming ports
Check the official supported-versions page for Bedrock compatibility and the Java client Geyser emulates. Your Java server must accept that client version. An “outdated” message can concern the Java side even when Bedrock is supported. ViaVersion helps Java protocol compatibility; it does not add unsupported Bedrock versions to Geyser.
Keep the correct Geyser artifact for your platform. Fabric/NeoForge must match their supported Java game version. Keep existing Floodgate authentication and Java backend settings; changing transport does not replace them. Use the crossplay guide for authentication checks.
In an existing Velocity/BungeeCord network, Geyser remains on the public proxy. A proxy is the entry server forwarding players to individual Java servers, called backends. Check that Java players reach those same backends.
Inspect startup logs for port conflicts, unavailable native WebRTC libraries or failure to create state. Preserve the nethernet directory beside Geyser's configuration, including its signing identity. Deleting that identity can force players to confirm the server again. If Geyser reports an unsupported OS or architecture, resolve that startup issue first.
Test introduction and gameplay separately
Check signaling with the NetherNet connection test or this curl command from another network:
curl --fail --max-time 10 http://YOUR_PUBLIC_IP:19132/v1/join
For HTML, a timeout or 404, check signaling and routing. Use the real HTTPS hostname if you configured TLS. If you get server JSON, join with a Bedrock client from outside your network, for example through a mobile hotspot. That also checks the join POST and gameplay UDP.
Optionally, the server status checker in Bedrock mode shows the server name, version and player count. It does not replace a join test.
| Symptom | Next check |
|---|---|
| TCP works but joining times out | Public advertised UDP destination and its full forwarding path |
| 30-second handshake timeout | Compare advertised address with router/cloud NAT and UDP rules |
juice: Send failed, errno=101 | Compare routing and offered addresses, then test a join |
| Settings revert after restart | Panel overrides and JVM properties |
| Only one player fails | Client network, IPv4/IPv6 route, supported version and console connector |
IPv4 and IPv6 are different address formats. Check both routes if your hostname publishes both, and use bracketed IPv6 advertisements such as [YOUR_PUBLIC_IPV6]:19132. CGNAT means your internet provider shares a public IP between customers; your own router forwarding may not create public IPv4 access. Choose a verified reachable address or a service explicitly supporting the necessary signaling and UDP paths. Test gameplay UDP even after successful external signaling registration.
Console connector apps add another path. Test a directly configurable mobile or Windows Bedrock client first. Check NetherNet with a real join instead of an old RakNet-only status checker.
Hosting and server-network constraints
For the direct example, budget one TCP signaling listener and one UDP gameplay listener per instance. For both, budget the TCP listener and two UDP listeners. Multiple instances on one public IP need distinct usable port allocations. This budget concerns listeners, not one port allocation per player; ask your host which allocations are available.
Ask your host: “I run Geyser YOUR_GEYSER_VERSION with NetherNet. Please confirm my initial TCP port, advertised UDP gameplay port, and extra RakNet port if I use both. Do startup overrides or my existing Java TCP port prevent signaling from starting?”
Reserve a separate TCP port for Geyser's initial connection. Built-in signaling cannot share the Java TCP listener through clone-remote-port. Check the startup log for that port conflict: Geyser disables built-in signaling and can fall back to an external service. If you use nxs or hybrid, follow its documented connectivity checks.
Configure your HTTP reverse proxy to forward GET /v1/join and POST /v1/join/{networkId} with request and response bodies intact. Route gameplay UDP separately and arrange its DDoS protection. Review legacy RakNet mitigation rules too. Test your hostname-routing plugins: issue 6710 reports URL-shaped virtual host values on Velocity. Check that your plugins handle them.
TLS encrypts the initial HTTP connection. For TLS, configure PEM certificate/key files or PKCS12 under bedrock.signaling.builtin.https. Use a trusted certificate to avoid the plain-HTTP first-trust prompt; check its name, trust and expiry. Pass signaling without browser logins, redirects or CAPTCHAs. Add a reachable UDP gameplay path alongside an HTTP-only tunnel.
Interpret current error reports
As of 29 October 2026, these reports concern the versions and platforms listed. Update Geyser and retest before applying a reported workaround.
| Message / symptom | Report and next step |
|---|---|
| iPhone/iPad fails while Windows works | Check HTTPS signaling; see the HTTPS guide for iOS and iPadOS. A universal HTTPS requirement is not confirmed. |
GET /v1/join succeeds, POST /v1/join/{networkId} returns 500 | #6810, open: reported on build 1265 with hybrid; builtin worked in comparison. Only change mode deliberately if you do not need the external entry point. |
InitialConnection-122, NetherNetDataChannelClosed, 30-second handshake timeout | #6807, closed on 27 October: Alpine/musl on ARM64, build 1265; switching to a glibc image worked in the report. The maintainer identifies the 26 October build as resolving it, confirmed by the reporter. |
libdatachannel-java.dll blocked, NetherNet unavailable | #6822, open: Windows 11 Smart App Control. Inspect Code Integrity and startup logs; do not routinely disable protection. |
Duplicate handler name: rak-error-handler with NXS | #6824, reported on build 1270, closed on 27 October. The maintainer points to the 26 October build as resolving it. Retest after updating; preserve the full stack trace and signaling mode if it recurs. |
Officially documented: Since build 1272, Geyser supports HAProxy headers for NetherNet gameplay. Configure trusted HAProxy IPs; previous RakNet proxy settings alone are insufficient. See the Geyser update from 26 October.
Sources
Sources checked: 29 October 2026.