DDoS stress testing looks simple from the outside: pick a target, pick a method, hit start. But between "the panel accepted my request" and "the target actually degrades", there is a whole chain of factors that decides whether your test produces signal or just noise.
After running capacity tests against every kind of target — bare-metal game servers, CDN-fronted websites, API gateways behind load balancers — the same mistakes keep showing up. Here is the checklist I run through before every serious session.
1. Know What Layer You Are Actually Testing
Layer 4 and Layer 7 failures look identical from a dashboard (latency up, timeouts), but they break completely different things:
- L4 floods (SYN, UDP, ACK) saturate the network path itself. Bandwidth charts on the target side tell the story: once inbound exceeds port capacity, everything behind that port suffers equally.
- L7 methods (HTTP, HTTPS floods) consume application resources. Bandwidth can look fine while the PHP-FPM pool, Node.js event loop, or database connection queue is exhausted.
If you don't know which one you are testing, you can't read the results. A target that "survives" an L4 flood at 5 Gbps might collapse under a modest L7 flood that never exceeds 100 Mbps, because the app layer was never sized for concurrent request load.
2. Baseline Before You Break
The most useless sentence in stress testing is "the site went down". Went down from what?
Before the first packet: record normal response time, normal error rate, normal CPU and memory on the target side (if you own it), and normal time-to-first-byte from at least two vantage points. Without a baseline you cannot distinguish "degraded 3x" from "degraded 300x", and those are very different findings about your infrastructure.
3. Method Selection Matches the Target, Not the Habit
People tend to reuse the same two or three methods they know. The targets don't cooperate with that:
- SYN flood: cleanest way to test SYN backlog and kernel tuning on a raw TCP service.
- UDP random flood: stresses connection tracking and any stateful firewall in the path.
- ACK/PSH floods: consume memory in stateful inspection devices — useful against targets hiding behind expensive firewalls.
- HTTPS flood: the real CPU killer; TLS handshake cost lands on the target, not you.
- DNS amplification: tests ingress filtering and whether upstream links drown before the service does.
A game server on raw UDP, a website behind a CDN, and an API behind a WAF have completely different weak points. Matching the method to the stack is the difference between a real capacity number and a wasted run.
4. Watch the Metrics That Matter
During the run, four numbers tell you almost everything:
- P95/P99 latency, not average — averages hide the tail that users actually experience.
- Error rate by type — connection timeouts mean network path; 502/503 means origin or proxy layer; 429 means rate limiting engaged.
- Concurrent connection count on the target — if it plateaus below your sending concurrency, something in the path is shedding load early.
- Time from stop to recovery — how fast the target returns to baseline is a resilience metric nobody tests and everybody needs.
5. One Variable at a Time
Change duration, not method and concurrency and duration together. If a run fails to degrade the target, change exactly one thing. Otherwise the "successful" degradation you eventually cause teaches you nothing about which knob actually mattered.
6. Read the Recovery, Not Just the Crash
The most overlooked phase is the 60 seconds after you stop. A target that recovers in seconds has headroom and clean resource release. A target that stays degraded for minutes after traffic stops has a leak — worker processes stuck, connection pools not releasing, caches stampeding on recovery. The second target is the fragile one, regardless of how much traffic it survived.
7. Log Everything
Timestamps, method, target, duration, observed effect, recovery time. After a few weeks you have a private dataset of what works against what kind of infrastructure — which is worth more than any tool's marketing page.
Where This Checklist Came From
Most of these rules exist because I broke them first. The complete walkthrough — with method-to-target matching tables, parameter tuning ranges, and how to read a full test report — is documented in the guide below.
If you run infrastructure that matters to someone, test it before someone else does it for free, without your permission, and without a report at the end.
Top comments (0)