ddos-sim.com All simulations Configure a test
Home › DDoS simulation testing › SYN flood test

Layer 4 · Transport · syn_flood_check

SYN flood test

The syn_flood_check simulation opens bounded TCP handshakes to pressure the connection table on a domain you own — full handshakes, nothing spoofed. It rehearses the classic SYN-flood failure mode while staying attributable and in-bounds.

Layer L4 Protocol TCP Command syn_flood_check Access Extended validation

On this page

  1. What a SYN flood does
  2. How ddos-sim.com simulates it safely
  3. What the test exercises
  4. How to run the test
  5. Availability & limits
  6. FAQ
  7. Related simulations

What a SYN flood does

A traditional SYN flood sprays half-open connection requests with forged source addresses, filling the target's SYN backlog so it can no longer accept legitimate connections. The forged sources also make the traffic hard to trace and block.

How ddos-sim.com simulates it safely

ddos-sim.com pressures the same connection state without forgery: it opens bounded, fully completed TCP handshakes from the worker's real address to a single verified domain pinned to a public address. That stresses the backlog and connection table while keeping every packet attributable, with rate and concurrency held inside the domain's limits.

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

  • SYN backlog and half-open connection limits
  • Connection-table and conntrack capacity
  • SYN-cookie and TCP tuning under pressure
  • Firewall and load-balancer state handling
  • Time-to-recover once the test stops

How to run a syn flood test

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

Availability & limits

SYN floods require extended validation (a manual review) and run with prepaid credits. They are excluded from the free allowance.

Frequently asked questions

Does this use spoofed half-open connections like a real SYN flood?

No. It completes full TCP handshakes from the worker's own address so the load stays attributable. It still pressures the backlog and connection table, but nothing is spoofed.

Why is extended validation needed?

SYN pressure targets transport-layer state that shared infrastructure may rely on, so it is gated behind a manual review before it can run.

Related simulations

TCP port stress test port_check Open a controlled number of real TCP connections to a port you own and confirm how listener backlog, firewalls, and connection tracking hold up under load. UDP flood test udp_flood Simulate a bounded UDP flood against infrastructure you own to probe UDP ingress filtering, bandwidth headroom, and rate limits. HTTPS resilience test https_check Run an authorized HTTPS resilience test against a domain you own.

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

Configure a test
← All DDoS simulations
© 2026 ddos-sim.com · Authorized testing only. Simulations · Terms · Acceptable use · Privacy