Nethernet and latest version (1.26.51.1) - unable to connect

[dschuermans]

Hello,

Tried setting up a brand new container today (after updating my existing and could no longer connect)

Noticed the following two things:

• Nethernet is now the default protocol
• Version mismatch with no update available for client or downgrade for server
  • Client --> Version: v26.51 Build: 51061346
  • Server --> Version: 1.26.51.1, Build ID: 51061372
• When on "bridge" network mode:
  • LAN discovery doesn't work anymor, not even when binding ports 7551:7551/udp
  • Unable to connect directly (Nethernet error code)
• When on "host" network mode:
  • LAN discovery does work, server shows up under worlds as a LAN world
  • Unable to connect (Boat error code, presumably due to version mismatch)

I'm a bit lost now on how to proceed. My setup here was a single device running 4 docker containers:

• 1 acting as a portal server, listening on default ports
• 2 survival and 1 creative server, all listening on dedicated ports (19134, 19136 and 19138) and using bridge network mode

Would first connect to portal server and from there, by clicking on buttons in a menu, get transfered to either one of the 3 servers

Now I got nothing anymore, and a little kid that's sad we can't play on the servers anymore 😬

YAML:

services:
  bds:
    image: itzg/minecraft-bedrock-server
#    network_mode: host
    environment:
      EULA: "TRUE"
#      ENABLE_BDS_V6BIND_FIX: "TRUE"
      SERVER_PORT: 19132
      SERVER_PORT_V6: 19133
#      VERSION: "1.26.51.0"
      ALLOW_LIST: "false"
      SERVER_UDP_PORTS: "19132-19133"
    ports:
      - "19132:19132/udp"
      - "19133:19133/udp"
      - "7551:7551/udp"
    volumes:
      - ./data:/data
    stdin_open: true
    tty: true

EDIT:
Feels quite similar to this bug report on the mojang tracker:

https://report.bugs.mojang.com/servicedesk/customer/portal/4/BDS-23108

EDIT2:

netstat output from inside the running container:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.11:35259        0.0.0.0:*               LISTEN      2592/dockerd
tcp       25      0 172.20.0.2:36642        150.171.109.37:443      CLOSE_WAIT  14496/bedrock_serve
tcp       25      0 172.20.0.2:36656        150.171.109.37:443      CLOSE_WAIT  14496/bedrock_serve
tcp       25      0 172.20.0.2:36666        150.171.109.37:443      CLOSE_WAIT  14496/bedrock_serve
tcp        0      0 :::19132                :::*                    LISTEN      14496/bedrock_serve
udp        0      0 127.0.0.11:38504        0.0.0.0:*                           2592/dockerd
udp        0      0 :::7551                 :::*                                14496/bedrock_serve

and finally the log output:

DEBU[0000] Using /data to match uid and gid
DEBU[0000] Resolved UID=0 from match path
DEBU[0000] Resolved GID=0 from match path
Image info: buildtime=2026-08-17T12:33:06.470Z,version=latest,revision=e2b5c995b7038062e2423496bbfee9a4f98fd64f
Looking up latest version...
Starting Bedrock server...
NO LOG FILE! - setting up server logging...
[2026-09-16 17:20:43:532 INFO] Starting Server
[2026-09-16 17:20:43:532 INFO] Version: 1.26.51.1
[2026-09-16 17:20:43:532 INFO] Session ID: 8e8da450-0c72-4960-96de-dce5af36321e
[2026-09-16 17:20:43:532 INFO] Build ID: 51061372
[2026-09-16 17:20:43:532 INFO] Branch: r/26_u5
[2026-09-16 17:20:43:532 INFO] Commit ID: 0559ac59aa24e42d30e238bc55cdb306232a6507
[2026-09-16 17:20:43:532 INFO] Configuration: Publish
[2026-09-16 17:20:43:533 INFO] Contents of server.properties: {}
[2026-09-16 17:20:43:533 INFO] Level Name: Bedrock level
[2026-09-16 17:20:43:533 INFO] Profiler config ('bootstrap.json') load result: success=1, errorMessage=(null)
[2026-09-16 17:20:43:533 INFO] No CDN config file found at: cdn_config.json for dedicated server
[2026-09-16 17:20:43:533 INFO] Game mode: 0 Survival
[2026-09-16 17:20:43:533 INFO] Difficulty: 1 EASY
[2026-09-16 17:20:43:537 WARN] Content logging to console is disabled.  Enable it with content-log-console-output-enabled=true in server.properties
[2026-09-16 17:20:43:538 INFO]

