Signs of a DDoS Attack

The clearest signs of a DDoS attack are a request count that multiplies within seconds instead of minutes, pages that stall or fail while your server CPU sits nearly idle, a run of 503 and 504 errors, connection tables filling with sessions that never complete, and traffic crowding onto one endpoint or one network you have never served before. Any single symptom has a boring explanation. Together they only point one way. This guide covers the network and application signals worth checking, how to separate an attack from a genuine surge in visitors, and what to do first. Spotting the flood is rarely the hard part. Proving what you are looking at is.

Key Takeaways

• A DDoS attack normally arrives as a vertical jump in traffic, while real demand ramps up over minutes or hours.
• Slow pages with flat CPU usually mean bandwidth or connection exhaustion rather than heavy application load.
• A layer 7 flood can exhaust a server at a few Mbps, so quiet bandwidth graphs never rule out an attack.
• Cloudflare mitigated 23.2 million network-layer attacks in the first half of the year, roughly 128,000 a day.
• Legitimate spikes carry sessions, referrers, and conversions, while attack traffic repeats a single request shape.
• Connection state counts, error ratios, and source network spread confirm an attack faster than a bandwidth chart.
• Because 90.60% of network-layer attacks end within ten minutes, filtering has to be automatic to matter.

What a DDoS Attack Looks Like From Inside Your Own Stack

A DDoS attack shows itself as a sudden wall of requests, stalled or failing pages, connection tables packed with incomplete sessions, and traffic concentrated on one endpoint or one unfamiliar network. The pattern carries the signal, not any one symptom on its own.

Every symptom in that list has an innocent twin. A cache purge sends live traffic to the origin. A bad deploy pushes error rates up. A newsletter drop triples visitors for twenty minutes. What separates an attack is that several of these appear at once, arrive faster than any campaign could deliver, and refuse to settle.

Scale explains why this happens so often. Cloudflare mitigated 23.2 million network-layer attacks in the first six months of the year, about 5,343 every hour. The company also notes that roughly 100 Mbps of hostile traffic is enough to overwhelm a single server or website, which puts the average attack well within reach of anyone renting capacity for the price of a takeaway meal.

The table below maps the symptom you notice to the failure underneath it. Read it once now, before you need it, because pattern recognition under pressure is worth more than any tool. If you are still weighing whether the traffic came from one machine or thousands, how a DoS attack differs from a DDoS attack is the distinction that decides your response.

Knowing the symptom is only half the job. Sites sitting behind always-on DDoS protection watch most of this list flatten before the origin ever feels it, which is why two teams can face the same flood and only one of them opens an incident. The same attack also leaves a completely different evidence trail depending on which layer the attacker chose.

How the Symptoms Change With the Type of Attack

Volumetric attacks saturate bandwidth, protocol attacks exhaust connection state, and application attacks burn backend capacity. Each one leaves a different fingerprint on your monitoring.

A volumetric flood fails upstream of you. Packets drop at the uplink before they ever reach your web server, so the machine looks healthy while nobody can load the site. Protocol attacks reach the host but never finish the handshake, filling the connection table until legitimate sessions are refused. Application attacks look most like real users, because they are real requests, just far too many of them aimed at the most expensive path you expose.

Vector choice keeps moving. DNS-based attacks accounted for 34.3% of network-layer activity in the first half of the year, and CLDAP floods grew by 580% quarter over quarter to become the third most common vector. Both are reflection techniques, which means the traffic hitting you comes from misconfigured third-party servers rather than the attacker’s own machines. Multi-vector campaigns mix all three categories on purpose, so that a defence tuned for bandwidth misses the request flood arriving alongside it, and botnet-driven floods make that mix cheap to assemble. Some campaigns go further and spread that flood across an entire IP range instead of one host, a carpet bombing DDoS attack that keeps every per-host counter looking normal while the shared uplink saturates.

Yes, terabit attacks dominate the headlines, but they are not the ones that take most sites down. In the same reporting period, 96.62% of network-layer attacks stayed under 500 Mbps. The dangerous attack for an unprotected origin is not the record breaker. It is the ordinary one nobody planned for.

Network Signals That Confirm Something Is Wrong

Four network measurements settle most arguments quickly: packet rate against bandwidth, connection state counts, the protocol and port mix, and where the traffic enters your network.

