Slowloris

Slow traffic, real outage

Slowloris is a denial-of-service pattern that tries to exhaust the server resources used to keep HTTP connections open. Unlike a high-volume request flood, it does not need to send a dramatic number of completed page views. The pressure comes from many connections that remain open for too long, often without progressing through a request quickly enough for the server to free the worker, thread, socket, or memory attached to that connection.

That makes Slowloris important for defenders because the symptoms can look counterintuitive. Bandwidth may be modest. Request-per-second charts may not show a major spike. The application may not log many completed requests. Yet users see timeouts, load balancers report unhealthy backends, and web workers sit occupied. A response plan that only watches volume can miss the problem until the service is already degraded.

What is being exhausted

Every HTTP service has limits around open connections, request parsing, workers, buffers, and upstream queues. Modern platforms vary in how they handle those limits. Some servers use thread or process pools. Some use event-driven connection handling. Some rely on a reverse proxy in front of an application process. Slowloris-style pressure looks for the weakest place where an incomplete or unusually slow request consumes capacity longer than it should.

The defensive question is not "can a connection be slow?" Legitimate connections can be slow for many reasons: mobile networks, large uploads, accessibility tools, corporate proxies, and poor last-mile connectivity. The better question is whether a population of connections is staying incomplete, idle, or unusually long-lived in a way that is inconsistent with normal user behavior for that route. That is why defenders need baselines for connection age, header completion time, body upload duration, and backend worker occupancy.

Indicators that deserve attention

A likely Slowloris event often shows rising open connections while completed requests stay flat or fall. Web servers may show many requests stuck before headers are complete, before a request body is received, or before the application can respond. Reverse proxies may report upstream connection limits, gateway timeouts, increased 408-style client timeout responses, or 503 responses when no worker is available. Load balancers may mark instances unhealthy even though CPU and database metrics are not extreme.

Source patterns vary. Some events come from a small set of clients; others use distributed sources to avoid simple per-IP limits. User-agent strings, TLS fingerprints, geographies, and ASNs can help, but they should not be the only decision point. Focus on behavior: slow progression through the request lifecycle, unusual connection duration, high concurrency per entity, repeated pressure on the same host or route, and mismatch between low throughput and high resource occupancy.

Where mitigations should sit

Slowloris defense is strongest when layered before the application is forced to spend expensive resources. A reverse proxy, load balancer, edge service, or web server can enforce connection limits, request header timeouts, body timeouts, keepalive policy, and maximum concurrent connections per client or risk group. The goal is to give legitimate slow clients a reasonable window while closing connections that do not make meaningful progress.

Application teams should also separate cheap and expensive paths. A static page, cached page, login endpoint, search route, checkout route, and file upload endpoint do not have the same risk profile. Long body timeouts may be valid for upload routes but excessive for ordinary page requests. Tight global settings can create false positives; loose global settings can allow exhaustion. Route-aware policy, where available, gives defenders better control than one timeout value for the whole estate.

Evaluating controls without creating user pain

Timeout and concurrency changes should be tested against real traffic patterns, not only synthetic best cases. Look at slow mobile sessions, large legitimate form submissions, API clients behind corporate gateways, and assistive technology if those users matter to the service. A control that stops slow attacks but breaks a meaningful user journey will be tuned around during an incident, which weakens the defense when it is most needed.

Useful evaluation questions include: how long does a normal client take to complete request headers, what is the normal range for request body duration, how many concurrent connections does a single real user create, what happens when the backend is already under load, and which logs prove that a closed connection was slow rather than merely unlucky? Strong controls produce evidence. They should let responders explain why connections were closed and whether clean traffic remained healthy.

Misconceptions that slow response

The first misconception is that a DDoS attack always means high bandwidth. Slowloris is specifically dangerous because it can create disproportionate service impact with modest traffic volume. The second is that adding more application servers is the best first response. More capacity can buy time, but it does not fix a policy that allows non-progressing connections to occupy resources too long. If the bottleneck is at the reverse proxy or load balancer, scaling the application tier may not help at all.

Another misconception is that all slow clients are hostile. Some users really do have poor connectivity. That does not mean the service must accept unlimited slow behavior, but it does mean controls should be explicit and measured. Defenders should prefer progress-based timeouts, sensible concurrency caps, and route-specific exceptions over blunt blocks that treat every long connection as malicious.

Incident response priorities

During a suspected Slowloris event, confirm where capacity is being consumed. Check open connection counts, connection age, incomplete request counts, worker occupancy, load balancer health, and route-level errors. Compare those signals with completed request volume and bandwidth. If the pattern fits connection exhaustion, tighten defensive controls at the earliest layer that can act safely, then watch whether legitimate success rates recover.

Communication matters because the outage may not look like a normal traffic spike. Tell operations, support, and engineering teams that the issue is connection pressure, not necessarily a surge in completed page views. After the event, review timeout defaults, keepalive settings, upload exceptions, monitoring gaps, and escalation paths. Slowloris resilience comes from understanding how the service handles slow progress, then making that behavior intentional instead of accidental.