#####################################################
#                                                   #
#               LOADING VANILLA WORLD               #
#                                                   #
#####################################################
[2026-09-16 17:20:44:165 INFO] Opening level 'worlds/Bedrock level/db'
[2026-09-16 17:20:44:166 INFO] Accepting clients on [::]:19132
[2026-09-16 17:20:44:209 INFO] Pack Stack - None
[2026-09-16 17:20:44:467 INFO] Signed in to signaling service successfully
[2026-09-16 17:20:45:621 INFO] Server started.
[2026-09-16 17:20:45:621 INFO] ================ TELEMETRY MESSAGE ===================
[2026-09-16 17:20:45:621 INFO] Server Telemetry is currently not enabled.
[2026-09-16 17:20:45:621 INFO] Enabling this telemetry helps us improve the game.
[2026-09-16 17:20:45:621 INFO]
[2026-09-16 17:20:45:621 INFO] To enable this feature, add the line 'emit-server-telemetry=true'
[2026-09-16 17:20:45:621 INFO] to the server.properties file in the handheld/src-server directory
[2026-09-16 17:20:45:621 INFO] ======================================================

[hoaxlayer]

Came here to a similar problem, logs indicate that it is expecting to receive a property regarding Nethernet (TRANSPORT TYPE ERROR section) but I don's see it documented anywhere:

#####################################################
#                                                   #
#              CREATING VANILLA WORLD               #
#                                                   #
#####################################################
[2026-09-16 11:37:10:301 INFO] Opening level 'worlds/Wilderness Bound/db'
[2026-09-16 11:37:10:346 INFO] Pack Stack - None
[2026-09-16 11:37:11:465 INFO] Signed in to signaling service successfully
[2026-09-16 11:37:11:667 INFO] IPv4 supported, port: 19132: Used for gameplay and LAN discovery
[2026-09-16 11:37:11:667 INFO] IPv6 supported, port: 19133: Used for gameplay
[2026-09-16 11:37:11:720 INFO] Waiting for Minecraft services...
[2026-09-16 11:37:13:222 INFO] Server started.
[2026-09-16 11:37:13:222 ERROR] ================ TRANSPORT TYPE ERROR  ===================
[2026-09-16 11:37:13:222 ERROR] Your current connection type is not set to NetherNet. In this release, NetherNet is the only supported transport type.
[2026-09-16 11:37:13:222 ERROR] Players will not be able to connect to your game without NetherNet.
[2026-09-16 11:37:13:222 ERROR] 
[2026-09-16 11:37:13:222 ERROR] To switch, set 'transport=nethernet' in server.properties.
[2026-09-16 11:37:13:222 ERROR] 
[2026-09-16 11:37:13:222 ERROR] For more information, please reference the included bedrock_server_how_to.html file.
[2026-09-16 11:37:13:222 ERROR] =======================================================
[2026-09-16 11:37:13:222 INFO] ================ TELEMETRY MESSAGE ===================
[2026-09-16 11:37:13:222 INFO] Server Telemetry is currently not enabled. 
[2026-09-16 11:37:13:222 INFO] Enabling this telemetry helps us improve the game.
[2026-09-16 11:37:13:222 INFO] 
[2026-09-16 11:37:13:222 INFO] To enable this feature, add the line 'emit-server-telemetry=true'
[2026-09-16 11:37:13:222 INFO] to the server.properties file in the handheld/src-server directory
[2026-09-16 11:37:13:222 INFO] ======================================================

Image probably needs to be updated in order to support it.
It's strange that being server software (and required) it's not set by default by Mojang themselves. Weird.

[tomuk5]

same here, setting transport=nethernet in the server.properties file allows the server to start but no clients can connect to it - same error pattern as OP.

interesting side effect running in apps (docker) on truenas, this image and server version now gets stuck in 'deploying' state but the logs are shown and the console also wont attach to the container either

[Eric-Meier]

My server is able to continue to operate and players can join by setting "transport=raknet" in server.properties. I get the error in the startup logs that players won't be able to join but they can.

[esarella]

I added transport=nethernet in the server.properties and had to manually add server on my Ipad. Once my ipad connected everything started connecting without any issues

[itzg]

My image only downloads and runs the Mojang supplied binary. I'm not sure if there is anything I can do to address this issue.

I can convert this to a discussion so that the findings can conveyed in that way.

[adzule]

@itzg I think it may be due to changes with the latest 1.26 that just released. Sounds like transport layer raknet is no longer supported going forward and nethernet is required. The dockerfile is configured to only expose 19132:19132/udp and the new nethernet protocol also needs 19132:19132/tcp as well as udp to negotiate the WebRTC. If I'm reading right it also needs an additional set of ports opened to do the connections in such as - "49152-49202:49152-49202/udp" that need to be specified as the allowed range server-udp-ports=49152-49202 in the server.properties

[jon-dez]

I hit this on 1.26.51.1 as well. The image downloads and runs the Mojang binary; NetherNet itself is in BDS. What is missing is image support: property-definitions.json has no transport or server-udp-ports, so TRANSPORT= / SERVER_UDP_PORTS= are ignored. EXPOSE and the examples are still UDP-only. The healthcheck is RakNet mc-monitor status-bedrock, which will never succeed on this build.

What the current client actually does (not RakNet first):

1. GET /v1/join on the address you typed, HTTPS then HTTP on that port (explicit port skips :443/:80).
2. First 2xx → NetherNet. POST /v1/join/{id} carries the WebRTC SDP.
3. Gameplay is ICE (Interactive Connectivity Establishment) over UDP, using ports from server-udp-ports.
4. If /v1/join never answers, it falls back to RakNet, which this BDS build refuses (NetherNet is the only supported transport).

On the wire that means TCP server-port (19132) for HTTP signaling, plus a UDP range for ICE. I have not tested LAN discovery (UDP 7551) or host-vs-bridge LAN visibility; the notes below are the WAN / Add Server path only.

server-udp-ports must advertise an address the client can actually reach. A range like 19140-19155 only constrains the local bind. Behind Docker bridge (or any extra NAT) that bind is a private address, so ICE candidates are unusable. Use Mojang’s mapping form server-udp-ports=<reachable-ip>:19140-19155:19140-19155 (<reachable-ip> is the host or WAN address you published, not the container IP). Range-only is enough when the server already listens on that same reachable address (network_mode: host).

Compose (mount the script next to the file). Set PUBLIC_IP to the address clients should send ICE UDP to:

services:
  bds:
    image: itzg/minecraft-bedrock-server
    entrypoint: ["/bin/bash", "/opt/ensure-nethernet.sh"]
    environment:
      EULA: "TRUE"
      SERVER_PORT: "19132"
      PUBLIC_IP: "203.0.113.10"
      ICE_UDP_START: "19140"
      ICE_UDP_END: "19155"
    ports:
      - "19132:19132/tcp"
      - "19140-19155:19140-19155/udp"
    volumes:
      - ./data:/data
      - ./ensure-nethernet.sh:/opt/ensure-nethernet.sh:ro
    healthcheck:
      test: ["CMD-SHELL", "bash -c 'echo >/dev/tcp/127.0.0.1/19132'"]
      interval: 30s
      timeout: 5s
      start_period: 60s
    stdin_open: true
    tty: true
    restart: unless-stopped

ensure-nethernet.sh writes the keys property-definitions.json will not map, then execs the image entrypoint:

#!/bin/bash
# property-definitions.json does not map transport / server-udp-ports.
set -euo pipefail

: "${PUBLIC_IP:?set PUBLIC_IP to the address clients send ICE UDP to}"
ICE_UDP_START="${ICE_UDP_START:-19140}"
ICE_UDP_END="${ICE_UDP_END:-19155}"
PROPS="${PROPS:-/data/server.properties}"

mkdir -p "$(dirname "$PROPS")"
touch "$PROPS"

upsert() {
  local key="$1" val="$2"
  if grep -qE "^${key}=" "$PROPS"; then
    sed -i "s|^${key}=.*|${key}=${val}|" "$PROPS"
  else
    printf '%s=%s\n' "$key" "$val" >>"$PROPS"
  fi
}

upsert transport nethernet
upsert server-udp-ports "${PUBLIC_IP}:${ICE_UDP_START}-${ICE_UDP_END}:${ICE_UDP_START}-${ICE_UDP_END}"

exec /opt/demoter-entry.sh "$@"

[dschuermans]

@jon-dez makes sense what you're saying, will give this a try later today 🙏

Any idea though if PUBLIC_IP needs to be an actual IP, or are hostnames accepted too? (having a dynamic IP and all 😅 )

[jon-dez]

@dschuermans I've only tested this with an IP address, and the source my AI agent pulled from (https://minecraft.wiki/w/Server.properties) only shows examples with IPs. With a bit of modification to the script I believe it could be usable with dyndns (by querying the dns record before the server starts and setting PUBLIC_IP value), though if the dns record changes while the server is still up then it would break.

[jon-dez]

Follow-up on SERVER_UDP_PORTS advertised mapping: a hostname is not accepted there.

Mojang’s form is an IPv4 or IPv6 literal (<reachable-ip>:19140-19155:19140-19155). I tried a DNS name in that field. The server still started and GET /v1/join was 200, but the Bedrock client failed the join with error Door. Switching the same mapping back to the reachable IPv4 literal worked.

Add Server can still use a hostname for TCP /v1/join. ICE advertisement in server-udp-ports has to be an address, not a name.

See also #675.