Minecraft DDoS Protection in 2026: Four Layers, Concrete Thresholds

Minecraft servers get attacked routinely, and the attacks that actually take players offline are rarely the ones people picture. A 900 Gbps reflection flood makes headlines, but most outages on community servers come from modest 1–5 Gbps UDP blasts and connection floods that exhaust the Java process long before the uplink saturates. Defending a server means understanding which layer each attack hits, what number it needs to reach to hurt you, and which control actually absorbs it. This breaks down four layers — network edge, host kernel, Java process, and application logic — with the thresholds that matter at 50, 200, and 1000 player slots.

Know Your Attack Envelope Before Buying Mitigation

Three attack families hit Minecraft servers, and each one asks a different capacity question. Volumetric UDP floods are measured in Gbps and PPS: a cheap source-port-spoofed flood of 200-byte packets at 2 Mpps is only about 3 Gbps, but many providers filter on bandwidth only and pass the PPS. Protocol floods are measured in concurrent connections and handshakes per second — a 30k-connection SYN flood costs almost no upstream bandwidth but will fill a default net.core.somaxconn of 4096 and a netfilter conntrack table of 65k within seconds. Application-layer abuse is measured in requests per second to the game port, typically Minecraft status pings and login attempts, and it burns CPU rather than network.

Size your defences against a realistic worst case rather than an average. If your server peaks at 120 players, an attacker only needs roughly 1.5× your normal session count in forged handshakes to look like a legitimate flash crowd to naive rate limiters. Work out your normal PPS baseline first: a Paper server at 100 players and 20 TPS typically sits near 8k–15k pps in and out. Anything above 50k pps inbound on a quiet hour is almost certainly hostile.

Attack type	Typical size that hurts a 100-slot server	Primary metric	Layer that absorbs it
UDP volumetric flood	3–40 Gbps sustained, 2–15 Mpps	Gbps / Mpps	Provider edge scrubbing
SYN / connection flood	10k–60k concurrent half-open connections	Connections, SYN/s	Host kernel (SYN cookies, conntrack)
Status ping flood	2k–20k requests/s	Requests/s, CPU per request	Application rate limits
Login / auth spray	200–2k login attempts/s	Auth operations/s	Plugin + fail2ban + proxy
Slowloris-style idle sockets	5k–20k held sockets	Open FDs	Kernel timeouts + proxy

Layer 1: Uplink Absorption at the Provider Edge

Nothing on your machine matters if the packets never arrive, so the first layer is always upstream. A 1 Gbps unmetered port is not protection — it is a 1 Gbps ceiling that any 5 Gbps flood will fill in under a second. What you need is always-on scrubbing or BGP-triggered diversion to a scrubbing centre sized well above your port, with a fast detection window. Ask providers two questions before signing: what is the scrubbing capacity per IP, and how many seconds from attack detection to traffic diversion? On-demand mitigation that takes 60–90 seconds to activate is enough to drop a raid but not enough for a sustained multi-hour campaign.

For a 200-slot Paper server, 10 Gbps of scrubbing headroom is the practical floor; for a network of Minecraft servers sharing one /29, look for 40 Gbps or more across the block. If your host advertises “DDoS protected” without a scrubbing capacity figure, treat it as marketing. The bare-metal options listed on dedicated server plans with always-on DDoS mitigation are the reference point for what a game-focused port should include.

Layer 2: Kernel-Level Connection Handling

Once packets reach the host, the Linux network stack becomes the defence. SYN cookies stop half-open connection tables from being exhausted, conntrack limits stop a single source from filling the state table, and small timeouts kill slowloris sockets before they accumulate. On a 1000-slot network node, raise net.core.somaxconn to 8192, set net.ipv4.tcp_syncookies=1, raise net.netfilter.nf_conntrack_max to at least 262144 with a 600-second timeout, and drop invalid packets in the raw table before they hit conntrack at all.

Minecraft’s Java process listens on UDP 25565 for game traffic and TCP 25565 for status and login, so UDP floods bypass conntrack entirely and are metered only at the interface. That is why interface-level PPS accounting matters: enable per-IP traffic accounting or nftables counters so you can see, within seconds, whether a spike is 90% UDP to 25565 or spread across unrelated ports (the latter means an attack on the whole host, not your game).

Layer 3: Proxy and Java Process Protection

The third layer sits between the internet and your world. A Velocity or BungeeCord proxy absorbs handshakes, enforces per-IP connection caps (3–5 per address is generous), rate-limits status pings to 10–20 per second per IP, and hides backend server ports entirely. Backend Paper instances should never be reachable from the internet — bind them to the private interface and let the proxy do the talking. An attacker who cannot enumerate your backends cannot flood them directly.

JVM settings matter here too. A 6 GB heap on a 100-player Paper server and a G1 collection target of 200 ms is suitable under normal load, but under a ping flood the allocation rate triples while useful throughput stays flat. Set -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1NewSizePercent=30 and make sure the server has 2 GB of headroom above the heap for the OS, off-heap buffers, and threads. If the JVM starts swapping because a flood pushed resident memory past RAM, you are already done.

Layer 4: Application-Level Throttling

The innermost layer is the game and its plugins. Limit login attempts per IP to a handful per minute, cap simultaneous joins (20 joins per 10 seconds is plenty for a 200-slot server) so a burst of real players cannot be weaponised against you, and rate-limit anything that triggers world lookups on unauthenticated paths. Paper’s max-joins-per-tick and connection throttle settings are the cheapest controls you have.

Log everything at this layer with timestamp, source IP, and outcome. Rotate aggressively — a sustained flood can generate 50–200 MB of connection lines per hour — and keep logs on a separate partition from world files so a disk fill never costs you a save.

Budgeting Protection by Server Size

Protection should scale with what an outage costs you. A 20-slot friends-only server needs kernel hardening and a provider with basic scrubbing; a 200-slot monetised community needs proxy filtering, app throttling, and 10+ Gbps always-on capacity; a 1000-slot network needs dedicated scrubbing on its own IP block and a second path for failover.

Server size	Scrubbing capacity	Max sustained PPS handled	Proxy required	RAM floor
20 slots	2–5 Gbps	~100k	No	4 GB
100 slots	10 Gbps	~400k	Recommended	8 GB
200 slots	10–20 Gbps	~1 Mpps	Yes	12 GB
1000 slots (network)	40+ Gbps	2–5 Mpps	Yes, multi-node	64 GB total

The most common failure is not insufficient bandwidth but a missing layer: a server with 40 Gbps of scrubbing and no proxy still dies to 20k connections, while a server with a proxy and only 5 Gbps of scrubbing dies to a moderate volumetric flood. Build all four layers, test each one separately, and keep the attack logs — they are how you prove to a host that the filtering rule needs widening, and how you decide next quarter whether the dedicated hosting environment you are paying for is still the right size for the players you actually have.