What an HTTPS flood does
A real HTTPS flood buries an origin under a high volume of legitimate-looking encrypted requests, often aimed at the most expensive endpoints — search, login, cart, or anything that hits a database. Because every request rides
inside TLS, cheap network-layer filtering cannot see the payload, so the load lands on your application and its backends.
How ddos-simulation.com simulates it safely
ddos-simulation.com reproduces that pressure without ever leaving bounds. Requests go only to a single verified domain, resolved to a pinned public address with private and loopback destinations blocked; the certificate
is validated; redirects are not followed; and the request rate, concurrency, and worker count stay inside the limits set for that domain. Nothing is spoofed and no arbitrary payloads are sent.
Authorized targets onlyEvery 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
- TLS termination and session-reuse capacity
- Request throughput and connection-pool limits
- Backend, database, and cache behavior under sustained load
- CDN, WAF, and rate-limiter responses to encrypted traffic
- Autoscaling reaction time and cost
When to run an HTTPS flood test
Run an HTTPS flood test when you need to know how the application tier holds up under a burst of full, legitimate-looking requests.
- You want to validate autoscaling, caching, and origin capacity against a surge of real HTTPS requests.
- A WAF, CDN, or rate limiter is meant to absorb request floods and you need proof it engages.
- You're rehearsing a Layer 7 flood ahead of a launch or a known high-traffic event.
How to run an HTTPS flood test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
https_flood command to a timeline in the portal and set the target path or port, rate, and duration. - Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
- Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
- Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.
Configure an HTTPS flood test in the portal →
Reading the results
Resilient: Response codes stay 2xx, latency degrades gracefully, and caching or autoscaling absorbs the surge without the origin buckling.
Under strain: 5xx responses and timeouts climb, latency spikes, or the origin saturates because the CDN or WAF passed the flood straight through.
Availability & limits
HTTPS 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 the HTTPS flood test priced?
Each engagement is priced individually. Build a plan (or ask us to design one) and request a quote; we price the specific test and confirm timing. There is no subscription and no upfront pricing.
Does the test follow redirects or hit other hosts?
No. Requests go only to the single verified domain, resolved to a pinned public address. Redirects are not followed and private or loopback addresses are blocked.
Will it validate my TLS certificate?
Yes. Each request completes a real TLS handshake and validates the certificate for the verified domain, so the run reflects your production TLS path.
Rehearse the HTTPS flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan