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

Pick a suitable package from the DDoS protection page. We suggest choosing one geographically close to your server location (or your primary user base). We offer numerous locations in the United States and Europe.

During the purchase process you will be asked to:

1. Name your service (important if you plan to have many)
2. Select the filtering location (choose a location close to your backend server)
3. Select an appropriate DDoS protection threshold (choose a value big enough to handle your expected attacks)
4. Select the amount of Clean Bandwidth required to run your service (not attack traffic)

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.

Encapsulated networks can be created from your services "Tunnels" page, the link for which can be found in its Action menu. To create a Tunnel you need to specify the backend servers IP address, as well as the settings for your chosen tunnel type, such as the GRE key shown in the Dashboard. If unsure as to the appropriate encapsulation type we recommend using GRE. Alternatively to the form in your dashboard you may also use the form below to create a tunnel, just input details for your backend server and select your service.

We provide scripts / software to install the encapsulated tunnel onto your backend server in the Dashboard. On your services Tunnels page you should see the list of tunnels which have been created. In the Action menu for the tunnel there is a page titled "Setup Tunnel", here you can download the provided Linux setup script, or the Windows tunneling software with your configuration built-in.

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 your service's Action menu and select Ports, then Add Port. 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, select the RakNet preset 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.

On Anycast services, use the UDPAuth profile for the gameplay range and protect the signaling TCP port with TCP VERIFY (TCP SYN Proxy). In the service's Filtering page, create a Layer 4 rule with BPF dst host 203.0.113.10 and tcp dst port 19132 (replace the IP and port with your public signaling endpoint), Match On: All Traffic, and target TCP VERIFY.

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. Test joins, reconnects, and continued gameplay after the HTTP connection closes. This combination 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 RakNet under Layer 7 (Game) for server-port, normally 19132 for IPv4. This applies RakNet-specific filtering while forwarding the port over UDP. 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:

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!