Connection floods on the Java port
Half-open handshakes that never complete, or connections opened and abandoned in volume. They consume connection state and CPU long before anyone reaches the login screen.
Attacks on a Minecraft server arrive at two levels. Packet floods aimed at your port are dropped by the filter in front of the game, before the server process sees them. Bot joins are valid Minecraft connections, and those are stopped inside the game with online-mode and a whitelist.
| Port | What it carries | Exposure | In the preset |
|---|---|---|---|
| TCP 25565 | Java game traffic and the status ping the client list uses. | Open to players | Yes |
| UDP 19132 | Bedrock game traffic over IPv4. | Open to players | Yes |
| UDP 19133 | Bedrock game traffic over IPv6. | Open only if you use it | Add it yourself |
| UDP 25565 | Java query, only when enable-query=true. | Open only if you use it | Add it yourself |
| TCP 25575 | Java RCON, only when enable-rcon=true. | Restrict to your own addresses | Add it yourself |
A rule is TCP or UDP, never both.
Half-open handshakes that never complete, or connections opened and abandoned in volume. They consume connection state and CPU long before anyone reaches the login screen.
Every client that lists your server sends a status request. As an attack it is a flood of them, and because it arrives on the gameplay port, the limit on that port covers it.
enable-query opens a UDP listener whose reply is larger than the request that triggered it, which is the shape used to reflect traffic at someone else. Leave it off unless a tool needs it.
Bedrock gameplay and discovery run over UDP 19132, with no TCP handshake to lean on, so the UDP rule carries the weight.
The last gate is what catches a flood that uses the right port and a plausible packet size.
Java traffic is checked against the Minecraft handshake and login, and Bedrock traffic against RakNet. Traffic that does not speak the protocol is dropped.
On Java, an established connection cannot quietly carry more than one player needs. A flood riding a single open connection hits the per-connection ceiling.
TCP connection openers that are never completed, and SYNs whose stack fingerprint looks forged, are separated from real clients on the Java port.
The UDP first-packet challenge drops single-shot spoofed floods under load, and the zero-day engine learns the shape of a new attack while it runs.
Java opens TCP 25565, completes the handshake, then sends a login the server answers. Each step is a chance to tell a client from a socket that will never finish.
The server list ping arrives on the gameplay port, so the ceiling on that rule covers a flood of status requests as well as gameplay.
Bedrock is RakNet over UDP 19132 throughout, with no TCP handshake to lean on, so the UDP rule and the first-packet challenge carry the weight.
A real Java client completes the handshake and stays within one player's packet rate. A bot join does too, which is why that one is closed inside the game with online-mode and a whitelist, not at the network.
TCP 25565 Completes the TCP handshake, to the server, passes Prism
TCP 25565 Sends the Minecraft handshake, then a login, to the server, passes Prism
TCP 25565 The server answers the login, from the server, passes Prism
TCP 25565 Plays within one player's packet rate, both ways, passes Prism
TCP 25565 Opens handshakes it never completes
Ends at: SYN flood and fingerprint checks
TCP 25565 Connects once, then floods that connection
Ends at: A ceiling for one connection
TCP 25565 Traffic that is not the Minecraft handshake and login
Ends at: Minecraft protocol validation
Java writes a TCP 25565 rule and Bedrock a UDP 19132 rule, both with packet-rate ceilings set. Running Geyser or a second server? Each extra port gets its own rule.
Applying a preset adds its rules, it never replaces yours, and applying it twice adds a second copy. A server holds 15 inbound rules, so check the table afterwards.
| Protocol | Port | Policy | Status |
|---|---|---|---|
| TCP | 25565 | 10K pps | Enabled |
| UDP | 19132 | 20K pps | Enabled |
Quick setup: apply a preset for a common workload
Player count, plugins, a proxy in front and whether you run query all move the numbers. Set the ceilings above a normal busy evening, with headroom.
Read the guideA bot join completes the handshake, speaks the protocol and logs in, so every packet is well formed. online-mode=true makes each bot need a real paid account, and a whitelist closes a private server completely.
Read the guideThe world runs on one main thread with a 50 millisecond budget per tick. A faster core finishes a tick sooner; more cores carry chunk loading, saving, garbage collection and plugin work around it.
A small world. A small world and a few plugins, with memory left over for the operating system and for what the Java runtime uses outside the heap. Giving the heap every gigabyte on the machine is the common mistake.
Modded, with a real player base. More players, more mods and a bigger view distance all need more heap. The extra cores carry chunk loading, world saving and garbage collection so they stay off the main thread.
What every Minecraft server on Clouduxe starts with.
No. It is part of every VPS, VDS and bare metal server, in every region, on every plan.
Yes. Java on TCP 25565 and Bedrock over RakNet on UDP 19132 both have protocol validators and one-click presets.
Bot joins are real Minecraft connections, so no network filter can tell them from players. Use online-mode=true and, for a private server, a whitelist. Prism handles the packet floods around them.
Only if a monitoring tool needs it. Query is UDP and answers with more than it receives. If you do enable it, give it its own port rule with a rate ceiling.
The one closest to your players: Mumbai for India, Singapore for Southeast Asia, Limburg for Europe. Protection is identical in all three.
The same 17 Tbps upstream and the same filter on every plan, in every region, enabled from the first boot.