If your website has suddenly gone slow or offline and you suspect a distributed denial-of-service attack, you need two things: to confirm it quickly, and to get traffic filtered upstream of your server. This guide walks through both, in the order you should actually do them under pressure.
First, Confirm It Really Is a DDoS
Not every outage is an attack. Before you act, rule out the ordinary causes so you don't waste the crucial first minutes. A genuine DDoS usually shows a sharp, sustained spike in requests or bandwidth from many different IP addresses at once, with your CPU, connection count or bandwidth pinned while your application logs fill with traffic you didn't expect.
- Check server load: is CPU, RAM or the connection table saturated, or is the box idle (which points to a network-level flood instead)?
- Look at access logs: a flood of requests to one path, or from many IPs with an odd or identical user agent, is a strong signal.
- Rule out the boring causes first: a bad deploy, an expired certificate, a database that fell over, or a legitimate traffic surge from a launch or a news mention.
- Watch bandwidth: if your uplink is saturated but the server is idle, the attack is volumetric (L3/L4) and must be filtered before it reaches you.
The hard truth about server-side fixes
Once an attack saturates your uplink, nothing you type on the server helps — the malicious packets already crossed the wire you're paying for. Real DDoS defence has to happen upstream of your origin, not on it.
The First Ten Minutes
If you've confirmed an attack, your goal is to move traffic filtering off your server and in front of it. In order:
- Enable any DDoS protection your host or CDN already offers — many have an 'under attack' mode that turns on browser challenges immediately.
- If you have a reverse-proxy protection service, raise its protection level and turn on a JavaScript or challenge mode so automated clients are filtered out.
- Rate-limit aggressively at the edge, not the origin: cap requests per IP and per ASN so a single source can't monopolise you.
- Do not simply block by hand in iptables during a large flood — the packets still arrive and your firewall burns CPU deciding to drop each one.
Blunt the Attack
With traffic flowing through a proxy, you can shape it. Application-layer (Layer 7) floods are slowed by challenges that a real browser clears automatically but a simple bot cannot. Volumetric floods are dropped by the upstream network before they reach your pipe. Geographic and ASN filtering helps when the attack clearly originates from networks you don't serve — but use it carefully, because it can also block real users.
Hide Your Origin So It Can't Happen Again
The most common way a proxy is bypassed is a leaked origin IP. Once you move behind any protective edge, rotate your server's IP address and make sure the old one isn't still discoverable through email headers, historical DNS records, or a subdomain that points straight at the box. If attackers can find your real address, they route around the proxy entirely.
Put Protection in Place Before the Next One
The best time to set up DDoS protection is before an attack; the second best is right now, while you remember how it felt. Routing your domain through a reverse-proxy edge via a DNS change means the next flood is filtered automatically — and with automatic mitigation, protection can escalate on its own the moment an attack is detected, then relax when it's over. Akarguard does exactly this, and every attack produces an alert and a PDF report so you know what hit you.