Why Killing Floor servers lag and freeze

Short answer: usually it is neither your connection nor a “weak server”. It is DDoS — a stream of forged connections that makes the game process spend its cycles on garbage instead of gameplay. By 2026 these attacks hit Killing Floor servers almost daily, and it is a problem for the whole scene, not one host.

This page explains what actually happens, why it is hard to filter, and what a player can realistically do.

What a player sees

The symptoms are distinctive:

Ping looks fine, but the game stutters. This is jitter, not latency: packets arrive unevenly. “Ping is 80 but I still freeze” describes this attack almost word for word.
The server stalls for 1–3 minutes. Zeds stand still, damage does not register, then everything catches up in one jump. You can miss a whole trader window.
? instead of a ping in the server browser. The server is alive but cannot answer the listing query in time.
You get dropped and cannot rejoin — and a couple of minutes later you can.
Every server lags at once, no matter which address you connect through.

Telling it apart from your own problems is easy: if only Killing Floor stutters while every other server and site is fine, you almost certainly hit an attack window.

How it works

Killing Floor runs on Unreal Engine 2.5, an engine from 2004. It has one property that makes this attack cheap:

The server creates a connection object for any UDP packet from an unknown address — before any check of whether it is a player or garbage.

So a single forged packet makes the server allocate a connection, write two log lines and tear it all down again. Multiply that by tens of thousands per minute and the single-threaded game process saturates its CPU core. The tick stops, and every player on that server freezes, regardless of their ping or ISP.

That is why everyone lags at once and identically: the bottleneck is not the network, it is inside the game process.

Attacks do not come in one shape. Three families dominate:

Connection flood. Thousands of small UDP packets to the game port, each from a new address. The most damaging variant — this is what burns the server’s CPU time.

Amplification (reflection). The attacker sends a short query to somebody else’s misconfigured server (NTP, DNS, CLDAP, SSDP) with the game server’s address forged as the sender. That server answers with a packet tens or hundreds of times larger, and all of it lands on the game. Ratios of 1:800 have been documented.

Status-query flood. Mass requests to the port that returns the player list and settings. Big answer, tiny request — the same economics.

Why it is hard to filter

Because at packet level the attack looks like an ordinary player joining. It uses an ephemeral source port like a real client, a normal length and an ordinary TTL. The classic amplification tells (service source port, zero length, abnormal TTL) do not fire on recent waves: the attackers know them and stay clear.

Second, the attack is distributed by design. A single address sends about a dozen attempts per day, well below any sane threshold. A “no more than N connections per IP” limit never sees it.

Third, attackers adapt to the defense. Close one signature and the next wave arrives without it. This is why server administrators generally do not publish their exact filtering rules: a published rule stops working within days.

Why IP bans do not help

The addresses in the attack logs are forged. The sender simply writes somebody else’s address into the “from” field, and the reply — which it never wanted — goes nowhere.

How obvious is this? In our own wave analyses, the “sources” regularly turn out to be AWS CloudFront edge nodes. A CDN does not connect to a Killing Floor server over UDP; those addresses were forged. Ban them and you ban bystanders and break part of the internet for yourself.

There is a nastier variant: with reflection, the packets do arrive from genuine addresses — but those belong to fellow victims, somebody else’s misconfigured servers being used unknowingly.

The technical fix is BCP 38 (RFC 2827): the sender’s own provider validating source addresses on the way out. The standard is over twenty years old and still not deployed everywhere, because a network that turns it on gains nothing itself — only its neighbours benefit. The CAIDA Spoofer project measures the coverage worldwide, and the gaps are still wide: thousands of autonomous systems let forged addresses out. Attackers deliberately buy hosting there.

So why is the source provider not banned

Fair question, but there are really two different cases behind it.

Connection flood — there is nobody to ban. The providers whose addresses appear in the logs sent nothing. The packets left an entirely different network, with somebody else’s address written into the “from” field. An abuse report to them misses: that traffic never existed on their side. Only the network the packets actually left can stop it — which is exactly the BCP 38 that is missing there.

Amplification — banning would mean banning their own customers. Here the addresses are genuine: the packets do arrive from real but misconfigured third-party servers. Their owners are victims too, their machines used without their knowledge. The report reaches the right place, but to the provider it is a customer’s server, not their own, and almost nobody takes on fixing somebody else’s configuration.

What it costs the attacker

Less than you would think: roughly $15–50 per month, and more likely the lower end.

“Stress testing” services (booters, stressers) sell subscriptions for $20 to $125 per month, with entry tiers around $15–20. You pay for a subscription, not for an attack: a day of continuous flooding costs exactly what five minutes costs. That explains the shape of what we see — the attack runs for weeks because there is no reason to stop it, the money is already spent.

There is an even cheaper route that needs no service at all: one rented VPS at a host that does not filter outbound traffic. That is $5–20 a month, and a single such machine can push well over a hundred thousand packets per second — enough to stall a game server.

The volumes that bring Killing Floor to its knees are trivial by DDoS standards: single-digit to low-double-digit megabits per second. It is not the bandwidth that kills, it is the packet count — each one makes the engine create a connection. An attack of that size fits the cheapest plan of any service.

That is the whole asymmetry: the attack costs tens of dollars a month, while defending against it costs a filtered transit link, backup routes and an administrator’s time. Two orders of magnitude apart, and not in the defender’s favour.

What a player can do

Honestly: you cannot stop the attack. You can avoid wasting your nerves on it:

Check that it is not you. If only Killing Floor stutters while everything else works, it is not your side.
Switch servers. A wave usually hits one or two servers at a time and moves on every few minutes. The mode next door is often fine right then.
Switch entry point. If the project publishes several addresses (for example one per region), try another — they take different routes.
Clean your favorites. Dead entries show ? and N/A and look like “everything is down” while the servers are alive. There is a separate guide: How to clear favorite servers.
Report the time to the admins. “Everything lags” helps far less than the exact clock time and the server name — that is what locates the attack window in the logs.

What not to do: reinstall the game, change network settings, or buy a “gaming VPN against lag”. None of that touches this problem.

What administrators do

The working setup in 2026 looks like this:

A scrubbing transit in front of the servers. Traffic first reaches a facility that filters it in hardware, and only then reaches the game.
A hidden real address. If the machine’s true IP is known, the filter is simply bypassed.
Dropping garbage before the game process. Anything identifiable as forged must die in the kernel — before Unreal Engine creates a connection object.
Several independent routes. When a provider under pressure pulls an address from BGP (and that does happen), a second path has to remain.

There is no fully reliable defense: the networking source of Unreal Engine 2.5 is closed, so telling a real client from a forgery has to rely on indirect signals. Both the community and the requests filed with hosting providers say so openly.