How to set up a DDoS protected Minecraft Bedrock server on Linux or Windows

This tutorial explains how to configure DDoS protection for the official Minecraft Bedrock Dedicated Server on Linux or Windows. It assumes you have a running server and access to its configuration files.

Step 1: Backend Setup

Set up Bedrock on your server, referred to below as the "backend server". Use a supported operating system for your Bedrock release; we generally recommend Linux where possible.

Please ensure that the service is running and connectible on the backend server.

Check the transport setting in server.properties before configuring protection. NetherNet uses HTTP over TCP to arrange a connection, followed by WebRTC gameplay over UDP. RakNet uses UDP for the game connection. NetherNet became the default in Bedrock 26.50; use the instructions for the transport your server actually runs. Third-party server implementations can have different settings.

The properties below were checked against server.properties and bedrock_server_how_to.html in the official 1.26.52.3 Linux and Windows packages, available from the Bedrock Dedicated Server download page. Consult the files shipped with your version when upgrading.

Step 2: Purchase DDoS Protection Service

Choose a billing cycle, a service tier/network and the clean-bandwidth allowance on the DDoS protection page, then click Continue to Checkout. On Complete Order, review the filtering region when offered, enter a Service Name, and review the Order Summary before submitting your order. Choose a region close to your backend and users; clean bandwidth measures delivered traffic, not attack traffic. If you already have a suitable active service, continue with that service.

Step 3: Encapsulation Setup (Optional)

This step is only required if you are intending to use a GRE or IP-in-IP tunnel. If you are intending to use a Reverse Proxy (RP) style connection (the easiest) then you can skip this step.

A Reverse Proxy only proxies connections to your backend and can be useful for servers that do not require to set bans on player IP addresses or do not have command line skills to set up a network interface (or when using a panel that does not give access to console).

An encapsulated backend requires support on the Backend Server, currently Windows and Linux Operating Systems are fully supported, with partial support for FreeBSD. Most Enterprise or even SOHO Routers also support GRE or IP-in-IP tunneling, if supported you may be able to configure the router to terminate the encapsulated network.

Open Services, find your service, and choose Action > Tunnels. Click Add Tunnel, select GRE in Tunnel type, and enter the backend server's public IP in Backend address. Retain the displayed GRE key unless your backend requires a tunnel without one, then click Save. The integrated form below is an alternative way to configure the same tunnel.

The completed example uses 203.0.113.20 as a documentation-only backend address, GRE key 1785302134, and MTU 1472. Replace the backend address with your server’s public IP and use the same key and MTU when configuring that server.

After saving a port that uses this tunnel in Step 4, return to Tunnels and choose the tunnel's Action > Setup Tunnel. Select Linux / BSD and Download Tunnel Script, or Microsoft Windows and Download Application, as appropriate for your backend. The tunnel must be referenced by an Encapsulated port before it is usable. Install the downloaded script or application on your backend using the linked operating-system instructions.

For tunnel installation instructions, see Linux DDoS protection or Windows GRE/IP-in-IP tunnels. For NetherNet, complete the UDP configuration below as well: protecting only the HTTP connection leaves gameplay traffic unprotected.

Step 4: Add Ports

Open Services, find your service, and choose Action > Ports. Under Single Port, click Add port manually when Add your first port is shown; otherwise click Add Port. Enter Port start, Protocol, Backend method, Backend address and Backend port, then click Save. Choose the ports for your transport below. For an encapsulated backend, select the tunnel created in Step 3. For a Reverse Proxy backend, enter the backend server's IP address. Match the backend port to the server's configuration if it differs from the public port.

The Minecraft preset under Layer 7 (Game) is for Minecraft Java over TCP. Do not select it for either Bedrock transport. For a Bedrock server using RakNet, use the UDP setup described below. See the Minecraft Java guide, Port types, and Layer 7 protection modes.

NetherNet ports and protection

Configure both the TCP signaling port and a fixed UDP gameplay range. For example, edit the server's server.properties and restart the server:

transport=nethernet
server-port=19132
server-udp-ports=203.0.113.10:19140-19239:19140-19239

Replace 203.0.113.10 with your Filtered IP. This example advertises UDP ports 19140-19239 on that IP and uses the same ports locally. Create the following forwarding entries to the same Bedrock backend:

The mapping format is PUBLIC_IP:PUBLIC_PORT_RANGE:LOCAL_PORT_RANGE; ranges must have equal lengths. Configure the full range in the Dashboard and backend firewall, and size it for your concurrent connections. Leaving server-udp-ports empty lets the server allocate ephemeral ports, which makes explicit forwarding difficult. server-portv6 is ignored in NetherNet mode. If offering IPv6, configure its protected path too; IPv6 literals in UDP mappings need square brackets.

The advertised address tells players where to send gameplay packets. It does not create forwarding rules, bind UDP sockets to that IP, or configure the server's return route. Advertising the backend's public IP instead of the Filtered IP would let gameplay bypass protection. See Mojang's NetherNet guide for the signaling and WebRTC connection sequence.

Create the signaling entry as TCP on port 19132. For the gameplay range, choose Port Range > Add Port Range, set Port start to 19140, Port end to 19239, and Protocol to UDP. Select the same backend server or tunnel, then click Save. Use your own backend server address in the form.

This example uses 203.0.113.20 for the backend, separate from the example Filtered IP above. Replace it with your own backend address or select your tunnel.

On Anycast services, you can additionally protect the signaling TCP port with TCP Verify. Open the service's Filtering page, click Add Rules under Layer 3-5: Custom Rules, enable BPF Match, and enter dst host 203.0.113.10 and tcp dst port 19132 in Expression (replace the address and port with your public signaling endpoint). Enter a descriptive Name, choose Target Action: TCP Verify and Match On: All Traffic (Early), then click Save.