Packet rate against bandwidth

Compare packets per second with bits per second. A normal web workload carries large packets, so both numbers rise together. When packet rate explodes while bandwidth stays modest, you are looking at tiny packets designed to exhaust router and firewall processing rather than fill a pipe. The reverse pattern, huge bandwidth from few packets, points at amplification.

Connection state counts

Count sockets by state. A healthy server shows mostly ESTABLISHED and TIME_WAIT entries. Thousands of SYN_RECV entries mean handshakes are being opened and abandoned, the signature of a SYN flood. This is exactly the pressure that SYN cookies were designed to relieve, and watching that counter is the fastest confirmation available on a Linux host.

Protocol and port mix

Traffic arriving on UDP ports you do not run is one of the least ambiguous indicators there is. Ports 53, 123, 389 and 11211 carry DNS, NTP, CLDAP and memcached responses. If reply traffic from those services is landing on your address and you never sent the queries, someone spoofed your IP to a pool of open reflectors.

Where the traffic enters

Check the source network spread. Normal traffic distributes across the consumer ISPs your customers use. Attack traffic clusters, either in a handful of hosting providers or across residential networks in regions with no business relationship to you. CISA also warns that your network can lose service without being the target at all, when the attack lands on your provider instead.

Network data tells you the traffic is hostile. It rarely tells you why your application fell over first, which is where most teams lose an hour.

Application Symptoms Teams Usually Blame on the Code

When a layer 7 flood lands, the first suspicion almost always falls on a recent deploy or a slow database query. The tell is that the slowdown correlates with request volume on one path, not with the change you shipped.

Look for worker pools saturated while CPU per request stays normal, database connection pools exhausted by identical queries, and a cache hit ratio that collapses because the requests carry random query strings designed to bypass the cache. Session depth is the giveaway: real visitors load a page and then pull images, fonts and scripts, while flood traffic requests the HTML alone and never comes back.

Slow attacks invert every assumption in that list. Instead of flooding you, they open connections and hold them open, sending headers or a request body one fragment at a time. Bandwidth stays near zero, request counts look reasonable, and the server still runs out of workers. The Slowloris attack built its reputation on exactly that gap between what your graphs measure and what your server is actually short of.

You might be thinking this describes an aggressive crawler rather than an attack, and sometimes it does. The separation is behaviour under pressure: a crawler backs off when it receives 429 or 503 responses, while attack traffic ignores them and keeps the same rate. That single test resolves the question in about a minute.

How to Tell a DDoS Attack From a Legitimate Traffic Spike

Legitimate traffic ramps, browses, and converts. Attack traffic appears at full volume, repeats one request shape, and produces no downstream activity at all.

The curve tells you most of it. Real demand builds over minutes as an email goes out, a post spreads, or a broadcast airs, and it decays on a similar slope. A flood switches on. The second signal is source composition: a genuine surge broadly follows your normal mix of networks and devices, while attack traffic introduces networks with no history in your logs.

“Denial-of-service attacks can be difficult to distinguish from common network activity.”

Both situations can take a site offline, so the diagnosis is not academic. A genuine surge needs capacity, caching and queueing. Hostile traffic needs filtering, and infrastructure built for sudden traffic spikes handles the first case without teaching you anything about the second.

How to Check Your Own Server for an Attack in Progress

Four commands and two log queries will tell you whether the traffic is hostile, where it comes from, and which endpoint it is aimed at.

Start at the transport layer. Group your sockets by state and count the source addresses behind them. A single address holding thousands of connections is a rate-limit problem. Thousands of addresses holding a handful each is a distributed one.

# Connections grouped by state

ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# Half-open handshakes, the SYN flood counter

ss -ant state syn-recv | wc -l

# Top 20 source addresses by connection count

ss -ntu | awk '{print $6}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Then read the access log. You are looking for three distributions: which addresses dominate, which status codes the server is returning, and whether one path absorbs the traffic. If the top path is your search page or login endpoint and the top user agent string is identical across thousands of addresses, the case is effectively closed.

# Busiest client addresses

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

# Status code distribution

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

# Most requested paths and user agents

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

awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

