How to test your DDoS protection.

A defense nobody has tested is a hypothesis

DDoS protection gets bought the way smoke alarms get bought: you install it, a light blinks, and you assume the rest. The difference is that a smoke alarm has a test button. Most mitigation setups get their first honest test from the attack itself, at whatever hour the attacker picked.

And when protection fails in practice, it is almost never because the network could not absorb the volume. It fails on configuration that looked perfectly correct on the day it was made:

• The origin IP still answers directly, so the flood walks around the edge entirely.
• One hostname — staging, mail, api-v1 — was never moved, and it resolves straight to the same server.
• A rate limit sits at a number nobody ever compared against real traffic, and the first thing it throttles is your own mobile app.
• Filtering is on-demand, and the person allowed to switch it on is asleep.
• The attack is mitigated correctly, and afterwards there is nothing to show a customer, an insurer or your own board.

Not one of those is a capacity problem, and every one of them is findable on a quiet Tuesday afternoon.

Rule one: never rent an attack to test a defense

Search for a way to test DDoS protection and the first results will be services selling attack traffic by the minute, marketed as "IP stressers" or "load testers for your own server". Do not use them, for three reasons in ascending order of how much they should matter to you.

1. It is a crime, and the "my own server" defense does not hold. Unauthorized impairment of computer systems is an offense under the UK Computer Misuse Act, the US Computer Fraud and Abuse Act and equivalent law across the EU. Even when the target is yours, the traffic crosses networks that are not, is generated from machines whose owners never consented, and terminates on infrastructure your hosting contract says you may not attack. Law-enforcement takedowns of these services routinely publish their customer databases; being in one is a bad afternoon.
2. You are paying the people attacking everyone else. These services run on compromised routers, cameras and servers. Your test fee funds the botnet that shows up in someone else’s incident review — possibly, later, in yours.
3. It answers a question you did not ask. What you buy is raw volume, and volume is the part your provider is best at and you have least control over. It tells you nothing about whether your rate limits are keyed correctly, whether your API clients survive a closed gate, or whether your origin is still exposed. The attacks that actually take sites down are application-layer attacks, and those are not what a booter sells.

Everything worth learning can be learned from targeted functional checks against your own infrastructure, plus authorized load testing you run yourself. That is the rest of this page.

What you are actually testing

Your protection makes six promises. Test them separately, because they fail separately.

Test 1 — Is your origin still reachable without the edge?

This is the test that finds something. An exposed origin makes every other defense optional for the attacker: they aim at the IP address and your filtering never sees the packets.

From a network that is not your office or your CI runner, resolve nothing and ask the server directly — curl -sI --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com — and see what comes back. A page means the door is open. Repeat on port 80, and on any admin or application port your stack exposes.

Then close it: restrict the origin firewall to your provider’s edge ranges, so anything else is dropped rather than answered. And note what a correct result looks like when you re-test — a timeout, not a 403. A refusal proves the packet arrived, which means an attacker can still make your server spend resources deciding to say no.

Finding the address is the other half of this exercise, and attackers have more routes to it than direct DNS: historical DNS records, certificate transparency logs, mail headers, and error pages that leak an internal hostname. The full sweep is in how to hide your origin IP address — run it as part of this test, not instead of it.

Test 2 — Is every hostname actually behind the edge?

Protection applies to the names you pointed at it, and to no others. Take an inventory of every A, AAAA and CNAME record in every zone you own, including the ones inherited from a previous team, and sort each into one of two columns: behind the edge, or not.

The ones that are usually in the wrong column: staging, dev, old, legacy, vpn, direct, origin, cpanel, regional variants, and the marketing microsite somebody set up for a campaign in 2023. Anything that resolves to the origin address is a published bypass, and an attacker enumerating your DNS will find it in seconds.

While you are there, confirm the edge is doing more than forwarding. Request a static asset twice and check the cache header on the second response: a MISS every time means your origin is still serving every byte, and under load it will fall over exactly as fast as it would have without a CDN in front of it. Cacheable traffic served from the edge is not a performance nicety — it is capacity you get to keep during an attack.

Test 3 — Do your rate limits fire, and do they answer in a language your clients speak?

Rate limits are the most commonly misconfigured control in the stack, and their failure modes point in both directions: a limit set too high never triggers, and a limit keyed to a shared IP address throttles an entire office, mobile carrier or university behind one NAT.

Run a modest, controlled burst — a few hundred requests over a minute from a single source, which is well inside what your origin serves on a normal day — against a canary path you created for the purpose. Not your login endpoint, and not from the office IP you need to keep working. Then check four things:

• It trips where you think it does. If the documented limit is 100 requests a minute and nothing happens at 400, the rule is not doing what the dashboard says.
• The response is a 429 with Retry-After. Not an HTML challenge page, not a 302, not a 200 carrying an error in the body. A machine client that cannot parse the refusal retries harder and joins the flood — the whole argument in how to protect an API from DDoS attacks.
• The key is the one you intended. Per-credential for authenticated routes, per-IP only where there is nothing better. Verify by hitting the same limit from two different accounts on one connection, and from one account on two connections.
• It recovers. The limit should release on schedule, not hold a client out for an hour because a counter never decayed.

Test 4 — What does a real client experience when the gate closes?

Every mitigation posture that tightens against attackers also tightens against somebody legitimate. You want to know who, before an attack decides it for you.

