Your CDN dashboard says "attack mitigated". Your origin server says otherwise. One of them is lying, and finding out which one — before a real attacker does — is the entire point of testing your own DDoS protection.
Most teams never do this. They buy a plan, see green checkmarks on a status page, and assume the problem is solved. Then a bad day arrives, the site goes down for six hours, and the post-mortem discovers the mitigation was never actually covering the origin in the first place.
Here is a practical, ordered way to verify your own defenses. Every step assumes you are testing infrastructure you own or are authorized to test.
Step 1: Measure your baseline before anything else
You cannot detect degradation without a normal to compare against. Before sending a single test packet, record:
- Response time (p50 and p99) from at least two geographic vantage points
- Error rate by type (timeouts vs 5xx vs 429)
- Origin server CPU, memory, and connection counts
- Time-to-first-byte through your full CDN/proxy chain
This takes twenty minutes and gives you the "before" picture that makes every later step meaningful.
Step 2: Find out if your origin is actually hidden
The single most common failure: a CDN or scrubbing proxy in front, but the origin IP leaked months ago through a DNS history, a forgotten subdomain, an email header, or an SSL certificate log. If the origin IP is public, attackers skip your entire protection layer and hit the server directly.
Test it: search certificate transparency logs and passive DNS archives for your domain. If any historical record exposes an IP that still responds on ports 80/443, your CDN is decorative — anyone can route around it.
Step 3: Test Layer 4 first, in isolation
Start with volumetric pressure against the protected edge — SYN floods, UDP random traffic, and stateful TCP connection floods. The goal is not to knock yourself offline; it is to watch three specific things:
- Does the scrubbing layer engage, and after how many seconds?
- Does legitimate traffic still get through during mitigation? (Test from a clean IP while the pressure runs.)
- Does your origin see any of the traffic, or does the edge absorb everything?
If your origin logs show inbound packets during this phase, your protection has a routing hole.
Step 4: Test Layer 7 with realistic requests
This is where most protections quietly fail. Launch HTTP/HTTPS load that mimics real browsers — correct TLS fingerprint (JA3/JA4), proper HTTP/2 frame behavior, randomized headers — not the crude scripted traffic that WAFs eat for breakfast.
Watch specifically for:
- JS challenge handling: does traffic without JavaScript execution get filtered? (It should be.) Does traffic with valid challenge responses get through? (It also should — and this is where naive test tools report false failures.)
- Rate limiting behavior: at what request rate do 429s start? Is that threshold above your legitimate peak traffic with headroom?
- Cache hit ratio under load: some CDNs absorb static content perfectly but collapse when dynamic endpoints are hit. Test both.
Step 5: The metric nobody tests — recovery time
Stop the pressure. Time how long until every metric returns to baseline. A target that survives an attack but takes eleven minutes to recover has a worker leak, connection pool exhaustion, or cache stampede on recovery — all fixable, all invisible until tested.
Step 6: Read the results honestly
Three outcomes, three actions:
- Edge held, origin clean, recovery fast — your protection works. Document the capacity ceiling you verified and schedule re-tests quarterly.
- Edge held, but origin saw traffic — routing leak. Lock down origin firewall rules to accept only CDN ranges.
- Everything degraded — you just received advance notice of your next outage. Fix it now, on your schedule, not theirs.
The uncomfortable summary
DDoS protection you have not tested is a subscription, not a defense. The verification loop — baseline, expose leaks, L4, L7, recovery — takes an afternoon with the right tooling, and it converts "we have Cloudflare" from a hope into a measured fact.
Top comments (0)