How to Tell If Your Site Is Under a DDoS Attack (Three-Axis Diagnosis)

Traffic suddenly spikes, pages spin, APIs time out — these symptoms could be a successful promotion or a DDoS. The difference matters, because it decides whether you spend the wrong budget: treat an attack as a scaling problem and the bandwidth you buy gets blown through in a second; treat a peak as an attack and you block real users and hurt conversion. Here is a practical three-axis diagnosis.

Axis 1: Where does the traffic come from — source dispersion

This is the fastest cut.

• Normal traffic: concentrated in your real user base — same regions, same networks (ASNs), same active hours. Pull your connection table or flow data and the IP distribution is "familiar faces."
• DDoS traffic: comes from thousands of unfamiliar netblocks, often across many countries and odd ASNs. A few IPs hitting you at high frequency is more likely a scraper or single-abuser, not a distributed attack.

Intuition check: if "request volume spikes" and source-IP dispersion spikes together, that is almost certainly not humans.

Axis 2: What does the traffic look like — protocol and packet signature

Normal business traffic is mostly HTTP/HTTPS with a smooth protocol mix. Watch for these shapes:

• Heavy UDP / ICMP: you are a web service yet drowning in UDP or ICMP — classic volumetric or reflection/amplification (open services like NTP, DNS, SSDP, Memcached abused to multiply traffic 50x or more).
• SYN / ACK imbalance: bandwidth is not full, but SYN_RECV piles up and the connection table is exhausted — protocol attack; firewalls and load balancers fall first.
• Requests that "look perfectly normal": all valid GET/POST, yet hammering one expensive endpoint (search, login, captcha) — application-layer CC, nearly invisible from traffic shape alone, caught only through cost anomalies and behavior rules.

Axis 3: What did it do to the business — correlation

This axis decides how worried you should be. Compare against this table:

The key: if "request surge" is accompanied by rising errors + dispersed sources + falling conversion ratio, it is an attack, not a peak.

Three attack classes, how to tell them apart

• Volumetric: bandwidth saturated, egress near its ceiling. UDP / reflection amplification; a single egress simply cannot absorb it — the most visible, and the most brutal.
• Protocol: bandwidth may be fine, but connection/session tables or firewall state are exhausted by SYN / ACK floods. The server "is not offline yet completely unresponsive" is usually this one.
• Application-layer (CC): traffic looks normal but relentlessly burns database, login, or search. Hardest to spot at a glance because every request is legitimate — only "cost anomalies" and behavior rules catch it.

60-second confirmation checklist

1. Do you see "dispersed sources + rising errors + saturated bandwidth or connections" all at once?
2. At the same moment, are normal users fully unable to reach you (not just slow)?
3. After limiting a single IP's rate, does overall pressure drop noticeably? (If yes, it is likely single-abuse; if no, likely distributed.)
4. Does the protocol mix show heavy UDP / SYN that does not match your business type?

If the first three hit, you can basically call it a DDoS or CC attack. Once confirmed, move to What to Do When Your Site Is Under a DDoS Attack (15-Minute Response Plan).

Why confirm "one minute earlier"

Confirm one minute earlier, onboard scrubbing one minute earlier, lose one minute less. Many teams stall in "is my code broken?" debugging and only realize it is an attack half an hour later — and that half hour of orders and players does not come back. If you are still evaluating protection, see Free or DIY DDoS Protection vs Professional, or contact us for a free preliminary assessment.