In short. A DDoS attack is a flood of junk requests from thousands of devices that exhausts your server's resources, so real visitors stop getting a response. Signs: the site suddenly stops loading or returns 502/503, traffic and load spike with no marketing reason, and the logs fill with near-identical requests from many IPs. First-hour plan: confirm the attack from logs and metrics, put the site behind anti-DDoS protection or a CDN, rate-limit requests, serve everything you can from cache and static files, and contact your host. Below is each step in detail.
What DDoS is and why it works
DDoS (Distributed Denial of Service) means exactly that — denial of service, distributed across many sources. The attacker controls a botnet: a network of compromised devices, from servers to CCTV cameras and home routers. They all hit your site at once. Any single request looks almost normal, but their combined volume drains some resource: bandwidth, memory, CPU, the connection limit, or the database pool.
DDoS doesn't hack your site — it makes it unreachable. The data is intact, but the business stalls: leads stop coming in, payments fail, and your ads keep spending budget on visitors who only see an error.
The scale has grown by orders of magnitude: the largest publicly disclosed attack Cloudflare mitigated in the autumn of 2025 peaked at 22.2 Tbps — against a "record" 5.6 Tbps just a year earlier. The driver is IoT botnets like Mirai and its descendants: millions of cheap devices left on admin/admin. But it isn't the record-breakers that threaten a small site — it's routine attacks of a few gigabits, cheap to rent and more than enough to drop a typical VPS in seconds.
Attack types: bandwidth, connections, application
| Layer | Target | Examples | How it looks |
|---|---|---|---|
| L3/L4 — volumetric | Bandwidth and network stack | UDP flood, SYN flood, DNS/NTP amplification | Pipe saturated, server unreachable entirely, ping fails |
| L7 — application | The app itself | HTTP flood on heavy pages: search, filters, cart | Bandwidth free, but PHP/database choke, 502/503/504 errors |
The distinction is critical for defense. You can't absorb a volumetric attack alone — if a 1 Gbps link is flooded with ten, no server tuning helps: whoever has the bigger pipe must filter it (an anti-DDoS provider or CDN). An application-layer attack you can often blunt yourself: rate limiting, caching, cutting off bots. We covered the error codes it surfaces as in our guides to the 502 error and the 503 error.
Telling DDoS from an ordinary outage
Not every spike of downtime is an attack. The same symptoms come from a crashed backend, a full disk, a surge of real visitors after an ad or viral post, or a botched deploy. Check the signs together:
- Sudden traffic spike with no cause. No ad launch, no newsletter, no news hook — yet inbound traffic is 10–100× normal.
- Uniform requests. Logs show thousands of hits to the same URL (often a heavy one: search, catalog filter) from hundreds of different IPs.
- Anomalous geography. Your audience is one country, but requests arrive as a steady stream from dozens.
- Strange User-Agents. Empty, outdated, or identical across thousands of IPs.
- Real users can't get through. On viral traffic people behave like people — they browse, they linger. Under attack, conversion and depth collapse to zero at record "traffic."
# Quick triage from the nginx access log:
# top 20 IPs by request count over the last 10,000 lines
tail -n 10000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
# top requested URLs — where they're hitting
tail -n 10000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -10If one or two IPs make thousands of requests, that's not DDoS yet — it's a crude flood you close with an IP ban. DDoS starts where there are hundreds or thousands of sources and banning them one by one is pointless.
The first hour: a step-by-step plan
Step 1. Confirm the fact and scale
Capture the metrics: CPU and memory load, connection count, inbound bandwidth, top IPs and URLs from the logs. You need this to choose a defense, to talk to your host, and for the post-incident report. Check the site from the outside — from another network or via an availability check: from inside the server the picture often looks fine.
Step 2. Turn on anti-DDoS or proxy through a CDN
The fastest move for an unprepared site is to put the domain behind a protective proxy (a CDN with anti-DDoS: Cloudflare, Qrator, StormWall and similar). The DNS records point to the protection's IP, all traffic is filtered, and only clean requests reach your server. Note: while the DNS TTL is still refreshing, the attack keeps hitting the old IP — so after switching, change your server's real IP, or the attacker keeps striking around the protection.
Step 3. Rate-limit requests
For L7 attacks, enable rate limiting on the web server: even a simple "no more than N requests per second per IP" cuts a large share of the flood. Detailed strategies are in the rate limiting article.
# nginx: no more than 10 r/s per IP on heavy routes
limit_req_zone $binary_remote_addr zone=antiflood:10m rate=10r/s;
location /search {
limit_req zone=antiflood burst=20 nodelay;
}Step 4. Serve everything you can from cache and static files
An application-layer attack is dangerous because each request is expensive for the backend. Serve the homepage and landing pages from cache, and temporarily disable heavy features — search, filters, exports. Let the site run in "storefront mode," but let it run.
Step 5. Contact your host
Hosting providers have their own network protection and blocklists. Hand them the data you gathered in step 1. Know this: under a heavy attack the host may blackhole your IP itself — drop all traffic to it to save the neighbors. The site is then fully down, and that's one more argument for external filtering.
An attack ends when it costs the attacker more than it costs you. The point of defense isn't to "beat the botnet" — it's to make you an unprofitable target.
How to prepare in advance
- Deploy a filtering proxy before the attack, not during. Onboarding under fire means hours of downtime; onboarding ahead of time means an hour of calm work.
- Hide the server's real IP. If it leaked into DNS history, mail headers, or subdomains, the protection gets bypassed with a direct hit.
- Set up a WAF. An application firewall cuts off bots and stray hacking attempts alike — how it works is in the WAF article.
- Prepare a "lightweight" version of the site. A static stub with contacts and cacheable landing pages should switch on with one command.
- Write a response plan. Who decides, where the logs are, how to enable protection, the host's phone number. At 3 a.m. under attack it's too late to think — you execute.
The role of monitoring: know before your customers do
Half the damage from DDoS is the time before anyone notices. The classic scenario: the attack starts at night, the owner learns of it in the morning from a customer chat, and 6–8 hours of traffic and reputation are gone. Uptime monitoring shrinks that time to minutes: a check every 30–60 seconds from several regions, a Telegram alert on the very first failure, a response-time chart that shows degradation starting before a full outage. You can set this up on enterno.io — the free tier covers several sites, and major Runet outages are visible on our outages page.
Frequently asked questions
How long does a DDoS attack last?
From minutes to weeks. Most commercial attacks are short — hours: renting a botnet costs money, and if the site holds, the attacker moves to an easier target. Prolonged attacks signal targeted pressure: competition, extortion, activism.
Can a small site be attacked?
Yes, and they are, routinely. Ordering an attack on a small site costs less than a monthly streaming subscription, so regional shops, clinics, schools, and service firms end up in the crosshairs — most often in high season and at a competitor's request.
Will simply changing the IP address help?
Not for long. If the domain points to the new IP directly, the attacker finds it with the first DNS query. Changing the IP works only paired with a filtering proxy: the protection takes the traffic, and the new real IP is never published.
Is DDoS a criminal offense?
Yes. In most jurisdictions it falls under computer-misuse and unauthorized-access statutes, and organizers and operators are regularly traced through the payment trail. If you're attacked, preserve the logs — they'll matter both for a police report and for the conversation with your provider.
Checklist to remember
- Sudden traffic with no cause + uniform requests from thousands of IPs = likely DDoS.
- First hour: logs and metrics → anti-DDoS/CDN → rate limiting → cache and static → host.
- Volumetric attacks are filtered externally; application-layer ones can be blunted on the server.
- After enabling protection, change the real IP or it gets bypassed.
- Uptime monitoring — so you learn of an outage in a minute, not in the morning from customers.