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-simulation.com simulates it safely
ddos-simulation.com pressures the same connection state without forgery: it emits raw TCP SYN packets at a guaranteed rate from the worker's real address to a single verified domain pinned to a public address, holding one raw socket for the whole task and never completing the handshake. Because the source is real, the target's SYN-ACKs return and the worker's own kernel resets them — so this is an honest SYN-rate generator rather than a spoofed backlog-exhauster — with every packet attributable and the rate held inside the domain's limits.
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
- 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
When to run a SYN flood test
Run a SYN flood test when transport-layer state — not application logic — is what you need to prove out.
- You've enabled SYN cookies, tuned the backlog, or added connection-tracking capacity and want to confirm it actually holds.
- An edge firewall, load balancer, or DDoS scrubber sits in front and you need evidence its SYN-flood mitigation engages.
- You're sizing headroom before a launch or a high-traffic event and want a known SYN rate the stack can absorb.
How to run a syn flood test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
syn_flood command to a timeline in the portal and set the target 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 a syn flood test in the portal →
Reading the results
Resilient: The listener keeps accepting legitimate connections throughout, SYN-ACK latency stays flat, and backlog and connection-tracking counters stay well below their limits.
Under strain: New connections start timing out, the accept queue or conntrack table fills, or softirq CPU spikes — signs the SYN path, not bandwidth, is the bottleneck.
Availability & limits
SYN floods are reviewed and approved before they run (a manual review) and are priced per engagement — request a quote.
Frequently asked questions
Does this spoof source addresses like a real SYN flood?
No. The worker sends real SYN packets from its own address at a guaranteed rate — nothing is spoofed. Because the source is real, the target's SYN-ACKs come back and the local kernel resets them, so it acts as a SYN-rate generator rather than a spoofed half-open backlog exhauster; it still exercises the SYN path, backlog, and SYN-cookie handling.
Why does this need review?
SYN pressure targets transport-layer state that shared infrastructure may rely on, so it is gated behind a manual review before it can run.
Rehearse the syn flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan