ddos-sim.com All simulations Build a test plan

Layer 7 · Application · http_flood

HTTP flood test

The http_flood simulation sends bounded HTTP requests to a path you choose at a high sustained rate and records status codes and latency. It is the clearest way to rehearse a Layer 7 request flood against a domain you own and watch how the application tier responds.

Layer L7 Protocol HTTP Command http_flood Access After verification

What an HTTP flood does

An HTTP flood (a GET or POST flood) sends far more application requests than an origin can serve, targeting endpoints that are cheap for an attacker to request but expensive for you to answer. The traffic looks like ordinary browsing, so it slips past crude network filters and exhausts worker threads, connection pools, and databases.

How ddos-sim.com simulates it safely

ddos-sim.com issues bounded HTTP requests to the exact path you specify on a single verified domain, pinned to a public address with private and loopback ranges blocked. Rate, concurrency, and worker limits are enforced per domain, and each worker refuses any target other than the one it was assigned.

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

  • Application request throughput and thread/worker pools
  • Upstream, database, and cache saturation
  • Reverse-proxy and load-balancer connection handling
  • Rate limiting and caching effectiveness on hot paths
  • Error-handling and graceful-degradation behavior

When to run an HTTP flood

Run an HTTP flood when you want to see how an endpoint holds up under a high-rate Layer 7 request load you control.

  • You want to find where a specific path starts to bend under sustained request pressure before an adversary does.
  • You're validating that autoscaling, caching, a CDN, or a rate limit actually absorbs application-layer request volume.
  • You need a latency and status-code baseline for a hot path before layering on heavier techniques.

How to run an HTTP flood test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the http_flood 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 an HTTP flood test in the portal →

Reading the results

Resilient: Status codes stay 2xx, latency stays within your threshold as load rises, and any autoscaling or caching kicks in as designed.

Under strain: 5xx responses or timeouts appear, latency climbs past your threshold, or a rate limit trips earlier than expected.

Availability & limits

HTTP floods are available after your domain is verified and are priced per engagement — request a quote and we price the specific test.

Frequently asked questions

How is this different from the HTTPS flood?

The HTTP flood exercises the plaintext Layer 7 path, while https_flood adds a real TLS handshake per request. Use HTTP to isolate application-tier behavior and HTTPS to include TLS termination cost.

Can I target a specific endpoint?

Yes. You choose the path, so you can point the flood at the exact endpoint whose resilience you want to measure, on your verified domain.

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

Build a test plan
← All DDoS simulations