How to Determine If Your Server Is Under CC Attack or Busy
Your site slows to a crawl or drops offline, and you cannot tell whether you are losing to an attack or winning too much attention. Here is the direct answer: in a real traffic surge, bandwidth and QPS rise together. Under a CC attack, QPS spikes while bandwidth stays comparatively flat, because this application-layer traffic sends short, repeated layer 7 requests. Use this four-step diagnosis and response guide to determine whether a server is under a CC attack. You will learn to separate a genuine surge from a network-layer flood or a CC flood, then act correctly in each case.
Check Bandwidth And QPS In Monitoring
You can settle most of this question in one place: check bandwidth and QPS in monitoring, side by side, on the same time axis. The rule is simple. In a real user surge, bandwidth and QPS rise together. During a CC attack, QPS spikes while bandwidth stays comparatively flat. The reason is mechanical. A CC attack is an application-layer flood built from short, repeated HTTP requests. Each request is tiny, so it moves little data. The request count, however, climbs fast.
When Both Metrics Rise Together
Open your dashboard and align the two graphs. A genuine surge shows both lines climbing in step. Page views, downloads, and API calls all carry payload, so more users means more bytes on the wire. The evidence sits in your access logs: real page requests and download records that match your normal user paths. One caution applies here. False bandwidth fullness can appear when international link fluctuations trigger TCP retransmissions. The bandwidth graph spikes, yet much of that volume is duplicate data, not real traffic. Compare source regions against your usual user distribution before you conclude anything.
Normal business peaks and attacks can look alike at first glance. Campaigns, push notifications, or viral sharing raise QPS and CPU at the same time. Compare against your usual baseline. Check whether source regions match your user distribution, and whether the access path resembles real users — opening the page first, then requesting static resources and APIs — rather than repeatedly hitting only the same endpoint.
When QPS Spikes Alone
Divergence is the signature you want to catch. The table below shows how the two attack types separate when you read the graphs together.
Metric | Network-layer DDoS | CC attack (L7 HTTP Flood) |
|---|---|---|
Bandwidth (bps) | Rises sharply, often Gbps range | Changes little, typically a few Mbps to hundreds of Mbps |
Packet volume (pps) | Rises sharply | Not the primary indicator |
Layer 7 QPS | May not change significantly, or even drop | Abnormal spike |
Concurrent connections / new HTTP req/s | Not the primary indicator | Abnormal spike |
SSH login | Often fails or lags | Generally logs in normally |
Access logs | Quiet | Grow wildly in a short time |
For a CC attack, total bandwidth stays relatively flat while layer 7 QPS, concurrent connections, and new HTTP requests per second spike abnormally. For a network-layer flood, bandwidth and packets per second jump sharply while layer 7 QPS may stay flat or drop as handshakes fail. That contrast is your fastest first check. Ask whether bandwidth and packet volume have spiked together, or whether request rate moved alone.
Three supporting signs confirm the second pattern:
CPU pinned for extended periods while bandwidth stays unremarkable
Requests concentrated on a handful of expensive URLs
Access logs showing highly regular intervals from the same batch of IPs
When these appear alongside a QPS spike and a flat bandwidth line, treat the traffic as hostile until proven otherwise. This is how you determine whether a server is under a CC attack without guesswork.
Is Your Website Under DDoS Or CC Attack?
You now know the first split: bandwidth and QPS together means a surge, QPS alone means trouble. The next question is what kind of trouble. A flood at the network layer and a flood at the application layer leave different fingerprints, and each needs a different response. Answering whether your website is under DDoS or CC attack starts with the layer where the abuse happens.
Network-Layer Versus Application-Layer Signs
A network-layer DDoS announces itself with a sudden bandwidth spike. Volumetric floods push raw packets at your pipe, so the measurement that matters is packets per second. An application-layer CC attack works the opposite way. It mimics legitimate users by sending high-frequency HTTP/HTTPS requests to dynamic pages such as login, search, and submission forms. Each request looks valid. The goal is to exhaust server CPU, database connections, and other computing resources until service stops. Here the metric that matters is requests per second.
Attack Layer | Traffic Measurement Metric |
|---|---|
Network-layer DDoS | Packets per second (pps) |
Application-layer attacks | Requests per second (rps) |
Not every application-layer strike looks like a request storm, though. Slow attacks such as Slowloris belong to this layer yet never produce high QPS. Their requests stay incomplete for long periods, so logs may not spike at all. Watch for these signs instead:
ESTABLISHED connections stay saturated for a long time
Web service workers run out while CPU stays moderate
Log volume looks normal despite visible slowness
Requesting The Data-Center Traffic Graph
A network-layer/transport-layer DDoS is easy to confirm. Ask your data center for the traffic graph for your IP. A sharp inbound spike on that graph, matched against your own monitoring, settles the question quickly. Application-layer CC is harder to confirm. The packets look ordinary, so the graph may show little. You need deeper inspection of requests, connections, and logs before you call it.
One trap catches many admins: duration. CC attackers often try to exhaust resources with short attack traffic, so a brief incident does not clear the server. A brief burst can drain database connections long after it ends. Treat length as a weak signal and weigh intensity and pattern instead. When you determine whether a server is under a CC attack, the shape of the requests matters more than how long they last. If you suspect a server is under attack but the graph stays flat, move to connection states and logs, which the next sections cover. That is how to investigate a suspected ddos or cc-style attack without wasting time on the wrong layer.
Inspect TCP Connection States
Monitoring graphs tell you where to look. Connection states tell you what is actually happening. Run netstat -an or ss -s on the host and count sockets by state. A healthy web server shows a steady mix of states that tracks your normal user load.
Spotting Abnormal SYN_RECV And TIME_WAIT
Two states deserve a hard look. A flood of half-open sockets stuck in SYN_RECV means many clients start a handshake and never finish it. Some of that is normal internet noise. A count that climbs into the hundreds and stays there is not. TIME_WAIT is different. Every closed connection leaves one behind for a short period, so a busy site always shows some. Thousands of them, piling up faster than they clear, point to short-lived connections opening and closing at machine speed. That pattern fits a cc flood far better than a room full of real shoppers.
State | Normal reading | Suspicious reading |
|---|---|---|
SYN_RECV | Small, fluctuating count | Large count that persists |
TIME_WAIT | Present but stable | Rapid, unbounded growth |
ESTABLISHED | Tracks active users | Saturated for long stretches |
Comparing Connections To Real User Behavior
Numbers only mean something against a baseline. Record your connection counts at quiet hours and at peak hours for a week. You then know what a busy Tuesday looks like. Compare the current count to that baseline, not to zero. Real users also behave in recognizable ways. They load a page, fetch its assets, then pause to read. Attack sources hammer endpoints without pauses.
Watch for supporting signals alongside the socket counts. High ping times, clients dropping mid-session, and the server vanishing from server lists all suggest resource exhaustion rather than popularity. A network-layer flood usually kills SSH access too, while a cc attack often leaves you logged in fine. Treat these clues as confirmation, not proof. Move to the logs next.
Analyze Web Access Logs For CC Patterns
When the graphs and socket counts leave you unsure, check web access logs. They record every request, so they help you determine whether a server is under a cc attack with far more certainty than traffic graphs alone. A cc attack leaves a readable fingerprint. A flood of requests arrives in a burst, and the pattern behind that traffic tells you what you face.
Repeated Paths And Single-Source Connections
Real visitors spread their requests across many pages. They load the home page, open articles, and pull images and scripts along the way. An attack looks narrower. You will see the same url being refreshed at high frequency, often by many concurrent connections from one source address. The clearest sign is a client repeatedly hitting only the same endpoint, such as a login form or a search query, while ignoring static assets. Ask whether the access logs show a large number of requests to one path in a short window. Dynamic endpoints being flooded with identical parameters point to an http/https flood rather than a crowd of readers.
Using Log Tools To Detect And Investigate
Log analysis tools scan entries as they arrive and flag the patterns above in real time. They also preserve the evidence, which matters for how to investigate an incident after it ends. Attack surge detection adds another layer. It watches security-engine alert rates and raises a warning when activity departs from the normal range. Use these tools to separate an application-layer strike from a network-layer one. A layer 7 flood inflates request counts while packet volume stays calm, and layer 7 qps climbs without matching bandwidth. A ddos at the lower layer does the reverse. That contrast confirms the layer and guides your response.
Avoid Misjudgments, Respond Correctly
Common False Alarms To Rule Out
A promotion, a newsletter send, or a post that goes viral can mimic hostile volume. Rule these out before you block anyone. Check your campaign calendar and social mentions first. Then compare source regions against your usual audience. Real readers arrive from places you already serve, and they open pages before they fetch assets. A crawler sweep or a monitoring bot can also inflate request counts. Look for a declared user agent and a polite request rate. Finally, confirm the spike is not retransmission noise from a flaky international link. Duplicate packets inflate traffic graphs without adding real users.
Tailored Responses For Each Scenario
For a genuine surge, add capacity and cache aggressively. Scale out web workers, raise database connection limits, and serve static assets from a CDN. Cache rendered pages where your content allows it. These steps absorb load without punishing anyone.
For a cc attack, act in layers. Apply rate limits per source and per endpoint. Challenge suspicious clients with a JavaScript check or a captcha. Then check server logs for malicious scripts and known vulnerabilities, because a compromised host may be feeding the flood. If you suspect the server is under attack at the network-layer, ask your provider to filter upstream instead. A ddos at that layer rarely yields to host-level tuning. Learn how to investigate each case from its own evidence: an application-layer flood shows in request logs, while a layer 7 request storm leaves packet counts calm. Match the fix to the layer you confirmed.
Bandwidth-versus-QPS divergence remains your fastest first check to determine whether a server is under a cc attack. That single comparison saves you from guessing at the wrong layer. Diagnosis then layers upward: responsiveness, TCP states, and logs confirm what the request pattern suggests. Stay calm and follow the evidence. Verify before you block anyone, and scale before you assume malice. A cc flood and a network-layer ddos each leave distinct fingerprints, so match your fix to the layer you confirmed. Finally, baseline your normal traffic now. Record quiet-hour and peak-hour numbers for a week. The next incident becomes far easier to judge.
FAQ
How fast can I tell an attack from a busy day?
Check bandwidth and QPS on the same graph first. Matching climbs point to real demand. A QPS spike over a flat bandwidth line points to a cc flood. You get an answer in minutes, not hours.
Does a short outage rule out an attack?
No. Attackers often send brief bursts of cc traffic to drain database connections and worker pools. Service can stay degraded long after the burst ends. Judge the request pattern, not the clock.
Can a cc attack hide from my bandwidth graph?
Yes. Each request carries little data, so the graph barely moves. Watch request rate, concurrent connections, and CPU instead. A ddos at the network layer does the opposite and lights up the graph at once.
What should I check before blocking anyone?
Confirm the source regions match your audience. Check your campaign calendar for a promotion or viral post. Review user agents for crawlers. Real traffic and hostile traffic differ in path diversity, so read the logs before you act.
When should I call my provider instead of tuning the server?
Call the provider when packet volume spikes alongside bandwidth. That pattern means a ddos at the network layer, and upstream filtering works better than host tuning. Keep handling application-layer cc floods on the server itself.
