Is your Minecraft server under attack or only lagging?

Your players are rubber-banding. Logins time out. The server stutters, then drops off the multiplayer list. From the player seat, a DDoS attack and a bad case of lag look identical. Guess wrong and you waste an hour tuning view distance while an attacker keeps your server offline, or you blame an attacker while a runaway redstone clock eats your CPU.

This guide shows you how to tell whether your Minecraft server is under attack or only lagging. You will learn the signals each problem leaves behind, the in-game and command-line checks to run, and what each result points to.

Takeaway: Genuine lag shows a busy CPU doing real game work and a low TPS you trace to entities, chunks, or redstone. An attack shows traffic your players did not generate: a bandwidth spike with no new logins, or thousands of connection attempts flooding your console. Confirm which pattern you have before you change anything.

How a Minecraft server under attack mimics ordinary lag

Both problems end the same way for the player. Timeouts, mass disconnects, frozen mobs, and a server nobody reaches. The symptoms overlap because both starve the same outcome: the server answering players in time.

The starvation happens in different places. A volumetric attack starves the network link. A bot flood starves the connection handler. Ordinary lag starves the main thread. Three bottlenecks, one shared symptom. This is why a wrong guess costs you. Tuning chunk loading does nothing against a packet flood, and adding bandwidth does nothing against a redstone machine running 200 block updates per tick.

The question matters more each season. Cloudflare’s DDoS data shows attacks rose sharply through 2025, with network-layer floods driving most of the growth, and gaming stays one of the most-targeted sectors. Summer, tournaments, and donation drives are peak windows, because an offline server costs you most then.

The three things people call lag

Before you diagnose anything, separate what lag means. It splits into three types, each measured differently.

• Server TPS lag. The server cannot finish its work inside the tick budget. Minecraft targets 20 ticks per second, one tick every 50 milliseconds. When a tick runs long, TPS drops and the whole world slows. Everyone feels it at once.
• Network lag. Packets between players and the server take too long or get dropped. TPS reads fine. Players see high ping and rubber-banding.
• Client lag. Low FPS on a single player’s machine. The server is healthy. Other players are fine.

The split tells you where to look. If every player lags together, the cause is server-side or network-side. If one player lags alone, it is their machine or their connection. A DDoS attack lives in the network and connection layers, so it shows up as everyone struggling at once.

Signs of a DDoS attack on a Minecraft server

An attack leaves fingerprints. They differ by attack type, so check for both.

Volumetric attacks: Layer 3 and 4

A volumetric attack floods your network link with UDP or TCP packets from a botnet. The goal is to saturate bandwidth before traffic reaches the Minecraft process. Signals to look for:

• Players cannot connect or get instant timeouts, but your TPS reads normal. The game loop is healthy. The pipe to it is blocked.
• Inbound bandwidth spikes with no matching rise in player count. Real players bring a few hundred kbps each. A flood brings gigabits with nobody joining.
• The spike starts and stops sharply. Most attacks are short, often under ten minutes, and many recur in bursts.
• Your host or upstream provider flags traffic on their netflow. They see the link saturation you cannot see from inside the server.

Bot floods and login spam: Layer 7

A Layer 7 attack does not need massive bandwidth. It abuses the Minecraft protocol itself. Bots open connection after connection, join and disconnect on a loop, or send malformed handshake packets. Signals:

• Your server console fills with connection, login, and disconnect lines at a rate no human community produces.
• The same usernames or random UUID-style names appear and vanish in seconds.
• Player slots fill with accounts never moving or chatting.
• The flood arrives from many rotating IP addresses, so banning one address changes nothing.

A bot flood shows up clearly in your logs because the traffic reaches the Minecraft process. A volumetric flood often shows nothing in those logs, because the packets never reach the process. The location of the evidence is itself a clue.

Why is my Minecraft server lagging without an attack

If your checks show no attack traffic, the cause is performance. Genuine lag usually traces to one of these:

