TCP vs UDP Attacks on Minecraft Servers: Breaking Down the Differences

Every time a player connects to a Minecraft server, data travels over one of two transport protocols: TCP or UDP. Java Edition uses TCP. Bedrock Edition uses UDP. This is not just a technical detail. It determines what attacks are possible, how dangerous they are, and how to defend against them.

This article breaks down both protocols from a DDoS attack perspective. No abstract theory. Real numbers and specific recommendations.

TCP and UDP: the basics in 2 minutes

If you already know the difference between TCP and UDP, skip ahead. For everyone else, here is the gist.

TCP (Transmission Control Protocol) establishes a connection before sending data. Three-way handshake: client sends SYN, server responds SYN-ACK, client confirms with ACK. Only then does data exchange begin. Every packet is numbered, delivery is guaranteed, lost packets are retransmitted.

UDP (User Datagram Protocol) does not establish connections. Packets are sent without acknowledgment, without numbering, without delivery guarantees. Fire and forget. This makes UDP faster (less overhead) but less reliable.

TCP (Minecraft Java):
Client  ──SYN──>     Server
Client  <─SYN-ACK──  Server
Client  ──ACK──>     Server
Client  <──DATA──>   Server   ← established connection

UDP (Minecraft Bedrock):
Client  ──PKT──>  Server     ← just sends
Client  ──PKT──>  Server     ← no acknowledgment
Client  ──PKT──>  Server     ← no state

Minecraft Java Edition listens on TCP port 25565. Minecraft Bedrock Edition listens on UDP port 19132. Some servers enable the Query protocol, which runs on UDP port 25565. Remember that. It matters later.

TCP attacks: classic with a predictable pattern

TCP attacks on Minecraft servers are well understood and generally well filtered. But "well filtered" does not mean "harmless." Here are the main types.

SYN Flood

The most common TCP attack. The attacker sends a massive number of SYN packets (the first step of the handshake) with spoofed source IPs. The server allocates memory for each half-open connection and sends SYN-ACK. The response goes to the fake IP, ACK never arrives. The half-open connection table fills up, and new legitimate clients cannot connect.

For Minecraft servers, SYN flood is particularly dangerous because Java servers typically have a limited backlog. Default net.core.somaxconn in Linux is 4096. At 100,000 SYN/s, that queue fills in a fraction of a second.

Typical volumes: 1 to 50 Gbps. We have seen attacks on Minecraft servers peaking at 30 Gbps of pure SYN flood. More details on SYN flood attacks in our dedicated article.

ACK Flood

The attacker sends masses of TCP packets with the ACK flag set. The server receives ACKs for connections that do not exist and spends resources looking them up in the connection table. If the server uses conntrack (and it almost certainly does), each packet triggers a hash table lookup.

ACK flood is less effective than SYN flood because packets without matching connections are quickly dropped. But at sufficient volume (10+ Gbps), packet processing load becomes a problem.

RST Flood

A stream of TCP packets with the RST (reset) flag. The goal: terminate existing player connections. If the attacker guesses the sequence number of an active connection, they can forcibly tear it down. In practice, guessing sequence numbers is difficult, so RST flood usually works as a volumetric attack, overwhelming bandwidth.

Slowloris

An elegant attack that does not require high traffic volumes. The attacker opens many TCP connections and sends initial handshake bytes very slowly, one byte every 10-30 seconds. The server keeps these connections open waiting for completion, eventually exhausting the concurrent connection limit.

For Minecraft servers, Slowloris looks like this: hundreds of connections start the handshake but never finish it. Each holds a slot. When slots run out, real players cannot join.

Why TCP attacks are easier to filter

TCP attacks are predictable because TCP is inherently stateful. Every connection has a clear lifecycle: SYN, SYN-ACK, ACK, DATA, FIN. A firewall can track this state and drop packets that do not fit the expected sequence.

SYN cookies solve SYN flood almost completely. Instead of allocating memory per SYN, the server encodes connection information in the SYN-ACK sequence number. Memory is allocated only when a valid ACK with the correct sequence number arrives. SYN flood with spoofed IPs uses zero memory.

Conntrack (connection tracking) tracks the state of every TCP connection. ACK for a nonexistent connection? Drop. RST with wrong sequence number? Drop. Cheap and effective.

UDP attacks: a different beast

UDP attacks on Minecraft servers work fundamentally differently. No state, no handshake, no packet ordering. This creates enormous problems for defense.

UDP Flood

The simplest attack: sending masses of UDP packets to the target port. Since UDP requires no connection setup, the attacker can send packets with spoofed IPs without any restrictions. The server must accept every packet and check whether an application is listening on that port.

