ddos-sim.com All simulations Build a test plan

Layer 7 · Application · slowloris_check

Slowloris test

The slowloris_check simulation holds connections open with a slow trickle of keep-alive bytes to test how your service handles slow-connection exhaustion. It rehearses a low-bandwidth Layer 7 attack that has toppled many under-tuned servers.

Layer L7 Protocol HTTP Command slowloris_check Access After verification

What Slowloris does

Slowloris opens many HTTP connections and keeps each one barely alive — sending a partial request header every so often — so the server holds them open waiting for a completion that never comes. It needs almost no bandwidth; it wins by tying up every available connection slot until legitimate users cannot get one.

How ddos-sim.com simulates it safely

ddos-sim.com opens a bounded number of deliberately slow connections to a single verified domain pinned to a public address, drip-feeding keep-alive bytes within the concurrency and worker limits for that domain. It reproduces the exhaustion pattern without any spoofing or malformed payloads.

Authorized targets only

Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.

What the test exercises

  • Connection-slot and worker/thread-pool limits
  • Idle and header read timeouts
  • Reverse-proxy request buffering (a common mitigation)
  • Event-driven vs. thread-per-connection server behavior
  • How gracefully slow clients are shed

When to run a Slowloris test

Run a Slowloris test when you need to know how long a few slow clients can tie up your connection pool.

  • You front the app with a server or proxy (nginx, Apache, a Go server) and want to confirm its slow-client and header timeouts are set.
  • You want to validate connection-count limits and per-IP caps against low-bandwidth, long-lived connections.
  • You're checking that a CDN or WAF terminates and buffers requests so slow clients never reach the origin.

How to run a slowloris test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the slowloris_check command to a timeline in the portal and set the target path or port, rate, and duration.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.

Configure a slowloris test in the portal →

Reading the results

Resilient: Header and idle timeouts close trickling connections, the connection pool stays available, and real requests are served normally.

Under strain: Worker or connection slots fill with half-open requests, new visitors queue or time out, and the server stalls on a handful of slow clients.

Availability & limits

Slowloris tests are available after your domain is verified and are priced per engagement — request a quote.

Frequently asked questions

Does Slowloris need a lot of bandwidth?

No — that is the point. It exhausts connection slots with a slow trickle of bytes, so it exposes servers that allocate a worker per connection or have generous read timeouts.

What is the usual fix it reveals?

Fronting the origin with a buffering reverse proxy or CDN, tightening header read timeouts, and using an event-driven server that does not dedicate a thread per idle connection.

Rehearse the slowloris against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Build a test plan
← All DDoS simulations