ddos-sim.com All simulations Configure a test

Layer 7 · Application · https_check

HTTPS resilience test

The https_check simulation sends bounded HTTPS requests to a path you choose on a domain you have verified, over a real TLS handshake, and streams back latency and status codes. It is the technique behind the ddos-sim.com free allowance — the quickest way to see where your service starts to bend under encrypted Layer 7 load.

Layer L7 Protocol HTTPS / TLS Command https_check Access Free allowance

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-sim.com simulates it safely

ddos-sim.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 only

Every run is bound to one verified domain you have proven you own. Ownership is checked over DNS or 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

How to run a https check test

  1. Verify your domain. Prove ownership over DNS or HTTPS — it is self-service and takes minutes.
  2. Add the https_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 https check test in the portal →

Availability & limits

HTTPS checks run on the free allowance — three tests every rolling 30 days at up to 10,000 requests per second, no card required — and scale further with prepaid credits after domain verification.

Frequently asked questions

Is the HTTPS resilience test free?

Yes. Every verified workspace gets three HTTPS resilience tests every rolling 30 days at up to 10,000 requests per second, with no card required. Larger or higher-throughput runs use prepaid credits.

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 check against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Configure a test
← All DDoS simulations