Connectivity Problem with Minecraft Bedrock - Bedrock server UDP responses not reaching clients

Technical Support
, ,
1

System Information

Field Value
Operating System Linux - Debian GNU/Linux 13 on x86_64
Product AMP ‘Deimos’ v2.7.2.8 (Mainline)
Virtualization Docker
Application Minecraft Bedrock
Module GenericModule
Running in Container Yes
Current State Ready

Problem Description

Issue

I am hosting a Minecraft Bedrock dedicated server on this VPS. The server starts correctly, loads the world, and binds to UDP port 19132 without any errors. The Bedrock server reports “Server started” and appears to be functioning normally.

However, external clients cannot connect to the server even though the port is open and reachable. To diagnose the issue, I performed a packet capture on the VPS using tcpdump.

The results show that inbound UDP packets from the client reach the VPS normally. Outbound UDP packets are also sent, but they are always exactly 33 bytes in length. This is the size of the initial RakNet ping, not the full Bedrock response packet. A proper Bedrock server should send a larger response packet of around 140 to 180 bytes containing the server information and MOTD.

Because only the small 33 byte packets leave the VPS, the required Bedrock response packet never reaches the client. As a result, the Minecraft client cannot complete the handshake and cannot connect to the server.

This behavior strongly suggests that larger outbound UDP packets on port 19132 are being blocked, filtered, or truncated by an upstream network rule, firewall policy, or virtualization layer within Hostinger’s infrastructure.

Evidence:

The server is listening on UDP 19132

Inbound UDP packets arrive normally

Outbound packets are always 33 bytes instead of the expected larger Bedrock response

Clients cannot connect because they never receive the required response packet

Request:
Please verify whether full UDP passthrough is enabled on this VPS and whether any upstream filtering, NAT rules, anti DDoS policies, or packet size restrictions are affecting UDP traffic on port 19132. Minecraft Bedrock requires unfiltered bidirectional UDP traffic to function correctly.

Reproduction Steps

  • Deploy a Minecraft Bedrock dedicated server on the VPS using the default installation method provided by Hostinger.
  • Start the Bedrock server and confirm that it is running and listening on UDP port 19132 using standard Linux networking tools.
  • Attempt to connect to the server from an external device such as a phone or computer using the public IP and port 19132.
  • Run a packet capture on the VPS to monitor UDP traffic on port 19132 while attempting to connect from the external device.
  • Observe that inbound UDP packets from the client reach the VPS normally but outbound packets from the server are always only 33 bytes in size.
  • Confirm that the Minecraft client cannot connect because it never receives the larger Bedrock response packet that is required for the connection process.
2

Because of a client version mismatch I opened the AMP interface and updated AMP and Minecraft Bedrock and now am unable to connect, just times out so could be the same problem?

BTW I’m running a dedicated server over a LAN at home!

3

I got a workaround on another thread in case someone can benefit from this. At least we can get 1 working bedrock server.

:star: What “Enable LAN Visibility” actually does

When Enable LAN Visibility = true, the Bedrock server:

1. Starts sending LAN broadcast beacons

These are small UDP packets sent to the client’s IP directly.

2. Switches to a different RakNet handshake path

The LAN handshake is smaller, simpler, and uses different packet sizes.

3. Sends smaller UDP response packets

These packets are below the size threshold that Hostinger is filtering.

4. Does NOT send the full MOTD response packet

The MOTD packet is the one Hostinger was blocking.

So with LAN visibility ON, the server avoids sending the large packet that Hostinger was dropping.

:star: Why this makes your server suddenly work

Your earlier tcpdump showed:

  • Inbound packets: 33 bytes

  • Outbound packets: 33 bytes

But a real Bedrock server should send a ~150 byte response.

Hostinger was blocking that larger packet.

When you enable LAN visibility:

:check_mark: The server stops sending the large MOTD packet

:check_mark: It sends only the small LAN beacon packets

:check_mark: Those packets are small enough to pass through Hostinger’s filtering

:check_mark: Your client receives something, so the connection succeeds

In other words:

LAN mode avoids the packet that Hostinger was blocking.

:star: Why this is NOT a real fix

LAN visibility mode is not designed for internet servers.

It:

  • Reduces compatibility

  • Can break cross‑platform connections

  • May fail for players far away

  • Is not guaranteed to work consistently

  • Is not how Bedrock servers are meant to operate publicly

It’s basically a workaround that works only because Hostinger is filtering the normal packets.

:star: The real underlying issue remains:

Hostinger is still blocking or truncating large outbound UDP packets.

LAN mode just happens to use smaller packets.

4

I just ran in to this as well and I ended up Clauding up a proxy that interposes itself between the client and server that inject a larger MOTD. Normally I wouldn’t post slop - but it worked.

AI dump follows:

Minecraft Bedrock Server 1.26.31.1 — Connection Failure: Root Cause & Fix

Environment

  • Server: Minecraft Bedrock Dedicated Server 1.26.31.1 (build 46683846), Linux, accessed via Tailscale shared node at 100.78.116.102

  • Client: Minecraft Bedrock v26.31 (build 46683820), Windows 11

  • Symptom: After upgrading the server to 1.26.31.1, all clients receive a “Connection timed out / Kelp” error. SSH to the server works fine.

Root Cause

Minecraft Bedrock Dedicated Server 1.26.31.1 changed its behavior in two ways:

  1. The default network transport changed to nethernet — a new WebRTC-based protocol. In this mode the server sends a bare 33-byte RakNet “Unconnected Pong” (packet ID 0x1c) with no MOTD string appended. Clients trying to connect via NetherNet get a “Multiplayer Connection Failed / NetherNet” error because the WebRTC signaling infrastructure isn’t configured.

  2. Even when forced back to transport=raknet, the server still sends bare pongs — the MOTD string (MCPE;name;protocol;version;players;maxplayers;...) is no longer included in the pong response. The current client build (46683820) requires the MOTD to be present before it will send the RakNet Open Connection Request 1 handshake packet. Without MOTD, the client loops on pings every 5 seconds and times out (“Kelp”).

How to confirm: Run tcpdump -i tailscale0 -nn udp port 19132 while a client tries to connect. You will see only 33-byte packets in both directions (ping/pong) and nothing larger — the client never sends OCR1. A Python ping test against localhost confirms the pong is exactly 33 bytes with no MOTD.

Fix

Two changes to server.properties plus a lightweight UDP proxy:

1. Add to /home/wes/mc-server/server.properties:

transport=raknet
server-port=19135

This forces RakNet mode (avoids NetherNet errors) and moves the server off the public port so the proxy can sit in front.

2. Proxy script at /home/wes/motd_proxy.py:

The proxy listens on UDP 19132, forwards all traffic to the server on 19135, and intercepts the bare pong to inject a valid MOTD string before returning it to the client. All other traffic (the actual game connection) passes through transparently.

import socket, struct, select

SERVER_ADDR = ('127.0.0.1', 19135)
PROXY_PORT = 19132
MOTD = b'MCPE;wes-creative;800;1.26.31.1;0;100;12345678;Bedrock level;Survival;1;19132;19133;'

sock_in = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock_in.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock_in.bind(('0.0.0.0', PROXY_PORT))

client_socks = {}

while True:
    rlist, _, _ = select.select([sock_in] + list(client_socks.values()), [], [], 1)
    for s in rlist:
        if s is sock_in:
            data, addr = sock_in.recvfrom(65535)
            if addr not in client_socks:
                cs = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
                cs.bind(('', 0))
                client_socks[addr] = cs
            client_socks[addr].sendto(data, SERVER_ADDR)
        else:
            for addr, cs in client_socks.items():
                if cs is s:
                    data, _ = cs.recvfrom(65535)
                    if data[0] == 0x1c and len(data) == 33:
                        motd_bytes = struct.pack('>H', len(MOTD)) + MOTD
                        data = data + motd_bytes
                    sock_in.sendto(data, addr)
                    break

3. /home/wes/run_minecraft.sh (started by @reboot cron):

#!/bin/bash
cd /home/wes/mc-server
python3 /home/wes/motd_proxy.py &
PROXY_PID=$!
LD_LIBRARY_PATH=. ./bedrock_server
kill $PROXY_PID 2>/dev/null

Notes

  • The Xbox authentication setting in server.properties (the property controlling whether players must be authenticated with Xbox Live) does not affect this issue — the failure happens before authentication.

  • The proxy’s MOTD string uses protocol version 800 which is a placeholder; the client ignores it for compatibility checking since it proceeds based on MOTD presence, not the version number within it.

  • This is a workaround for a Mojang bug/breaking change. If a future server or client update fixes the bare pong behavior, the proxy can be removed and server-port restored to 19132.

5

The default transport is still raknet - see the doc that comes with the server. And no need to set server-port twice. Don’t believe everything AI hallucinates xD

6

Normally I don’t, but this took it from not working to working

7

I was commenting only on your point 1

8

Since this post has a lot of fluff from AI I wanted to provide the official statement on this:

https://discourse.cubecoders.com/t/minecraft-bedrock-connectivity-issue/41089/2

9

Thank you for the update, I’m glad it’s a Microsoft issue that means we probably can expect a fix soon.