The UDPAUTH preset is available for individual ports, but the Dashboard's Port Range selector does not offer it. The UDP range above therefore does not enable UDPAuth. If you require UDPAuth for a gameplay range, ask support to review your intended configuration before deployment. Do not expand a large range into individual entries without checking your service's port-entry limit.

UDPAuth requires a completed TCP handshake before accepting UDP from that client IP. Keep signaling and gameplay on the same protected service and verify that both arrive from the same client public IP. A separate signaling proxy or an IPv4/IPv6 split can break that association. When using a support-reviewed UDPAuth configuration, test joins, reconnects, and continued gameplay after the HTTP connection closes. UDPAuth helps reject spoofed traffic; it does not stop every flood from real clients that can complete the handshake. On services without these Anycast features, use ordinary TCP and UDP entries.

RakNet ports

For transport=raknet, select UDP for server-port, normally 19132 for IPv4. The RakNet-specific preset is currently restricted to support staff and is not shown in the customer protocol selector. Contact support to discuss its availability for your service. server-portv6, normally 19133, is the separate IPv6 UDP listener; it is needed only if you provide that connection path. These are not two mandatory ports for an IPv4-only server.

The form below shows the default RakNet ports. Include only the ports you actually serve, and adjust their backend mappings as needed:

The completed example uses 203.0.113.20 as a documentation-only backend address. Replace it with your backend address, or select the GRE tunnel you created when using encapsulation.

UDPAuth depends on a preceding TCP connection, so it is unsuitable for a standalone RakNet server. TCP VERIFY also does not validate RakNet's UDP handshake.

Step 5: Encapsulation - Server Binding and Reply Routing

These settings apply to the Bedrock server process on the backend. For a tunneled setup, game replies must use the backend's local tunnel IP and the configured tunnel return route. Use the tunnel IP assigned to that host, not an unassigned public Filtered IP. A Reverse Proxy backend normally does not need a forced tunnel binding; NetherNet still needs the public UDP mapping from Step 4.

Native binding on Linux and Windows

For a NetherNet server whose assigned local tunnel IP is 10.17.24.14, add this to server.properties and restart:

server-ip=10.17.24.14

Leaving this property empty listens on all interfaces. The documented setting is for the signaling listener; do not assume it forces every WebRTC UDP socket or outgoing connection onto the tunnel. server-udp-ports controls UDP ports and advertised mappings, not the local source IP or operating-system routing.

A wildcard listener (0.0.0.0 or ::) alone does not prove that replies use the wrong address. Whether a workaround is needed depends on the transport, the server build, and the host routing; verify a real connection first.

If game replies use the wrong source address

Linux: Check the tunnel's return-routing configuration first. If the server cannot select the required UDP source address, use a network namespace or container with deliberately configured tunnel egress, or an appropriate combination of policy routing and source NAT. These require configuration for your network; a source-based route alone will not fix packets that already have the wrong source address. Apply this to the Bedrock service rather than changing the host's default route.

The LD_PRELOAD binding guide describes another possible workaround, but its linked IPv4 shim is not a universal Bedrock fix: it leaves wildcard bind() calls unchanged and does not handle IPv6. Do not assume it forces either RakNet or NetherNet UDP traffic onto the tunnel. Check the actual shim and server build before relying on it.

Windows: ForceBindIP is a possible workaround when the server's socket calls can be intercepted. After installing it, run the 64-bit server from its own directory, replacing the example address with your local tunnel IP:

ForceBindIP64 10.17.24.14 "C:\Bedrock\bedrock_server.exe"

Adjust the executable path, and use the full path to ForceBindIP64.exe if it is not on PATH. This is a conditional workaround, not a requirement for every Windows server. ForceBindIP's author documents limits to which socket operations it can intercept. Validate it with your exact RakNet or NetherNet build; a successful launch does not establish that WebRTC traffic follows the tunnel. If it cannot control the required sockets, use a dedicated VM with tunnel routing configured for that server, or a verified Reverse Proxy setup.

Verify the server's sockets and actual traffic

On Linux, inspect the Bedrock process with ss -lntup and ss -unap. On Windows, use netstat -ano -p tcp and netstat -ano -p udp, matching the PID to bedrock_server.exe. Check NetherNet's UDP sockets during a join, since they may not exist while the server is idle.

Socket listings show local addresses and ports, but cannot prove the packet's outgoing route. During an external player's connection, capture traffic with tcpdump on Linux or Wireshark on Windows. For a tunnel, confirm that RakNet replies, or NetherNet's WebRTC UDP traffic, use the intended tunnel source and return path. At the player end, confirm gameplay uses the Filtered IP. Repeat for each supported address family and after server upgrades or shim changes.

Step 6: Finish & Test

Once all steps are completed and the progress bar for deployment of the configuration reaches 100% you should be able to connect to your service on your Filtered IP.

This Filtered IP is the address that you should use in any DNS names, or supply to any connecting users. All traffic which arrives at configured ports on a Filtered IP will be filtered for attack, and then forwarded to your configured backend server.

Note: Keep host and provider firewalls enabled. Allow the required service traffic from the current Backend Communication IP Addresses shown in the Dashboard. For tunnels, also allow the selected tunnel protocol between its endpoints.

For NetherNet, verify an actual join and sustained gameplay, not just a successful TCP connection or server-list response. Confirm that the advertised gameplay endpoint is protected and that reconnecting works with UDPAuth enabled.

Have Fun!