What it is
Opening a TCP connection takes three steps: the client sends SYN, the server replies SYN-ACK and reserves state, the client sends ACK. A SYN flood sends the first packet and never the third. The server holds half-open state for every one, and since the source is usually spoofed, the SYN-ACK goes nowhere. The connection table fills and real connections get refused.
Why it matters for Minecraft
Minecraft is a TCP protocol, so it inherits this attack for free. A SYN flood does not need to be large in bandwidth terms to be effective — it needs to be large in packet terms, which is cheap. The result looks like an outage with no traffic spike, which often gets misdiagnosed as a server fault.
How it is actually stopped
In the kernel, before userspace sees anything: SYN cookies, per-source rate limits and connection budgets. This is well-solved infrastructure work and belongs upstream of the game server entirely — by the time a Minecraft process could react, the state has already been consumed.
Common questions
Is a SYN flood the same as a join flood?+
No, and the difference matters. A SYN flood never completes a connection and never speaks Minecraft; it is stopped by packet filtering. A [join flood](/glossary/join-flood) completes everything and speaks perfect Minecraft; it can only be stopped by reading the protocol.
Do SYN cookies fix SYN floods?+
They remove the state-exhaustion problem by not reserving state until the handshake completes, which is a genuine fix for the mechanism. They do not help with the packet volume itself, so a large enough flood still needs absorbing upstream.