What is a Slowloris attack?

Slowloris is a denial-of-service technique that opens many connections to a web server and sends request headers extremely slowly, so the server keeps each connection open waiting for the rest. Servers that dedicate a worker to each connection, like Apache in its older modes, run out of workers and stop answering real visitors.

Is a 'LIKELY VULNERABLE' Slowloris result real?

Not necessarily. Nmap's http-slowloris-check infers the result from timing: it sees that the server keeps a slow connection open longer than a normal one. It does not attack the server. Treat it as a prompt to check your server's request timeouts, not as proof.

Does a CDN protect against Slowloris?

Usually yes. A CDN or reverse proxy such as Cloudflare or nginx waits for the complete request before passing it to your server, so slow partial requests never reach it. If your site is behind one, the scan may be testing the provider's edge, not your server.

Medium risk Web server · Denial of service

Possible Slowloris weakness: what it means and how to fix it

By Stephane Meus, CEH, PenTest+ · Updated 17 October 2026 · 5 minute read

Short answer: Slowloris is a way to knock a web server offline by opening many connections and sending each request painfully slowly, so the server runs out of room for real visitors. The scan's check doesn't attack anything. It noticed your server keeps a slow, unfinished request open longer than it should, which suggests it could be worn down this way.

The fix: make the server drop requests that arrive too slowly (request timeouts), limit connections per visitor, and ideally put a reverse proxy or CDN in front of it.

What is Slowloris?

A normal visitor sends a complete web request in a fraction of a second. A Slowloris attacker opens hundreds of connections and sends each request one header line at a time, every few seconds, never quite finishing. The server politely waits on each one.

Servers that give every connection its own worker, like Apache in its older prefork and worker modes, have a fixed number of workers. Once the attacker holds them all, real visitors can't get in. It needs very little bandwidth, so a single laptop can do it. Event-driven servers such as nginx and IIS hold up much better, though they still benefit from timeouts.

What the scan actually checked

FreshScanSentry runs Nmap's http-slowloris-check. It opens a couple of connections, sends a request slowly, and measures how long the server keeps waiting compared with a normal request. A long wait produces LIKELY VULNERABLE. It's a timing-based guess, which is why FreshScanSentry rates it Medium, not High, and never floods your server.

How it looks in your report your-site.com

443 Possible Slowloris denial-of-service weakness Result: likely vulnerable Medium

Likely, not confirmed: inferred from timing

First: is it your server or your provider's?

If your site sits behind a CDN, a load balancer or a hosting platform's edge proxy, the scan may be measuring that front door, not your server. FreshScanSentry adds a note to the finding when it suspects this, for example when the host answers on nearly every port. In that case the provider handles slow requests, and there's usually nothing for you to change.

How to fix it

Apache

Turn on request timeouts with mod_reqtimeout, which ships with Apache 2.4 and is enabled by default on many Linux distributions. Check it's loaded, then set:
```
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
```
This drops a client that takes more than 20 seconds to send its headers (up to 40 if data keeps trickling in at 500 bytes per second or faster).
Use the event MPM instead of prefork, if your setup allows (PHP through PHP-FPM rather than mod_php). It handles idle connections far better.
Limit connections per address with a module such as mod_qos, or at the firewall (see below).

nginx

client_header_timeout 10s;
client_body_timeout 10s;
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;

nginx's defaults (60 seconds) are already much less exposed than Apache's prefork mode, but shorter timeouts and a per-address connection limit close the gap.

IIS

Lower the Header wait timeout and Connection timeout in the site's limits, and use IIS's Dynamic IP Restrictions to cap concurrent requests per address.

Any server: put something in front

A CDN or reverse proxy (Cloudflare, a load balancer, or nginx in front of Apache) waits for the full request before passing it on. Slow requests never reach your server. This is the most complete fix.
A firewall connection limit per address. With iptables, for example: iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 50 -j REJECT.

Then re-scan

After the change, run another scan. The finding should disappear, or the timing should no longer look suspicious.

Common questions

Can the scan itself take my site down?

No. The check uses a couple of connections, not the hundreds an attack needs.

How worried should a small business be?

It's a nuisance attack: it takes the site offline while it runs but doesn't steal data. It's worth fixing, especially for a site that takes orders or bookings, but it comes after anything rated High.

Our site is on shared hosting.

Ask your host whether request timeouts are configured, or put the site behind a free CDN plan.

Sources: Nmap http-slowloris-check · Apache mod_reqtimeout · NVD: CVE-2007-6750 · nginx limit_conn