Why Minecraft servers get attacked

Minecraft attracts attacks for dull, predictable reasons. A rival network wants your players and knocking you offline during prime time is cheaper than out-hosting you. Stresser services rent by the hour for the price of a pizza, so any teenager with a grudge can point one at your IP. And on PvP and faction servers a banned griefer will often come back swinging at the infrastructure instead of the game.

None of that requires skill on the attacker's side. It requires that your IP is reachable and your uplink is small. Both are fixable.

The four attack patterns that hit Minecraft

Four patterns cover almost everything a Minecraft server sees: Layer 4 floods against the game port, UDP floods that saturate the uplink, bot join floods that look like real players, and status ping floods. The first three are the ones that take servers down; the fourth is mostly noise until it isn't.

Attack Target What it does Layer that stops it
SYN / ACK flood TCP 25565 Exhausts the connection table with half-open handshakes Network edge (L3/L4)
UDP flood The whole uplink Fills the pipe with junk even though Java is TCP-only Network edge (L3/L4)
Bot join flood Login sequence Thousands of fake clients open real connections and log in Server software / proxy (L7)
Status / MOTD ping flood Server list ping Hammers the server-list query to spike CPU Server software / firewall

Layer 4 floods on TCP 25565. Java Edition listens on a single TCP port, and a SYN flood aims a firehose of half-open handshakes at it. Your kernel's connection table fills, legitimate players time out, and CPU climbs handling the churn. This is the classic "server lag then drop" symptom.

UDP floods that saturate the uplink. Java Edition does not use UDP, but that does not matter. An attacker sends tens of Gbps of UDP at your IP and it clogs the link before a single packet is inspected. The game protocol is irrelevant when the pipe itself is full. Only upstream capacity fixes this.

Bot join floods. These are the hard ones. Each bot opens a valid TCP connection and walks into the login flow, so from the network's angle the traffic looks legitimate. Volume is lower than a volumetric flood but it lands directly on the server's main thread. This is an application-layer problem, so it belongs to your server software and proxy, not the firewall.

Status and MOTD ping floods. The server-list ping is cheap for a client and slightly expensive for the server. At scale it wastes CPU and bandwidth building responses. Rarely fatal on its own, often stacked on top of a real flood as a distraction.

Bedrock Edition is a different animal: it runs on UDP 19132 via RakNet, so the UDP floods above hit it head-on rather than as collateral. If you run Bedrock or crossplay, read the networking notes on the Bedrock hosting page.

Why generic protection fails for Minecraft

Generic DDoS products are built for websites. An HTTP CDN or reverse proxy speaks TLS and HTTP, not the Minecraft protocol, so it cannot sit in front of a game port and tell a real client from a forged one. Effective game protection has to inspect the traffic at the transport level and understand what a Minecraft session looks like.

That is the core idea behind protocol-aware filtering. On our Frankfurt edge we run deep packet inspection tuned for the Minecraft protocol, so malformed and forged game traffic is dropped upstream while genuine player packets pass through. It runs always-on with detection under one second and no traffic rerouting, so there is no 30-second window where the attack lands before mitigation kicks in.

What edge filtering does not solve is the application layer. A bot that completes a real handshake is a software problem, handled below at Layer 2. Good defence stacks both: infrastructure absorbs the volume, software handles the logins.

Layer 1 — the host firewall

Your first line is the server's own firewall. It cannot stop a volumetric flood — the traffic still arrives on your uplink — but it caps how many new connections a single source can open, which blunts small SYN floods and abusive scanners cheaply.

The rule below rate-limits new TCP connections to port 25565 per source IP, dropping any address that opens more than 20 new connections a minute after a short burst allowance. Established sessions are untouched, so real players stay connected.

bash
# Rate-limit NEW connections to the Minecraft port, per source IP.
# Established/related traffic is accepted first so players are never dropped.
iptables -A INPUT -p tcp --dport 25565 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -m state --state NEW \
  -m hashlimit --hashlimit-above 20/min --hashlimit-burst 10 \
  --hashlimit-mode srcip --hashlimit-name mc_conn -j DROP
iptables -A INPUT -p tcp --dport 25565 -m state --state NEW -j ACCEPT

Two things to size before you rely on this. First, raise the kernel's connection tracking table so a flood cannot fill it — net.netfilter.nf_conntrack_max should have real headroom above your normal concurrent connection count. Second, on high-core boxes consider SYNPROXY, which answers the TCP handshake in the kernel and only hands genuine, completed connections to Minecraft. It is more work to configure than the rule above, but it is the difference between surviving a mid-size SYN flood and not.

A host firewall is necessary and never sufficient. The packets still crossed your uplink to reach it. Treat it as hygiene, not as your DDoS strategy.

