Quick answer
If an attack is happening right now, the fastest route back online is to get your traffic behind a network that can absorb it — for a website that means moving DNS to a reverse proxy, and for anything else it means routed transit. Before that helps you have to confirm it is actually an attack rather than a traffic spike or an outage, and you have to make sure your origin address cannot be reached directly, or the attacker will simply bypass whatever you put in front of it. Blocking individual addresses and rebooting the server are the two most common reactions and neither works against a distributed attack.
First: confirm it is an attack
Several things look identical from the outside — a genuine traffic spike, an application fault, an upstream network problem and an attack all present as "the site is down". Acting on the wrong one wastes the time that matters most.
| What you see | Likely cause |
|---|---|
| Traffic normal, connections timing out | Protocol attack (SYN flood) or connection exhaustion |
| Bandwidth saturated, server idle | Volumetric flood — it never reaches your application |
| Server CPU pinned, request rate moderate | Application-layer attack hitting something expensive |
| Traffic normal, errors in one feature | Almost certainly a bug, not an attack |
| Traffic high from real referrers | You are being linked somewhere — a spike, not an attack |
While it is happening
The order matters. Getting protection in place is useless if the attacker can still reach the address behind it.
- Get behind a network with capacity — for HTTP, point DNS at a reverse proxy; for anything else, arrange routed or tunnelled transit
- Lower your DNS TTL first if you can, so the change propagates in minutes rather than hours
- Firewall the origin to accept traffic only from your provider's ranges, or the attack simply continues around your new protection
- Turn on the strictest protection mode you have while you stabilise, then relax it
- Cache aggressively — anything served from cache never touches your origin
- Tell your host: they see the traffic before you do and may already be null-routing you
What not to do
These are the reactions people reach for first, and each one costs time without helping.
| Reaction | Why it fails |
|---|---|
| Blocking attacking IPs | Thousands of sources, rotating constantly; in reflection attacks they are innocent third parties |
| Rebooting the server | It comes back up into the same flood, having lost whatever was still working |
| Blocking a whole country | Attacks are global; you mostly block customers |
| Turning off the site | That is the attacker's goal, achieved manually |
| Scaling up the server | Volumetric attacks saturate the link, which more CPU does not widen |
| Paying a ransom | Marks you as a target that pays, and rarely ends it |
Afterwards, before the next one
Attacks recur, frequently against the same target and often shortly after. The window right after one ends is the only time you will have both the motivation and the calm to prepare properly.
- Keep protection always-on rather than switching it on when something breaks — the first minutes are the expensive ones
- Audit every DNS record for anything still pointing at the origin, including subdomains you forgot
- Check certificate transparency logs for certificates issued directly to your origin hostname
- Move mail off the web server, or its headers publish the address you just hid
- Write down what the traffic looked like: source spread, request pattern, which endpoints were targeted
- Set alerts on your own baseline, not on fixed thresholds
Match the defence to the layer
A single answer does not cover every attack type, and buying the wrong one is a common and expensive mistake.
| Attack | What actually stops it |
|---|---|
| Volumetric flood | Upstream capacity — absorbed before your uplink |
| SYN / protocol flood | Kernel-level filtering at the edge, SYN cookies |
| HTTP flood | Request inspection and challenges, not packet filtering |
| Slow attacks | Connection timeouts and limits at the proxy |
| UDP flood on a game server | Routed transit with real UDP filtering, not null-routing |
Frequently asked questions
Last updated