• Too many entities. Mob farms, dropped items, and item frames each cost tick time. A few thousand entities in loaded chunks will drag TPS down.
• Too many loaded chunks. Players spread across the map, chunk loaders, and high view distance keep more chunks active than your CPU handles.
• Redstone and hoppers. Complex redstone cascades trigger block updates every tick. Hoppers poll for items constantly, even when empty.
• A weak single core. Minecraft runs most work on one thread. Single-core CPU speed matters more than core count.
• Low memory. Too little RAM forces frequent garbage collection pauses, felt as periodic freezes.

The shared trait: the CPU is busy doing real game work. An attack does not make your server compute more. It stops legitimate traffic from getting through. This difference is the heart of the diagnosis.

Minecraft server lag or DDoS: a five-minute diagnostic

Run these checks in order. Stop when the evidence points clearly one way.

1. 1

   Check TPS and tick time

   Run /tps and /mspt on Paper or a fork. TPS near 20 with low MSPT means the game loop is healthy, so a slowdown points to the network. TPS low with MSPT above 50 ms means the main thread is behind: a performance issue, not an attack.

2. 2

   Profile the main thread

   If MSPT is high, run a Spark or timings profile. It names the plugin, entity, or mechanic eating tick time. A clear culprit confirms genuine lag.

3. 3

   Compare bandwidth to player count

   Open your host panel traffic graph. Inbound gigabits with no matching player rise is a volumetric attack. Traffic rising in step with your player count is normal.

4. 4

   Count connections on the box

   On Linux, run ss to count sockets on your Minecraft port. Hundreds or thousands of half-open or rapidly cycling connections from many IPs signal a flood.

5. 5

   Read the console and crash logs

   A wall of login and disconnect spam means a bot flood. A clean log with a sudden network drop points to a volumetric attack upstream.

The connection count and console read are the fastest tells. Here is what a bot flood looks like on a Linux box:

Four thousand sockets on the Minecraft port with a small community is not normal traffic. Pair it with console lines cycling through many IP addresses every second and you have a bot flood, not lag.

This table sums up which way each signal points:

The crash pattern matters too. If your Minecraft server keeps crashing, read when and how. An out-of-memory crash with a heap dump after hours of uptime points to a memory or plugin problem. A server process the operating system kills, or a host rebooting your node under traffic, points to an attack overwhelming the machine or the link. Crashes timed to a ban, a rival’s event, or a public threat are a strong attacker signal.

How Infinity-Filter stops attacks before they reach your server

If your checks confirm an attack, the fix is not on the server. It is in front of it. Tuning a server already drowning in hostile traffic does not work, because the traffic never had to compute anything to hurt you.

Infinity-Filter sits between the internet and your origin as a reverse proxy and firewall. It absorbs and filters hostile traffic at the edge, so your Minecraft process only ever sees clean connections.

• Layer 3 and 4 mitigation drops volumetric floods, UDP and TCP, before they saturate your link. Your origin IP stays hidden behind the proxy, which removes the direct target.
• Layer 7 filtering inspects the Minecraft protocol. It rejects malformed packets, bot floods, and login spam, so connection-handler attacks stop at the proxy instead of filling your slots.

Be clear on the tradeoff. Routing through a proxy adds a small amount of latency, a few milliseconds when the proxy sits near your players. Filtering also needs configuration to match your server. This cost buys you a server kept reachable when someone decides to take it down.

Confirm first, then fix

Diagnose before you act. Check TPS and tick time, compare bandwidth to player count, count connections, and read your logs. If the evidence shows a busy CPU, fix performance. If it shows traffic your players never generated, you are dealing with an attack, and no amount of server tuning will end it.

For an attack, put filtering in front of your origin so the next flood stops before it reaches your server. Set up Infinity-Filter ahead of your Minecraft server and let the proxy take the next attack instead of your origin.