Failed to start Geyser on 0.0.0.0: fix "Address already in use" and the Bedrock port

What "Failed to start Geyser on 0.0.0.0" means

"Failed to start Geyser on 0.0.0.0:19132" means Geyser could not open UDP port 19132 for Bedrock players, and nearly every time the reason is that another program or plugin already has that port. The 0.0.0.0 part is not the problem. It stands for every network address of the machine and is Geyser's default. The number after the colon is the port Geyser asked for, so on your server it can be a different one.

[WARN] Not modifying handlers due to exception: io.netty.channel.unix.Errors$NativeIoException: bind(..) failed with error(-98): Address already in use
[ERROR] Failed to start Geyser on 0.0.0.0:19132
[ERROR] Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..) failed with error(-98): Address already in use

Address already in use is the reason, and error(-98) is Linux saying the same thing as a number. Geyser does not try another port and does not try again later. Until that port is free and the server restarts, nothing listens for Bedrock at all, so no Bedrock player can join.

If the address in the message is not 0.0.0.0, Geyser adds a green suggestion to set address under bedrock back to 0.0.0.0. Take it. An address the machine does not have stops Geyser just as surely, only with a different error.

Simple Voice Chat port already in use: Geyser and voice chat on one port

Simple Voice Chat and Geyser both listen on UDP, and one UDP port can only have one listener, so if both are set to the same number, whichever starts second fails. We have fixed this on customer servers more than once: Geyser moved onto the voice chat port, and voice chat put on Geyser's NetherNet port. When Geyser loses, you get the lines above. When voice chat loses, it says so itself:

Failed to run voice chat at UDP port 24454, make sure no other application is running at that port

After that line Simple Voice Chat switches itself off, and it stays off until the server starts again. So moving one of them to another port is only half the fix. Restart once afterwards, then check the console for both Started Geyser on UDP port and Simple Voice Chat's Voice chat server started at.

On a Velocity proxy, Geyser's folder is plugins/Geyser-Velocity. On a Fabric or NeoForge server, voice chat keeps its file in config/voicechat.

Watch the -1 in particular. Simple Voice Chat's own config warns against it, because UDP on the Minecraft port can also be used by the server query. Combine port=-1 with Geyser's clone-remote-port: true and voice chat and Geyser both reach for the same number. Give each one a port of its own. Players never type the voice chat port; the mod gets it from the server when they join.

Geyser clone-remote-port and the Bedrock port

clone-remote-port: true makes Geyser take the Java server's port, 25565 by default, as its Bedrock port. It is meant for hosts that change the Java port on every start and expect Bedrock on that same number. TCP and UDP are separate, so before NetherNet the Java server on TCP 25565 and Geyser on UDP 25565 could share the number. NetherNet changed that. Geyser's built-in signaling, the step where a Bedrock player first finds the server, runs over TCP on the Bedrock port, and the Java server already holds TCP 25565. Geyser notices and tells you:

[WARN] Built-in signaling cannot use port 25565 because the Java server already uses it. Bedrock players can still find this server through the external signaling service at ... instead.

So Geyser falls back to an outside signaling service, and your Bedrock players depend on a server you do not run. If your host gives you a separate Bedrock port, turn clone-remote-port off and put that port in port. Signaling then runs on your own server again, and voice chat's -1 can no longer land on Geyser's port.

NetherNet and Geyser: "NetherNet will not start"

Since Bedrock 26.60, released on 27 October 2026, Bedrock joins servers over NetherNet, and with transport: both Geyser needs two UDP ports: port for the older RakNet connection and webrtc-port for NetherNet. Set them to the same number, or leave webrtc-port at 0, which means "use port", and NetherNet refuses to start:

[INFO] Started Geyser on UDP port 19132
[ERROR] NetherNet will not start! With the "both" transport, RakNet and NetherNet each need their own UDP port, but both are set to 19132. Set "webrtc-port" in the "bedrock" section to a different available port.

The first line looks like success, and that is what makes this one nasty. Only RakNet started, and current Bedrock versions no longer join over RakNet, so your players still cannot get in. Give webrtc-port its own free number and restart. Geyser's config says plainly that changes to transport need a restart, so a reload is not enough here.

