How to Stop a DDoS Attack: The First 10 Minutes (2026)

Your site was fine an hour ago. Now it's crawling, timing out, or throwing 502s — and your traffic graph shows a wall of hits that makes no sense. If you're trying to figure out how to stop a DDoS attack before it drags you fully offline, you're in the right place. Take a breath. Most floods can be blunted in the first ten minutes with tools you probably already have. Below, we'll confirm the attack, filter the bad traffic, and keep your origin alive — in the exact order a working ops team does it.

Quick Answer: To stop a DDoS attack, first confirm the traffic is malicious — look for sudden 10-100x spikes, mass timeouts, and 5xx errors. Then put your site behind a proxy like Cloudflare and switch on Under Attack Mode so every visitor is challenged. Add rate-limiting rules, block the worst IP ranges and ASNs, and offload your origin so the flood never reaches it.

We resolve 20 to 30 client-site incidents every single day, and enough of them are traffic floods that this playbook comes straight from live firefighting — not a textbook. A working host like Hostaccent sees the same handful of attack shapes over and over, which is why the steps below are ordered by what actually stops the bleeding fastest, not by what sounds clever.

What's Actually Happening When Your Server Is Under Attack

A DDoS attack — distributed denial of service — floods your server with so many requests that real visitors can't get through. "Distributed" means the traffic comes from thousands of machines at once, often a botnet of hijacked devices, so you can't just block one IP and walk away.

Attacks hit at different layers. It helps to know which one you're facing, because the fix differs.

• Layer 3/4 (volumetric): raw packet floods — SYN floods, UDP floods, amplification. The goal is to saturate your bandwidth or connection table before a single PHP process even runs.
• Layer 7 (application): floods of real-looking HTTP requests hammering login pages, search endpoints, or your cart. These are nastier because each request looks almost legitimate and forces your server to do actual work.

Here's the reassuring part: your data is almost never the target. A DDoS attack is about knocking you offline, not stealing files. Your database, backups, and SSL certificates are untouched. You're dealing with a traffic problem, not a breach — and traffic problems have clean, mechanical fixes.

Insider Insight: Layer 7 attacks are the ones that fool people into upgrading their server for no reason. Adding RAM won't save you when 5,000 fake bots request your search page every second — you have to filter the requests before they hit your application, not give the application more muscle to absorb them.

How to Know If a DDoS Attack Is Happening (or Just a Traffic Spike)

Before you touch anything, confirm it. Knowing how to know if a DDoS attack is real — versus a legit surge from a viral post — stops you from firewalling away paying customers.

Signs it's an attack, not organic traffic:

1. Traffic climbed 10-100x in minutes, not hours. Real surges ramp; attacks slam.
2. The requests are boring and repetitive — the same URL, the same user-agent, or blank referrers, often from countries you don't serve.
3. Your server load or connection count is pinned while actual page views (in analytics) barely moved. Bots don't run JavaScript, so they rarely show up in Google Analytics.
4. You're seeing 502, 503, or 521 errors as your origin buckles.

On a Linux VPS, count live connections per IP first:

bashCopy
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

Then watch your access log in real time:

bashCopy
tail -f /var/log/nginx/access.log

If a handful of IPs each hold hundreds of open connections, or one URL is hit thousands of times a minute, that's your answer. In our experience, the tell is almost always a small set of IP ranges or one abused ASN generating the bulk of the noise. If you're getting 521s specifically, our walkthrough on the Cloudflare Error 521: How to Fix Web Server Is Down breaks down whether it's the attack or your origin firewall.

How to Stop a DDoS Attack in the First 10 Minutes

This is the part you came for. Work top to bottom — each step buys you breathing room for the next.

