Set up NetherNet on your Geyser server

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.

RakNet is the older connection method; NetherNet is the newer one. Checked on 12 October 2026, the official Geyser download 2.11.3 build 1251 includes NetherNet, but its default remains raknet. You do not need the archived experimental GeyserNetherNet extension. Configure the method deliberately and restart.

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:

1. The game makes an initial TCP connection, called signaling. Geyser sends the address and UDP port for gameplay.
2. The game connects to that UDP destination. A successful TCP port check only helps with the first stage.

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
    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.

If you intentionally accept both connection methods

Replace YOUR_PUBLIC_IP with your reachable public IP before saving this configuration:

bedrock:
  address: 0.0.0.0
  port: 19132
  clone-remote-port: false
  transport: both
  webrtc-port: 19134
  signaling:
    mode: builtin
    builtin:
      advertise-addresses:
        - "YOUR_PUBLIC_IP:19134"

This uses TCP 19132 for signaling, UDP 19132 for RakNet and UDP 19134 for NetherNet. Publish and permit all three. The two UDP services need different ports. Players initially contact the signaling port, not the advertised gameplay port. Use RakNet for a compatibility transition and recheck supported transports before updates.

Check versions and authentication before blaming ports

Geyser supports Bedrock 26.30-26.52 and emulates a Java 26.2 client. The 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

Enter your public server address in the NetherNet connection test. It checks the initial contact and shows your next steps. Then test a full join with a Bedrock client from another network.

You can view the server name, version and player count in the Minecraft server status checker. Choose Bedrock to check a NetherNet server, then join in Minecraft to verify the game connection.

From another network, check plain HTTP signaling:

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.

On cloud NAT, check the public advertisement as in this Oracle-hosted case. Joining worked after correction despite remaining warnings. Test the connection before changing more settings.

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. This build 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.

Sources

Primary sources checked on 12 October 2026. Version and build references describe that review date.

• Official Geyser current-build metadata
• Geyser supported versions
• Geyser configuration at reviewed build
• Geyser NetherNet implementation at reviewed build
• Geyser port forwarding
• Minecraft named error codes