For Bedrock servers, this is critical: every incoming UDP packet on port 19132 hits RakNet (Bedrock's networking library), which spends resources trying to parse it.

UDP flood volumes can be enormous. Since packets are generated without waiting for a response, a single attacking server can send gigabits of junk traffic per second. A botnet of several thousand nodes easily generates 100+ Gbps of pure UDP flood. And every packet must be processed at least minimally before it can be identified as junk.

A separate problem: UDP flood on random ports. If the attacker sends packets to random ports instead of 19132, the server generates an ICMP Port Unreachable for each one. This creates additional CPU load and can fill the outbound channel with ICMP responses. The fix: limit ICMP rate via sysctl or drop outgoing Port Unreachable entirely.

Amplification attacks: where 1 byte becomes 50

This is where UDP gets truly dangerous. Amplification uses legitimate internet services as traffic multipliers. The principle is simple:

1. Attacker sends a small request to an open service (DNS, NTP, memcached)
2. Source IP is spoofed to the victim's IP
3. The service responds with a much larger reply to the victim's IP
4. The victim receives traffic 10 to 1000+ times larger than what the attacker sent

Amplification factors by protocol:

Protocol	Amplification Factor	Typical Attack Volume
DNS	28-54x	10-100 Gbps
NTP (monlist)	556x	50-400 Gbps
Memcached	10,000-51,000x	100-1,700 Gbps
SSDP	30x	5-50 Gbps
CLDAP	56-70x	10-100 Gbps

Yes, you read that correctly. Memcached can amplify traffic 51,000 times. The attacker sends 1 MB of data, the victim receives 51 GB. In the context of Minecraft: an unprotected Bedrock server can be hit with 100+ Gbps via NTP amplification. Any hosting provider's bandwidth fills instantly.

Query Flood: attack through a built-in feature

Minecraft Query protocol runs on UDP, typically port 25565. It returns server information: player count, MOTD, plugin list, version. One Query request is about 9 bytes. The response ranges from 200 to 2000+ bytes, depending on plugins and players.

That gives an amplification factor of 20x to 200x. Using Minecraft itself, no external services needed.

Worse, many servers enable Full Query, which returns complete plugin and player lists. On a server with 50 plugins and 100 players, a Full Query response can be 3-4 KB. Amplification factor: 400x+.

Solution: disable Query if you do not need it.

# server.properties
enable-query=false

Why UDP is harder to filter

With TCP, a firewall can ask: "Does this packet belong to an established connection?" If not, drop it. With UDP, you cannot ask that question because connections do not exist. Every packet is independent. A legitimate Bedrock player packet looks exactly like an attack packet. Both are just UDP datagrams to port 19132.

What is left:

• Rate limiting per IP: limit packets per second from a single IP. Works against attacks from real IPs, useless against spoofed IPs.
• Payload inspection (DPI): analyze UDP packet contents. Legitimate RakNet packets have a specific structure. Attack packets are often random bytes. But this is expensive.
• GeoIP filtering: drop packets from regions with no players. Crude but effective.
• Behavioral analysis: analyze traffic patterns. 10,000 UDP packets per second from one IP is not a player.

The numbers side by side

Parameter	TCP Attacks	UDP Attacks
Minecraft Edition	Java (port 25565)	Bedrock (port 19132)
Typical volume	5-50 Gbps	50-500+ Gbps
Max recorded	~300 Gbps	~3.5 Tbps
Amplification	Not possible	Up to 51,000x
IP spoofing	Hard (needs ACK)	Trivial
Stateful filtering	Effective	Not possible
Attack cost	$$$	$
Defense cost	$	$$$

Notice the cost asymmetry. A TCP attack requires real resources: servers that complete handshakes or generate high packet rates. A UDP amplification attack costs almost nothing: a couple scripts, a list of open resolvers, done.

According to 2026 DDoS trends, UDP attacks on Minecraft servers account for about 70% of all DDoS incidents. TCP attacks remain relevant but are shifting toward application-level: fake Minecraft handshakes, login floods, bot joins.

Real-world scenario: hybrid attack

Let's walk through a typical attack on a server supporting both Java and Bedrock. The attacker operates in phases.

Phase 1: Reconnaissance. The attacker port-scans the server. Finds TCP 25565 (Java), UDP 19132 (Bedrock), UDP 25565 (Query enabled). Via Query, they get the plugin list and server version.

Phase 2: UDP amplification. DNS amplification targeting the server IP. 5 Gbps outbound becomes 150 Gbps inbound. Server bandwidth is saturated. All players, Java and Bedrock, disconnect. The server loses contact with monitoring.

Phase 3: SYN flood. In parallel with the UDP attack, SYN flood targets port 25565. Even if the upstream provider filters some of the UDP amplification, SYN flood stresses conntrack and the backlog. The server cannot accept new TCP connections.

Phase 4: Bot join. After the first two waves weaken, the attacker sends bots that complete the TCP handshake, submit valid Minecraft logins, and join the server. Slots fill with bots. Real players end up in the queue.

This is not theory. Multi-layer attacks like this became standard in 2025-2026. Defense must operate at all layers simultaneously.

Different protocols, different defense strategies

Protecting a Java server (TCP) and a Bedrock server (UDP) requires different approaches. You cannot apply the same logic to both.

Protecting Java Edition (TCP)

For TCP, powerful tools exist at the OS kernel level:

1. SYN cookies - solve SYN flood without extra software
2. Connection tracking - state-based packet filtering
3. Handshake verification - verify completion before allowing access
4. Application-level checks - validate Minecraft protocol after TCP connection

Protecting Bedrock Edition (UDP)

For UDP, we lose stateful tools. No SYN cookies, no conntrack. Different methods are needed:

1. XDP-level rate limiting - drop packets before they reach the kernel
2. RakNet payload validation - verify Bedrock packet structure
3. Cookie-based verification - custom challenge-response over UDP
4. GeoIP filtering - geographic restrictions
5. Upstream filtering - BGP Flowspec at provider level

For server owners running both editions (Java and Bedrock), understanding that no single solution covers both protocols is critical. A protection service must have separate modules for TCP and UDP traffic. MineGuard, for example, processes Java and Bedrock traffic through different pipelines, each with its own set of rules and algorithms.

Minecraft Query: the hidden threat

Query runs on UDP on the same port as Java Edition (25565 by default). It is enabled by default in many hosting configurations. Even if you only run Java Edition and think UDP does not concern you, Query creates a UDP attack surface.

Three problems with Query:

1. Amplification - small request, large response. Your server can be used as an amplifier for attacks on others.
2. Information disclosure - Query returns server version, plugin list (including versions), player IPs with Full Query. Reconnaissance before the real attack.
3. Resource consumption - each Query request is processed by the server's main thread. A flood of Query requests can cause TPS drops.

# Disable Query in server.properties
enable-query=false

Practical recommendations: what to do right now

For all servers

• Disable Query (enable-query=false)
• Close all unused ports (especially UDP)
• Enable firewall with port whitelist
• Do not expose RCON to the internet
• Hide your real server IP behind DDoS protection

For Java Edition (TCP)

# SYN cookies
sysctl -w net.ipv4.tcp_syncookies=1

# Increase backlog
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# Limit SYN-ACK retries
sysctl -w net.ipv4.tcp_synack_retries=2

For Bedrock Edition (UDP)

# Increase UDP receive buffer
sysctl -w net.core.rmem_max=26214400

# Rate limiting via iptables
iptables -A INPUT -p udp --dport 19132 \
  -m hashlimit \
  --hashlimit-above 50/sec \
  --hashlimit-burst 100 \
  --hashlimit-mode srcip \
  --hashlimit-name bedrock \
  -j DROP

# Close UDP port 25565 if Query is disabled
iptables -A INPUT -p udp --dport 25565 -j DROP

Common mistakes admins make

Some typical errors that turn a minor attack into full downtime.

Mistake 1: Open ports. Everything is open: 25565 TCP and UDP, 19132, RCON on 25575, SSH on default 22. Every open port is an attack vector. Close everything you do not use.

Mistake 2: Query enabled. Worth repeating because it matters. Query is enabled by default in many builds. It is not needed for server operation. It is only needed for monitoring, and even for that there are better alternatives.

Mistake 3: Real server IP in DNS. If your server's IP is known to the attacker, they can hit it directly, bypassing any cloud protection. Use DDoS protection with proxying and never expose the real IP.

Mistake 4: No rate limiting. Without connection rate limits, a single IP can send thousands of requests per second. Even basic hashlimit in iptables significantly reduces attack effectiveness.

Mistake 5: Ignoring sysctl. Default Linux parameters are not designed for operation under load. SYN cookies disabled, backlog small, UDP buffers minimal. Five minutes of sysctl configuration can prevent an hour of downtime.

The bottom line

TCP and UDP attacks on Minecraft servers are two different worlds. TCP attacks (SYN flood, ACK flood, Slowloris) are dangerous but well understood and effectively filtered through SYN cookies, conntrack, and stateful inspection. UDP attacks (flood, amplification, Query abuse) are harder and more dangerous: higher volumes, easier spoofing, tougher filtering.

If you run Java Edition, make sure SYN cookies are enabled and Query is disabled. If Bedrock, invest in rate limiting and upstream filtering. If both, use protection that understands the difference between protocols and filters each with its own ruleset.

There is no universal "protect from everything" button. But understanding how attacks work on each protocol is the first step toward building real defense.