Step 1 — Get behind a proxy (if you aren't already). If your origin IP is exposed, the attacker is hitting your server directly and nothing local will fully help. Point your DNS through Cloudflare (free tier is fine) so all traffic routes through their edge network first. This alone hides your real IP and absorbs most layer 3/4 volume at the edge. Hostaccent runs every client zone behind Cloudflare for exactly this reason — the edge eats the flood so the origin doesn't have to.

Step 2 — Turn on Under Attack Mode. In your Cloudflare dashboard, go to Security → Settings and enable Cloudflare Under Attack Mode. Every visitor now gets an interstitial "Checking your browser" managed challenge — one a real browser clears in about 5 seconds but a basic bot script fails outright. Cloudflare's own Under Attack Mode reference confirms it's built specifically to blunt layer 7 DDoS traffic, and after passing, real visitors aren't re-challenged for the duration of the challenge passage (default 30 minutes).

Step 3 — Block the obvious offenders. In Security → WAF, add rules to block or challenge the worst ASNs, countries, or IP ranges you spotted earlier. If the flood comes from a hosting-provider ASN you'd never get real customers from, block that ASN outright.

Pro Tip: Under Attack Mode is a blunt instrument — leave it on for days and you'll challenge Googlebot and legitimate API calls too, which can dent crawl rate and conversions. Switch it off the moment the flood stops, then rely on smarter rate-limiting for ongoing DDoS attack protection. Treat it as a fire extinguisher, not a smoke detector.

Layer the Defenses: Rate Limiting, WAF Rules, and Blocking at the Origin

Under Attack Mode stops the panic. Now build defenses that filter bad traffic quietly so you can turn the challenge screen off.

Cloudflare rate limiting. Create a rule that caps requests per IP — for example, more than 1000 requests in 10 seconds to / gets blocked for a minute. This kills layer 7 floods without punishing normal browsing. Tune the threshold to your real traffic; too tight and you'll challenge power users.

Nginx rate limiting at the origin. If the flood partially reaches your server, throttle it there too. The Nginx limit_req module is your friend. In your http {} block, define a zone:

bashCopy
limit_req_zone $binary_remote_addr zone=flood:10m rate=10r/s;

Then apply it inside the server or location block:

bashCopy
limit_req zone=flood burst=20 nodelay;

That caps each IP to 10 requests per second with a small burst — plenty for a human, painful for a bot.

iptables / firewall connection limits. For layer 3/4 pressure that slips through, limit concurrent connections per IP:

bashCopy
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 50 -j DROP

Fail2ban can auto-ban IPs that trip your rate limits, so you're not manually chasing addresses at 2 a.m.

Pro Tip: Watch your resources while all this runs. A layer 7 flood spikes PHP-FPM and MariaDB before it touches bandwidth — if your box is thrashing, the Why Is My VPS Running Out of RAM? guide shows how to read the real bottleneck instead of guessing. If pages are just slow rather than down, our How to Fix High TTFB in WordPress (2026 Guide) covers separating attack load from ordinary latency.

The OWASP Denial of Service reference is worth a read for the full taxonomy of application-layer attacks — it'll help you recognize the next one faster.

From the Hostaccent ticket queue: across our support volume, Linux server issues and brute-force/malware traffic together account for roughly half of what we handle each month, and application-layer floods hide inside both buckets. The fix is almost always filtering at the edge first, hardening the origin second — never the other way around.

After the Flood: Confirm It's Over and Stop It Recurring

Once traffic normalizes, don't just walk away — attackers probe again.

Confirm it's genuinely over. Turn off Under Attack Mode, then watch Cloudflare's Security Events and your origin logs for 15-30 minutes. If load stays flat and your uptime holds, you're clear. If the graph climbs again the moment challenges drop, re-enable and tighten your rate-limiting rules instead of the blanket challenge.

Lock in prevention:

• Keep your origin IP hidden. Never expose it in DNS records (like a stray mail. A-record). Attackers use those to bypass Cloudflare entirely.
• Set standing rate-limit rules so the next flood is throttled automatically, no manual toggling.
• Verify your backups. A DDoS won't corrupt data, but the panic of an incident is a bad time to discover your last backup is stale. We found — the hard way, during a real hardware failure years back — that untested backups are just hope. Run a restore drill.
• Cache aggressively. Full-page caching at the Cloudflare edge means most requests never reach PHP at all, which quietly absorbs a huge share of application-layer load.

If your SSL started throwing handshake errors mid-attack, that's often a symptom of the origin being overwhelmed, not a certificate fault — our Cloudflare Error 525: How to Fix SSL Handshake Failed post untangles the two. And if you're on shared hosting and hit account-level ceilings during the surge, Shared Hosting Resource Limit Exceeded: Causes & Fix (2026) explains what actually got capped.

When It's Time to Move to Managed Protection

Here's the honest takeaway before the pitch: everything above, you can do yourself for free. Cloudflare's free tier plus solid Nginx rules will stop the large majority of attacks small sites face.

But if you'd rather not babysit iptables rules at 2 a.m. — or you keep getting hit — letting the infrastructure handle it is a fair call. Our Basic VPS plan starts at $7.99/mo and ships on a Cloudflare → Nginx → Apache stack with NVMe SSD storage, a 99.9% uptime guarantee, and a 30-day money-back guarantee — so the proxy layer, WAF, and rate limiting are configured before your first flood. One honest limit: a single entry-level VPS won't absorb a massive volumetric layer-3 attack alone — that's the job of the Cloudflare edge in front. Hostaccent's managed setup pairs the two so neither fights solo, backed by real engineers who resolve these daily.

Conclusion: The Three Moves That Matter

Knowing how to stop a DDoS attack comes down to three moves, in order: confirm the traffic is malicious, challenge it at the edge with Under Attack Mode, and filter it with rate limiting so you can drop the challenge. Everything else is refinement.

Your quick recap:

• Confirm first — check connection counts and logs before you firewall anyone.
• Proxy + Under Attack Mode buys instant relief for layer 7 floods.
• Rate limiting (Cloudflare + Nginx) is the sustainable defense; the challenge screen is temporary.
• Hide your origin IP and test your backups so the next attempt fizzles.

Next step: enable Cloudflare on your domain today — before you need it. The best time to set up DDoS defenses is a calm Tuesday, not mid-incident. As of 2026, edge-level protection is free and takes under an hour to configure.

Frequently Asked Questions

How Do I Know If a DDoS Attack Is Happening?

Look for a sudden 10-100x traffic spike with repetitive requests to one URL, a pinned server load while real analytics barely move, and rising 502/503 errors. Run netstat to count connections per IP — if a few IPs hold hundreds of connections each, it's almost certainly an attack, not organic traffic.

How Long Does a DDoS Attack Usually Last?

Most attacks last from a few minutes to a few hours, though persistent ones can stretch across days in waves. Short bursts are often "stress tests" before a bigger hit. With edge protection and rate limiting in place, duration stops mattering much — the flood gets absorbed before it reaches your server.

Can Cloudflare Under Attack Mode Stop Every DDoS Attack?

It stops most layer 7 (application) attacks by challenging every visitor, and Cloudflare's edge absorbs a large share of volumetric layer 3/4 floods automatically. It's not magic against the very largest attacks, and it degrades user experience if left on. Pair it with rate-limiting rules for lasting DDoS attack protection.

How to Stop a DDoS Attack Without Cloudflare?

You can, but it's harder. Use your firewall (iptables connlimit rules), Nginx limit_req rate limiting, and Fail2ban to throttle and ban abusive IPs at the origin. The catch: your server still receives the flood, so a large volumetric attack can saturate bandwidth before your rules fire. An upstream proxy or scrubbing service does the heavy lifting free tools can't.

Will a DDoS Attack Damage My Server or Data?

Almost never. A DDoS is about denial of service — knocking you offline — not stealing or corrupting files. Your database, SSL certificates, and backups stay intact. The real risk is downtime and the revenue or SEO impact of being unreachable, which is exactly why fast mitigation matters.

Does a Bigger VPS Plan Stop DDoS Attacks?

Not on its own. More RAM helps absorb minor spikes, but a determined layer 7 flood will overwhelm any origin server if requests aren't filtered first. The winning combination is edge-level challenge and rate limiting plus a properly tuned server — which is how Hostaccent configures its managed VPS stack rather than relying on raw specs alone.