DDoS or Traffic Spike? How to Tell Them Apart Fast

A product gets mentioned on a big podcast, a forum thread goes wide, a newsletter lands in 200,000 inboxes. Graphs that usually idle at a few dozen requests per second suddenly show a few thousand. The same graphs look identical during an attack. Picking the wrong explanation hurts either way: challenge real buyers and you throw away your best evening of the year, wave through a flood and the site stays down while you celebrate.

DDoS or traffic spike: eight signals that separate them

No single signal settles it. When five or more line up on the same side, you have your answer.

Session behaviour is the one I trust most because simple bots rarely bother faking it. A browser loading a page pulls dozens of assets. A basic flood script requests the same URL over and over and ignores everything it links to.

Sudden traffic spike on a website: a ten-minute log check

With nginx and the default combined log format you can pull most of the table straight from the access log. Start with referrers over the last 50,000 requests:

tail -n 50000 /var/log/nginx/access.log | awk -F'"' '{print $4}' | sort | uniq -c | sort -rn | head -15

If the top entries are a news domain, t.co, a forum, or your email provider’s click tracker, you are almost done. If - (no referrer) sits on top with nine out of ten requests, keep digging.

Next, compare documents to static assets:

tail -n 50000 /var/log/nginx/access.log | awk '{print $7}' | grep -cE '\.(css|js|png|jpg|webp|woff2)'
tail -n 50000 /var/log/nginx/access.log | wc -l

With real visitors, assets make up a large share of hits unless a CDN already serves them, in which case do the comparison in the CDN’s analytics instead. A share close to zero means clients only want pages.

Then count query strings:

tail -n 50000 /var/log/nginx/access.log | awk '{print $7}' | grep -c '?'

Thousands of unique, random-looking parameters on the home page are a classic cache-busting pattern. More commands are in the guide on how to detect a DDoS attack.

Bot traffic detection: fake crawlers

Requests whose user agent claims to be Googlebot or Bingbot deserve one extra check. Real search engine crawlers pass a round-trip DNS test: reverse-resolve the IP, then forward-resolve the name you got and compare.

host 66.249.66.1
host crawl-66-249-66-1.googlebot.com

If the name ends in googlebot.com or google.com and resolves back to the same address, it is Google. If not, someone borrowed the label. Cloudflare exposes a “Verified Bot” field in its rule builder that already does this for known crawlers.

When the website is overloaded by real visitors

If the verdict is “real audience”, the playbook is about capacity, not filtering:

• Cache whole pages for anonymous visitors. This takes the most weight off PHP, Node or the database.
• Trim expensive features for an hour. Faceted search, live stock checks and recommendation widgets can wait.
• Serve static assets from the CDN only. Images and scripts should never reach the origin.
• Prefer a waiting room to an error page. A queue keeps people; a 503 sends them away.

Most of these also help during an attack, which is why I start there when the evidence is mixed. Sensible rate limiting on login and search is worth having in both scenarios.

When it turns out to be an attack

If the signals point at bots, switch to the DDoS attack response plan: call your provider, tighten edge rules, preserve evidence. To work out what kind of flood you are facing, the overview of types of DDoS attacks helps.

Mixed cases happen too. A post goes viral, and someone decides the newly busy site is a nice target. Then you run both playbooks at once, caching for the humans and filtering for the bots.

Know your baseline before the next spike

The whole decision gets easier when you know what normal looks like. Write down requests per second, bandwidth and the share of your top ten ASNs on an ordinary day and on your best campaign day. With those numbers the call takes minutes instead of an hour of arguing in a chat channel.

DNS is part of that preparation. If you can change records quickly, putting a CDN in front of the site during an emergency is a five-minute job. betadomain gives you direct name server management for your domains, a .com registration with DNSSEC support, and the same renewal price every year, listed on the domain price list. Your next step: run the three log commands above on a quiet day and save the output as your baseline.