Comprehensive Guide to DDoS Mitigation

A distributed denial-of-service (DDoS) attack floods a website or server with traffic from many machines at once, usually hijacked devices in a botnet, until real visitors can't get through. No single tool stops every kind of attack. This guide explains the main attack types, the defences that work against each, and what you can do yourself on shared hosting and on your own VPS.

1. What a DDoS attack is, and why it matters

Every server has limits: the bandwidth of its network link, the number of connections it can track, and the CPU and memory available to answer requests. A DDoS attack pushes one of those past its limit. The traffic comes from thousands of addresses at once, so blocking a single IP doesn't help the way it does with one abusive visitor.

Botnets built from poorly secured cameras and routers make attacks cheap to launch; Mirai (2016) showed this at scale, and attacks of several terabits per second are now reported every year.

2. The three types of attack

Amplification attacks send small requests with a forged source address (the victim's) to open DNS, NTP or memcached servers, which send much larger replies to the victim. The 2018 attack on GitHub, about 1.35 Tbps, used memcached this way.

Application-layer attacks are the hardest to spot because each request looks like a normal visitor. A few hundred requests per second to an uncached search page can take down a site that would shrug off millions of requests for a cached image. The HTTP/2 "Rapid Reset" technique, disclosed in 2023, showed how a protocol feature can multiply the load from a small botnet.

3. First: is it really an attack?

Not every spike is a DDoS. Before you block anything, look at who is sending the traffic:

• Real visitors come from many IPs with normal browsers, spread across your pages, often after a promotion. Don't block them; cache more.
• An aggressive crawler is one or a few IPs or one user agent fetching thousands of pages.
• A login or form attack hammers wp-login.php, xmlrpc.php or a contact form.
• A real DDoS shows huge request or packet rates from many sources, often to one URL or port.

The step-by-step checks, with log and connection commands, are in how to check for DDoS attacks or excessive traffic from specific IPs.

4. The defences, layer by layer

Blackholing drops all traffic to the attacked address; it ends the attack and takes you offline with it, so providers use it only as a last resort. Geo-blocking helps only if your customers are all in one country and the attack is not.

Challenge pages (a JavaScript check or CAPTCHA before the site loads) stop many bots, but they add friction for real visitors and can block legitimate tools and APIs. Turn them on during an attack, not permanently.

5. On your own server: practical settings

This section applies to a VPS or dedicated server you manage, not to shared hosting.

• Keep SYN cookies on. Modern Linux kernels enable them by default; check with sysctl net.ipv4.tcp_syncookies (it should print 1).
• Limit request rates in the web server. In nginx, for example:

# in the http block
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

# in a server or location block
limit_req zone=perip burst=20 nodelay;

Apply stricter limits to expensive URLs such as login, search and checkout rather than to the whole site.

• Protect against slow requests. In Apache, keep mod_reqtimeout enabled; in nginx, lower client_header_timeout and client_body_timeout, which default to 60 seconds.
• Limit connections per IP in the firewall. CSF, nftables and firewalld can all do this; see mitigating DDoS attacks using CSF and firewall management with nftables.
• Put a WAF in front of the application. See understanding and implementing a web application firewall.
• Don't be an amplifier. Close open DNS resolvers, NTP, memcached and SNMP to the internet. A misconfigured server can be used against someone else.

6. Monitor, respond and review

• Monitor before you need it. Keep graphs of bandwidth, requests per second, connections and error rates, and set alerts, so you know what normal looks like.
• During an attack: confirm it is an attack, switch the CDN into its strictest mode, add temporary rate limits, and tell your hosting provider with times, target URLs and sample IPs.
• Afterwards: review the logs, note what worked and what didn't, and fix the weak spot, often an uncached page or an exposed server IP.

7. On Domain India hosting

Shared hosting (cPanel, DirectAdmin, Webuzo). The server firewall is managed for every account on the server, and on our cPanel servers Imunify360's DOS protection is enabled. You can't change those settings, and you don't need root commands. What you can do:

• block abusive IPs for your own site with cPanel's IP Blocker or Require not ip rules in .htaccess;
• cache your pages and protect login forms;
• put a CDN or DDoS-filtering service in front of the site by changing your DNS;
• open a ticket with the IPs, URLs and times you found, so we can check the server-level firewall for the same traffic.

VPS. Our VPS plans are self-managed, so the settings in section 5 are yours to run. The VPS page lists DDoS protection among the features of every plan; ask support what it covers for your plan before you rely on it for a large attack.

The card shows the live price, excluding 18% GST; on 19 September 2026, the Domain India list price for VPS Starter was ₹553 a month.

Ready to act? Check your logs with the steps in how to check for DDoS attacks, read the CSF guide if you run your own server, or open a support ticket with the IPs and times you found.