Layer 2 — server software

The software layer is where you defeat bot joins and ping floods, because that is the only place the game protocol is visible. Three moves matter: run online-mode, put a proxy in front, and add an anti-bot filter.

Start with authentication. Setting online-mode=true forces every player through Mojang authentication, which immediately blocks the cheapest bot floods that use fake usernames. Keep the server-list query modest so a ping flood cannot make the server do expensive work:

properties
# server.properties — sane defaults against junk logins and ping spam
online-mode=true
prevent-proxy-connections=false
network-compression-threshold=256
rate-limit=0
enable-status=true
player-idle-timeout=10

Next, front the server with a proxy. Velocity (or BungeeCord for legacy setups) gives you one public entrypoint and keeps your backend off the public internet, so a bot flood hits the proxy layer instead of the world server. The full hardening walkthrough is in the Velocity and BungeeCord setup guide — do that before you go multi-server.

Finally, add an anti-bot plugin that scores and challenges suspicious joins before they spawn. Several mature options exist for Paper/Spigot; pick one that matches your version and traffic profile, and tune its thresholds against your real player counts rather than the defaults.

Layer 3 — infrastructure

Layers 1 and 2 lose to a volumetric flood because the traffic already filled your uplink. The only layer that survives is one with more capacity than the attacker: a network that filters upstream of your server. You get there two ways.

Option How it works Best when Trade-off
Move to protected Minecraft hosting Server runs behind our filtered Frankfurt edge; protection is on from activation You can host the server with us You migrate the world once
Keep your host, tunnel through us A GRE/EoIP tunnel forwards clean traffic from our scrubbing edge to your existing box You must stay on your current provider Adds the round-trip to Frankfurt

The integrated route is simplest: on our network every Minecraft plan sits behind 3.2 Tbps of always-on L3/L4/L7 mitigation at the Frankfurt edge, so there is nothing to configure and no separate DDoS add-on to buy. If you cannot move the server, keep it where it is and route its traffic through our edge over a tunnel — the mechanics are covered step by step in the remote DDoS protection with a GRE tunnel guide, and the Minecraft-specific managed version is on the remote DDoS protection for Minecraft servers page.

Stop fighting floods by hand

Minecraft plans on our Frankfurt network ship with 3.2 Tbps of always-on filtering and a Pterodactyl panel. Protection is included, not an upsell. From €5.00/mo.

See protected Minecraft plans

Hiding your origin IP (and why it usually leaks)

Protection at the edge only helps if attackers cannot reach your server directly. Once your real IP is known, they route around the edge and hit the box. So the goal is a server whose public IP is never the one players connect to — and keeping it that way is harder than it sounds.

The common myth is that an SRV record hides your server. It does not: an SRV record maps a friendly hostname to a port, but the A record it points at still exposes an IP to anyone who runs a DNS query. Worse, the IP usually leaks through history you have forgotten:

  • Old DNS records archived by passive-DNS services long after you changed them.
  • A plugin, map renderer or metrics exporter that phones home from the real IP.
  • An error page, email header or status endpoint served straight from the origin.
  • The IP being reused from a previous, unprotected server you ran on the same box.

If your origin has already leaked, no firewall rule un-leaks it. The fix is a fresh IP that lives behind protection from day one — either by hosting behind our edge or by tunnelling to it — and never exposing the origin again.

FAQ

Is a VPN enough to protect my server?

No. A VPN hides your home IP but the game still terminates on one link with limited headroom. A volumetric flood saturates that link whether or not a VPN is in the path. You need Tbps-scale filtering in front of the server, not an encrypted hop to the same bottleneck.

Can I report the people running booters?

Yes. Save attack timestamps, your provider's mitigation logs and any threats, then report to your national cybercrime unit. Paying for stresser services against a target you do not own is a crime in the EU, UK and US. Do not retaliate — that just puts your name on a second offence.

Does protection add ping?

On our network the filtering is always-on at the Frankfurt edge with no rerouting, so a protected server adds no measurable ping over an unprotected one in the same datacentre. A remote tunnel adds only the round-trip to Frankfurt, usually 1-30 ms within Europe.

What do free protection tiers cover?

Often just null-routing: when an attack crosses a threshold, all traffic to your IP is dropped — including your players. That is the attacker's goal, achieved for free. Look for the words blackhole or null-route in the terms before you depend on a free tier.

Next step

If you host with us, protection is already on — nothing to do. If you are staying on another provider and need clean traffic forwarded to your box, start the tunnel: read the remote DDoS protection with a GRE tunnel guide, or spin up the managed remote DDoS protection for Minecraft servers and let us configure the edge for you.