Slowloris: How a Slow HTTP Attack Works

Most people picture a denial-of-service attack as a flood: millions of packets hammering a server until bandwidth collapses. Slowloris, introduced by security researcher RSnake in 2009, works on a completely different principle. It doesn't need a botnet. It doesn't need much bandwidth. It just needs patience.

The idea is simple: open as many connections to a web server as you can, and send HTTP headers so slowly that each connection stays open indefinitely without ever completing a request. The server allocates a worker thread (or equivalent resource) to every open connection. Once the pool is full, every new visitor, including real users, gets turned away.

A single machine running a Slowloris script can take down an Apache server that would shrug off a volumetric flood. That's what made it remarkable when it appeared, and why understanding it still matters for anyone building or operating web infrastructure.

HTTP/1.1 assumes clients are mostly well-behaved. When a browser connects, it sends a complete request (method, path, headers, blank line) and waits for a response. The server reads the request, processes it, sends a response, and closes the connection (or keeps it alive for reuse).

But nothing in the protocol requires the client to send the request quickly. A client can open a TCP connection, send one byte of a header, wait ten seconds, send another byte, wait again. From the server's perspective, this is a legitimate connection in progress. The server waits. It has to, because slow clients on bad mobile networks are real.

Thread-per-connection servers like traditional Apache with prefork MPM are especially vulnerable. Each open socket consumes a worker process whether or not useful work is happening. Ten slow connections on a server with ten workers means zero capacity left for anyone else.

A normal HTTP GET request arrives in one shot: the client sends the request line, a few headers, a blank line, and it's done. The server can immediately start routing the request.

A Slowloris client sends the request line, then dribbles header fields one character at a time, or sends a header like Content-Length with a huge value and never sends the body. Some variants open connections and send partial headers, periodically adding a new header line to reset idle timers. The request never completes, but the connection never times out either.

A SYN flood exploits TCP's three-way handshake by sending SYN packets without completing connections, filling the server's half-open connection queue. Slowloris completes the handshake, so SYN cookies don't apply. Volumetric attacks overwhelm bandwidth; HTTP floods exhaust CPU with valid requests. Slowloris exhausts connection slots and worker threads with incomplete requests sent at kilobytes per second.

The lab below ties the pieces together in one system: a fixed worker pool, slow versus legitimate clients, a side-by-side view of how Slowloris compares to other denial-of-service patterns, and mitigations you can toggle (reverse proxy limits, idle timeouts). Click a connection slot to inspect wire-level HTTP. None of this sends real network traffic.

The most effective defense is aggressive connection and header timeouts. If a client hasn't completed its request within a few seconds, close the socket. Modern versions of Apache, nginx, and most load balancers ship with sensible defaults that didn't exist in 2009. mod_reqtimeout for Apache and client_header_timeout in nginx exist specifically for this class of attack.

A reverse proxy or load balancer in front of the origin absorbs and filters slow connections before they reach application workers. The proxy can enforce per-IP connection limits: if one address holds more than a handful of open connections, drop the excess. This is why putting nginx or a cloud load balancer in front of a vulnerable origin essentially solves the problem.

Event-driven architectures (nginx, Node.js with proper connection handling, Go's net/http with timeouts) don't allocate one thread per connection, which makes pure Slowloris less effective, though slow clients can still exhaust file descriptors or memory if limits aren't configured. The fix is always the same: timeouts, limits, and not exposing thread-per-connection servers directly to the internet.

Slowloris is a lesson in how protocol trust assumptions become attack surfaces. HTTP's tolerance for slow clients is a feature for real users on bad networks and a vulnerability when abused deliberately. The attack is old, well-understood, and largely mitigated by modern defaults, but the underlying pattern (holding scarce server resources with minimal client effort) appears in slow POST attacks, RUDY, and connection-draining techniques against databases and APIs.