Minecraft Bedrock Port 19132: Fix “Unable to Connect to World”
Bedrock Dedicated Server (BDS) now connects players over NetherNet. Current builds ship with transport=nethernet, BDS 1.26.51 already prints "NetherNet is the only supported transport type" when it is set to RakNet, and Bedrock 26.60, released on October 27, 2026, stopped RakNet in the clients too. Under NetherNet a player's client reaches server-port (19132 by default) over TCP for signaling, then plays over UDP on a port BDS picks for each player. server-portv6 (19133) is ignored, because one dual-stack socket listens on server-port. The UDP-only advice written for RakNet no longer works. Microsoft's official BDS guide covers installing and starting the server.
Fast isolation test
- Confirm the BDS process starts without a bind error.
- Join from a Windows or mobile Bedrock client on the same local network.
- Join from a Windows or mobile client on a different internet connection.
- Only after those work should you diagnose a console path.
This separates server/firewall problems from console UI restrictions.
1. Confirm the port and transport
Stop the server and inspect server.properties:
server-port=19132
transport=nethernetA missing transport line means raknet, which players on current versions cannot join. If another process already owns the chosen port, BDS will log a bind failure. Either stop the conflicting process or choose a different port and give players that port. server-ip is a BDS property under NetherNet only: leave it empty to listen on every interface.
2. Allow TCP signaling and UDP play through the firewall
Under NetherNet, open TCP on server-port and the UDP ports BDS gives players. By default BDS picks each player's UDP port from the system's free ports, so pin a range with server-udp-ports, at least as large as max-players, and open exactly that. On Ubuntu with UFW:
# server.properties
server-udp-ports=49152-49200
sudo ufw allow 19132/tcp
sudo ufw allow 49152:49200/udpLAN discovery uses UDP 7551; open it only if players on the same network should see the server as a LAN game. On Windows, create an inbound rule for the BDS executable, or for TCP server-port and the same UDP range. If a hosting provider has a separate network firewall or security group, it must also allow that traffic. A local firewall rule cannot override a provider-level block.
3. Forward the ports when self-hosting
For a home server, forward external TCP 19132 to the machine's stable local address, and forward the UDP range from server-udp-ports too. If the router maps players to other external ports, or your public address differs from the machine's, tell BDS with the external form, where both ranges have the same length: for example server-udp-ports=203.0.113.10:19132-19140:32000-32008. Test from outside the home network; joining the public address from inside can fail on routers without NAT loopback even when external players can connect.
If the router's public address differs from the address shown by an external IP check, the connection may be behind carrier-grade NAT. In that case normal inbound forwarding may be unavailable; ask the ISP for a public address, use a tunnel that carries both TCP and UDP, or move the server to a public host.
4. Match the Bedrock version
Update BDS and the client to compatible current versions. A reachable port cannot translate an old server protocol into a new client protocol. If the server works until an add-on is enabled, restore the pre-change backup and test the packs one at a time using the Bedrock add-on installation guide.
5. Do not change movement authority to fix routing
Settings related to server-authoritative movement affect gameplay validation. They do not open ports, repair NAT, or make a console discover a custom address. Keep gameplay settings at documented defaults while diagnosing connectivity so that one change does not create a second problem.
Console custom-server limitation
Windows and mobile Bedrock clients expose a custom-server address flow. Xbox, PlayStation, and Nintendo Switch commonly expose Realms and featured servers but not a reliable native custom-IP field. A missing “Add Server” button on console is therefore not proof of a firewall error and usually cannot be fixed by changing Microsoft family permissions.
Some communities use a LAN discovery bridge, friend-bot, or DNS-based workaround. These are unofficial, platform-sensitive, and may stop working after a game or console update. Minecraft's own overview advertises joining custom servers from mobile and PC, while Aternos documents a separate console bridge process. For the most reliable native console experience, use Realms or a featured server.
Symptom checklist
| Symptom | Likely area | Next check |
|---|---|---|
| BDS logs "NetherNet is the only supported transport type" | transport missing or set to raknet | Set transport=nethernet and restart. |
| BDS logs a bind error | Port conflict or permissions | Find the process using the port or choose another port. |
| Joins fail although TCP 19132 is open | UDP play ports blocked | Pin server-udp-ports and open that UDP range. |
| LAN works, internet does not | Router forwarding, provider firewall, CGNAT, or wrong public address | Test from cellular data and compare the router WAN address. |
| Windows/mobile works, console cannot add the address | Console client limitation | Use Realms/featured servers or evaluate an unofficial bridge. |
| No client works after an update | Version mismatch or failed BDS update | Read the startup log and confirm the current binary. |
| Only one world fails | World or add-on issue | Start a blank world, then restore and test packs individually. |
Related Bedrock guides
- Install behavior and resource packs
- Minecraft cross-platform and console options
- Compare BDS hosts, Realms, Aternos, and self-hosting
On a Supercraft Bedrock server this is already set: the panel writes transport=nethernet, and both the server port and the per-player UDP ports are open, so players only need your address and port.
Host a Minecraft Bedrock server with Supercraft if you want a managed public BDS endpoint, backups, and file access.