Address counting loses value once an attacker rotates through a million residential IP addresses, and the Aisuru and Kimwolf botnets are estimated to control between one and four million infected hosts between them. That is where client fingerprints earn their place: JA3 fingerprinting groups clients by how their TLS handshake is built, so a botnet using one toolkit collapses into a single identifiable signature no matter how many addresses it borrows.

Early Warning Signs Before the Main Flood Arrives

Most large attacks are rehearsed. Short bursts, endpoint probing, ransom messages, and unusual DNS query growth show up days before the campaign that takes you offline.

The rehearsal looks like a blip: thirty seconds of elevated traffic at three in the morning, then nothing. Teams close the alert as noise. What it usually means is that someone measured your capacity and now knows what it takes to exceed it. The same applies to sudden interest in your slowest endpoints, where a handful of requests to an unindexed search query is reconnaissance rather than a customer.

• Brief traffic bursts that stop before anyone investigates, often repeating at the same hour
• A jump in queries to your authoritative DNS servers with no matching rise in site traffic
• Extortion email demanding payment to avoid an attack, sometimes with a short demonstration
• Your own hosts scanning outbound, which suggests the infection is already inside
• An abuse notice from your hosting provider or ISP before you notice anything yourself

Cheap firepower makes this common. Operation PowerOFF, a 21-country law enforcement action, targeted over 75,000 users of DDoS-for-hire services and took down 53 domains, which tells you how large the market for a casual attack has become. Throttling probing traffic early is worth more than it looks, and rate limiting applied to expensive endpoints removes the cheapest reconnaissance path before the real campaign is planned.

Why Attack Speed Decides How You Should Respond

Attacks now finish faster than people can react. In the first half of the year, 90.60% of network-layer attacks Cloudflare mitigated ended within ten minutes, and record-breaking floods have been measured at 35 seconds from start to finish.

That changes what an alert means. By the time a monitoring system notices, escalates and reaches an engineer, the traffic has usually stopped. The alert is a post-mortem, not a trigger. Anything that depends on a human enabling protection during the attack is a plan that reliably arrives late.

The short duration also explains a symptom that confuses people: the site stays broken long after the flood ends. Cloudflare’s threat researchers point to routing instability, TCP retransmissions, and application timeouts that keep services degraded for hours after a burst of seconds. If your outage outlives the traffic, that is normal, and it is why upstream filters such as BGP FlowSpec rules are written before an incident rather than during one. The full data is published in Cloudflare’s DDoS threat report for the first half of the year.

What to Do in the First Fifteen Minutes

Your first quarter of an hour should produce a confirmed classification, a targeted filter, and a clean evidence trail, in that order.

1. Confirm from two vantage points. Compare edge traffic with origin traffic. If the edge is busy and the origin is idle, filtering is already working somewhere upstream.
2. Classify the layer. Bandwidth, packet rate, or request rate. The answer decides whether the fix belongs at the network edge, the transport layer, or the application.
3. Tighten the edge. Raise challenge levels, enforce stricter rules on the targeted path, and block the request signature rather than individual addresses.
4. Protect the expensive endpoint. Cap the path taking the load, then verify that real users on your normal networks still complete their journey.
5. Tell the people who need to know. Your hosting provider or upstream carrier may be absorbing the same traffic, and CISA’s guidance for defenders treats provider contact as a first response step.
6. Preserve the evidence. Export traffic samples, connection tables and access logs before rotation removes them, since the same attacker usually returns.

Null routing your own address is the option to keep for last. Dropping every packet to the target address ends collateral damage to neighbours, which is why carriers offer it, and it also completes the attacker’s objective. Read blackhole routing as a containment tool for the wider network, not as a defence for the service you are trying to keep online.

Final Thought on Spotting a DDoS Attack

Detection is a comparison, not an alarm. Every symptom on this page is meaningful only against a baseline you recorded when the site was healthy, which makes an hour spent documenting normal traffic the highest-value hour in your whole availability plan.

The second principle is proportion. Most attacks are small, brief and entirely survivable for infrastructure that filters automatically, and catastrophic for infrastructure that waits for a person to notice. Build detection so it teaches you something after the event, and build response so it never needs you in the first place. That balance, accurate visibility paired with automatic filtering, is what keeps a short flood from turning into a long outage.

Common Questions About DDoS Attack Signs