How to tell if your site is under a DDoS attack: 8 signs to check

A slow site isn't necessarily under attack. It could be a badly updated plugin, a backup running at the wrong time, an overloaded host or, luckily, an article that is doing really well. Finding the right cause saves you from wasting time on the wrong fix.

What a DDoS attack is, briefly

DDoS stands for Distributed Denial of Service: many devices, often infected computers and cameras controlled remotely, send requests to your site all at once, until the server or the connection can't cope.

Attacks fall roughly into three families:

• volumetric: they fill the bandwidth with huge amounts of traffic, often "amplified" by abusing misconfigured servers on the Internet;
• protocol: they open millions of half-finished connections (the classic SYN flood) to exhaust the resources of the server or the firewall;
• application (or layer 7): they look like normal visits, but they are thousands of requests to heavy pages such as search or login. They are the most common against websites and online shops, and the hardest to tell apart from real traffic.

The 8 signs

1. 502, 503 or 504 errors

Visitors see "Bad Gateway", "Service Unavailable" or "Gateway Timeout". It means the web server is up, but the application behind it (PHP, Node, the database) can't answer in time. It's the most common symptom of an application attack, but also of a site that is simply overloaded.

2. CPU or memory at 100% for no reason

If your hosting panel shows the processor maxed out at a time when the site is usually quiet, and no backup or import is running, something is asking for much more work than usual.

3. Many requests from the same addresses

In the server logs, a few lines repeating the same IP tens of thousands of times is a red flag. A real visitor opens a few pages a minute, not a hundred a second.

4. Always the same page

Application attacks almost always target the pages that are most expensive for the server:

• /wp-login.php and /xmlrpc.php on WordPress;
• the site search (?s=, /search?q=), which queries the database on every request;
• the cart and checkout of online shops;
• pages with ever-changing parameters (/?a=38291, /?a=48122…), to get around the cache.

5. Strange or identical user agents

Every browser introduces itself with a "user agent". In an attack you often see empty user agents, automated tools (python-requests, Go-http-client, curl) or the very same browser repeated thousands of times from different IPs.

6. Traffic from countries where you have no customers

A shop that only sells domestically and suddenly gets half its visits from faraway countries has good reason to be suspicious.

7. No images, no CSS

A real visitor opening a page also downloads images, stylesheets and scripts. Many bots only request the HTML page, thousands of times. You can see it in the logs because the requests for the files that go with every page are missing.

8. Your host emails you or suspends the site

In the largest attacks it's the hosting provider that notices first: it sees its network saturated and sometimes "unplugs" your site to protect other customers. If you get an email like that, the attack is at network level, and there's little you can do on the server alone.

Attack, slow hosting or too much success?

How to check the logs in two minutes

If you have access to the server, these two commands already tell you a lot. Who makes the most requests:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Which pages are requested the most:

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

If you have no access to the logs, your hosting panel usually has a statistics or "access" section. Behind 1PrimeCDN everything is in the panel: requests by country, stopped IPs and the reason for every block, on the Security page.

What to do if it's an attack

If the signs match, don't wait for it to pass: attacks can last minutes or days, and often come back. You'll find the steps in order in website under DDoS attack: what to do right now, or you can write to us from the emergency page.

And if you realise it's not an attack but a site that can't handle the traffic, the fix is caching: see slow website? Time to first byte and caching.