bedrock:
  address: 0.0.0.0
  port: 19132
  webrtc-port: 19133
  transport: both

A healthy start prints two lines, one for each side. If you only see the first, NetherNet is not running.

[INFO] Started Geyser on UDP port 19132
[INFO] Built-in signaling started on http://0.0.0.0:19132, with NetherNet on UDP port 19133

Players still type only the first port. Geyser hands out the NetherNet port while they connect, which means it has to be reachable from outside as well. At home you forward three things to the machine: TCP and UDP on the Bedrock port, and UDP on the NetherNet port.

Built-in signaling could not start: Address already in use on TCP

"Built-in signaling could not start" with Failed to bind HTTP signaling to /0.0.0.0:19132 means another program already listens on TCP 19132, the Bedrock port number. RakNet still starts in this case, so the log looks half fine, but NetherNet players have nothing to talk to.

[INFO] Started Geyser on UDP port 19132
[ERROR] Built-in signaling could not start
java.net.ConnectException: Failed to bind HTTP signaling to /0.0.0.0:19132: Address already in use

On a game server, look at web maps first. BlueMap, Dynmap and squaremap each run a small web server on TCP. We have seen BlueMap on the Bedrock port number, which caused no trouble until NetherNet needed TCP there. Move the map to its own port.

When the NetherNet port itself is taken

A clash on webrtc-port shows up differently. With stun-discovery: true, the default, the WebRTC library complains first and signaling gives up:

WARN    UDP socket binding failed on port 19133, errno=98
[ERROR] Built-in signaling could not start
java.net.ConnectException: Could not start STUN discovery on udp/19133: Failed to create STUN UDP mux monitor (Inappropriate ioctl for device)

With a fixed address in advertise-addresses and stun-discovery: false, we got no warning at all: the console printed the healthy NetherNet line while the port belonged to something else. So a clean log is not proof. When NetherNet players time out and nothing looks wrong, check which other plugin uses the webrtc-port number.

Geyser unable to connect to world: Geyser runs, Bedrock still can't join

When the console shows Started Geyser on UDP port 19132 and the NetherNet line, and Bedrock players still get Unable to connect to world, look at the port they typed before you touch the server. A Bedrock server entry is an address plus a port, and the game keeps both until someone edits them.

To fix an entry, open the Servers tab in Bedrock, edit the server and correct the port, or delete it and add it again. On Lodehost the right port is the Bedrock port next to your address in the panel. For players on Xbox, PlayStation or Switch, who cannot add servers the same way, see the crossplay guide.

Minecraft error code Terracotta on a Geyser server

Error code Terracotta is one of Bedrock's catch-all errors, and we saw it on 7 November 2026 when a player's saved server still pointed at a Bedrock port where nothing listened any more. The port had been changed that evening. Geyser was fine on the new port; the player's entry simply had the old one.

Bedrock uses the same code for more than one kind of failure, so read it together with where it happens. When Terracotta appears for one server only, and especially right after its Bedrock port changed, check the port in that server entry first. When every server and Realm gives the same code, the cause is not your Geyser config; look at the device, its connection or the Microsoft account.

Fix a Geyser port error in five steps

1. 1

   Find the Geyser lines

   Search the console or logs/latest.log for Started Geyser, Failed to start Geyser, NetherNet will not start and signaling. The first Geyser error after the server starts is the one to fix.

2. 2

   List every port on the server

   Write down port and webrtc-port from Geyser's config, port from voicechat-server.properties, the port of any web map, and server-port from server.properties.

3. 3

   Give each listener its own number

   No two programs can share a UDP port, and Geyser also needs TCP on its Bedrock port. Move whatever does not belong there. On Lodehost, keep Geyser's ports as they are and give the other plugin a port from the Ports tab, or ask us on a server outside Poland.

4. 4

   Restart, do not reload

   Geyser only applies transport and signaling changes on a restart, and Simple Voice Chat stays off after a port clash until the server starts again.

5. 5

   Check the console, then join from Bedrock

   Look for Started Geyser on UDP port and Built-in signaling started on. Then join from a phone or tablet with the address and the Bedrock port, the same way your players do.