Pick a low-traffic window, deliberately switch your protection into its strictest posture for a few minutes, and walk your own funnel: home page, search, login, checkout — on desktop, on a mobile browser, and in your own mobile app. Then the clients that have no browser at all: API integrations, payment callbacks, webhook senders, your uptime monitor, your status-page checker, and the search-engine crawlers you care about ranking in.

What this test catches, reliably: challenge loops on cookie-less clients, webhooks from a payment provider silently failing, and monitoring that starts paging because your defense classified it as a bot. Write down everything that breaks, fix it with an explicit allowlist or an API-path exemption now, and keep the list — during a real attack nobody is going to be reading documentation.

Test 5 — Can you prove afterwards what happened?

Mitigation that works and leaves no record still costs you. The bill for an incident arrives days later in customer questions, an insurer’s evidence request and a post-incident review, and all three want specifics — see how much a DDoS attack costs for the rest of that invoice.

So test it: take the window you caused in test 3 and reconstruct it from your dashboard alone. How many requests, from which networks, against which paths, which rule fired, and what status did the client receive? If that answer takes more than a few minutes, or requires SSH into a box, your evidence story is an archaeology project rather than a record — and an archaeology project is not something you can hand to a customer on the same day.

Two things worth confirming in the same pass. Does your provider retain per-request detail, or only aggregate graphs that can show you a spike but never who was in it? And is blocked traffic metered against your bandwidth quota — because a defense that turns an attack into an invoice has quietly moved the cost rather than removed it.

Test 6 — The runbook, and the people in it

Time to mitigation is a human number at least as often as a technical one, and no tool measures it. Book twenty minutes, put the keyboards away, and answer these out loud:

• Who notices? Which alert, to which channel, and who is carrying the phone at 02:00 on a Sunday.
• Who is allowed to change posture? Do they have working credentials on a device they carry, or is the password in a manager that lives behind the site that is currently down?
• What do customers hear, and where? Somebody has to write it, and it has to be publishable somewhere that does not share an origin with the thing that is offline.
• What do we explicitly not do? Worth agreeing in advance: no paying a ransom demand, no geo-blocking a market you sell to because a graph looked alarming at 03:00.
• Who declares it over, on what evidence? Attacks arrive in waves, and the second wave usually lands on a team that already stood down.

Write the answers on one page and put it where it can be reached from a phone. If your protection is on-demand rather than always-on, this exercise is your defense — every minute between "attack starts" and "somebody logs in" is billed at your full hourly downtime rate. The case for always-on filtering is in what is DDoS mitigation, and it is mostly this.

Load testing is useful — it is just not an attack test

Authorized load testing against your own stack is worth doing. Be clear about what it measures: your origin’s capacity, where saturation begins, whether autoscaling reacts in time, and which endpoint gives way first. What it cannot measure is whether your edge can tell an attacker from a customer, because your load generator is a well-behaved client sending honest requests from one place.

Ground rules, if you run one:

• Test against staging built to mirror production, or a production window you have announced internally.
• Tell your hosting provider and your mitigation provider first — both have acceptable-use terms about generated load, and one of them may otherwise mitigate you.
• Ramp gradually, watch origin metrics rather than the client’s success count, and have a documented abort.
• Never point a generator at infrastructure you do not own, including a provider’s edge. Measuring a CDN’s capacity from one machine only measures how quickly your own account gets throttled.

Put it on a calendar

The failure mode this schedule exists to prevent is not neglect. It is a migration: a server rebuild, a new subdomain, a firewall rule relaxed for a deploy and never restored. Configuration drifts back toward exposed, quietly, and a defense verified once is a defense verified for infrastructure you no longer run.

How Itnetic makes this testable

Several of these tests are harder than they need to be because the platform underneath was never built to be inspected. Ours was.

There is no human step to test. Filtering on Itnetic is always-on rather than something you enable mid-incident, so test 6 collapses to communications and access — there is no switch to fail to flip, and no ticket queue between an attack starting and filtering starting.

Test 5 is an export, not an excavation. Per-request logs carry the method, path, status, latency, TLS details, client fingerprint and the exact WAF rule and verdict behind every decision, with a copyable request ID. The attack timeline splits traffic into allowed, challenged and blocked second by second and marks the moment automatic under-attack mode triggered — which is precisely the "did mitigation engage, and when" evidence a post-incident review asks for.

Test 3 passes by construction on machine paths. Mark a prefix such as /api/ as an API zone and matching requests are never challenged and never redirected: rate-limited clients get a 429 with Retry-After, keyed per credential rather than per shared IP.

You can test rules before they bite. Custom WAF rules run in log-only mode against live traffic, so you can see exactly which real requests a rule would have caught before you let it block anything.

Testing does not generate an invoice. Attack traffic is scrubbed and never metered against your bandwidth quota — see pricing — so neither a test nor a real attack turns into a bandwidth bill. Real-time alerts to Discord answer the "who notices" question in test 6, and the Starter plan is free, so you can run every check on this page against a real domain at no cost. Going live is two DNS records and about five minutes.

Work through the six tests and one of two things happens. Either they find nothing, and you have spent an afternoon converting an assumption into a fact. Or they find something — and on a first pass, they usually find the origin still answering — and you found it at an hour you chose, rather than at the one an attacker picks for you.

Under attack while reading this? Stop testing and start mitigating: how to stop a DDoS attack.