mojira.dev
BDS-23108

Transport type "nethernet" renders server inaccessible

bugs.mojang.com report.bugs.mojang.com mojira.atlassian.net
Open
58

In the current .zip packet (Build 51061361, 1.26.51.1), server.properties comes with parameter transportation=nethernet, rather than raknet.
This renders the server visible, but not accessible from the game client. Attempting to connect to the server times out with the “door” error in game.
When reverting to raknet, the server is both visible and accessible, but the console prints an error saying only nethernet is supported:


[2026-09-16 14:00:42:593 ERROR] ================ TRANSPORT TYPE ERROR ===================
[2026-09-16 14:00:42:594 ERROR] Your current connection type is not set to NetherNet. In this release, NetherNet is the only supported transport type.
[2026-09-16 14:00:42:594 ERROR] Players will not be able to connect to your game without NetherNet.
[2026-09-16 14:00:42:594 ERROR]
[2026-09-16 14:00:42:594 ERROR] To switch, set 'transport=nethernet' in server.properties.
[2026-09-16 14:00:42:594 ERROR]
[2026-09-16 14:00:42:594 ERROR] For more information, please reference the included bedrock_server_how_to.html file.
[2026-09-16 14:00:42:594 ERROR] =======================================================

Like mentioned earlier, raknet works perfectly fine (in contrast to nethernet), but is not set in server.properties by default, and despite working, reads out an error in the console log.

Environment

Windows 11 Pro 25H2 on server device.

Linked issues

is duplicated by 5

Comments 46

what is your server-udp-ports set to?

It has not been set in server.properties

Tried setting up a brand new server today as well, unable to connect. Although I’m getting the “boat” error code.

No update available for my windows client, whose build version is a bit lower than what the server was reporting:

  • Client --> Version: v26.51 Build: 51061346

  • Server --> Version: 1.26.51.1, Build ID: 51061372

I also started noticing this as of the evening of 2026-09-15 after updating my server to 1.25.51.x. My relevant config details are below.

server-port=19132

server-ip=

server-udp-ports=19132:19132

transport=nethernet

enable-lan-visibility=true

I ended up creating a test server in Crafty Controller and their new bedrock server config basically matched what I was trying and also didn’t work, so it definitely appears to be an update problem. I can confirm what @Kermit said as well. Raknet still seems to work if manually set, but throws errors in the terminal saying it won’t.

I noticed the same thing. I propagated my old server.properties file and things worked fine. I took a look at the server log and noted the warning that players would not be able to connect unless I change the config to nethernet. So I changed the config and restarted the server. Then I was not able to connect anymore. I changed it back to raknet and again it works fine. So the behavior I see is the exact opposite of what the TRANSPORT TYPE ERROR message says.

36 more comments

Update:

The issue was resolved in my environment by explicitly setting:

server-udp-ports=<PUBLIC_IP>:19174:19174

Using only:

server-udp-ports=19174

resulted in Door / InitialConnection-83 errors for all external clients.

After specifying the public IP and port mapping explicitly, external clients can connect successfully.

In case it helps someone else, my actual problem switching to nethernet was that the initial connection now happens over TCP. I set up port forwarding on my router for UDP long ago and I had to re-configure my router to forward 19132 on TCP.
Somehow when reading around and troubleshooting this before, this bit never occurred to me. Nethernet is now working for my bare metal (non-virtual, non-containerized) ubuntu 24 BDS with

server-udp-ports=19132
transport=nethernet

with port forwarding configured on my router for port 19132 on UDP and TCP.

I’ve confirmed there are 2 combined issues, which can be circumvented, but a proper fix would be nice.

TCP must be HTTPS and you must specify your external IP with the UDP port.

1: Some clients (like the PS5) require the TCP connection to be HTTPS when connecting over the internet. The server only speaks http, the client only https, so you’ll need a proxy and a domain/dns with a certificate.
(On the PS5 a local connection does work over http and the windows client has no problem connecting over the internet using http)
if curl https://<yourdomain>:<yourport>/v1/join does not show a proper (json) response, the client PS5 client will not connect to your server over the internet and show a “Door” error.

2: The server is said to advertise its IP address together with the UTP port. I have not verified this, but the solution works, so it might be true. If you don't include an IP address in the server-udp-ports property in server.properties, it will include it’s own ip address, which is a local ip-address if you’re behind a NAT router. That works on your LAN, but not over the internet. The solution is to include your external IP address in the setting.
If the IP address in the UDP port setting is wrong (or absent), the client wont' connect and give a “Boat” error.
Also make sure to set a single port, not a range of ports. The range also seems to contain a bug. I have not found a benefit of setting a range, but if you really want to, you should do so by repeating the property for every port separately. I would think they would overwrite each other, and I have not verified this.

And the PS5 client seems to cache the data for about 5 minutes, so restart it and give it some time. If the client just returns to the menu, or displays the “Terracotta” error, that’s probable caching. Be patient and retry.

PS. online-mode and allow-list should both be set to true.

Another thing which works (at least for PS5 clients) is to put both TCP and UDP on the same port and apply only the second fix (IP-address in server-udp-ports). I don’t know why this works, maybe it’s not requiring HTTPS or maybe it's not using TCP at all, but it saves you having to set up DNS and an SSL certificate.

I have been able to reproduce the previously reported behaviour where one successful authenticated client connection after BDS startup causes subsequent LAN console joins to begin working.

Environment:

BDS 1.26.63.1

transport=nethernet

online-mode=true

allow-list=true

Xbox joining through normal LAN discovery

Initial failure: Boat / InitialConnection-145

After each BDS restart, the Xbox can see the server through LAN discovery but cannot join.

I tested using bedboo, an authenticated Bedrock/NetherNet client library. A small client signs in using a Microsoft/Xbox account, connects directly to the BDS on port 19132, reaches Player Spawned, then disconnects.

BDS log then shows:

Player connected
Player Spawned
Player disconnected

Immediately afterwards, the Xbox can join normally through the LAN-visible server.

Restarting BDS resets the problem, and another successful bedboo connection is required.

I have now automated the process so that after the scheduled BDS restart, the client waits for the server to become healthy, connects once, spawns and disconnects. This has also been proven during an unattended scheduled restart.

This appears to confirm that the first successful authenticated NetherNet client connection changes some server/session state required for subsequent LAN-console joins.

The workaround does not require disabling authentication or the allow-list. Both remain enabled.

Kermit

(Unassigned)

1709138

Community Consensus

Retrieved