What Is a DDoS Attack? How DDoS Protection for Websites Works

A DDoS (distributed denial of service) attack floods a server or website with traffic from thousands of machines at once, so real visitors cannot get through. Protection works in layers: your hosting provider's network filtering stops large volumetric and protocol floods before they reach the server, while application-layer floods that look like normal browsing need a CDN or WAF, rate limiting and caching on your side. No single layer covers every attack.

Below: the three attack types, what host-level protection can and cannot filter, working nginx rate limits, and a checklist for the day it happens.

How a DDoS attack works

A plain DoS attack comes from one source and is easy to block by IP. A DDoS comes from a botnet: thousands of hacked PCs, routers, cameras and cheap servers, often rented by the hour. Some attacks add amplification: the attacker sends small requests with your IP forged as the source to open DNS, NTP or memcached servers, and those servers send much larger replies to you. A small amount of attacker bandwidth becomes a large flood at your end.

Targets are not only big companies. Online stores during a sale, game servers, forums, and businesses that receive a ransom email ("pay or we keep your site down") are common victims. Do not pay; it marks you as a target that pays.

The three types of DDoS attack

• Volumetric attacks (measured in bits per second): UDP floods and amplification attacks that fill the network link. If your server has a 1 Gbps port and the attack sends 20 Gbps, nothing you configure on the server helps; the pipe is full before packets reach your firewall.

• Protocol attacks (measured in packets per second): SYN floods, ACK floods and malformed or fragmented packets. They exhaust connection tables in the kernel, firewalls and load balancers rather than raw bandwidth.

• Application-layer attacks, or L7 (measured in requests per second): HTTP GET or POST floods against pages that are expensive to generate: search, login, cart, wp-login.php, xmlrpc.php, or any uncached page that runs database queries. Each request looks legitimate, so a few hundred requests per second can exhaust PHP workers and the database on a small server.

What hosting DDoS protection filters, and what it cannot

Network-level protection sits at the provider's edge, in front of your server. It watches traffic patterns and drops floods that are clearly not normal: amplification replies, packet storms, SYN floods. This is the only place volumetric attacks can be stopped, because by the time traffic reaches your VPS, the link is already full.

What it cannot reliably do is judge HTTPS requests. An L7 flood arrives as valid, encrypted TCP connections that complete the handshake. To the network filter, a bot loading your search page 50 times a second looks much like a busy customer. Telling them apart needs application context: URL, cookies, request rate per visitor, browser behaviour. That is the job of a CDN or WAF and your own web server configuration.

At IM HOST, Cloud VPS plans include network-level DDoS protection together with dedicated vCPU and RAM, and every Linux VPS comes with DDoS protection and full root access, so you can add the application-layer rules below yourself. Shared hosting accounts include DDoS and brute-force protection as well; our article on security measures for shared hosting covers what to add at the site level.

Practical layers of defense

1. Put a CDN or WAF in front of the site

A reverse proxy such as Cloudflare absorbs a large part of L7 traffic at its edge, serves cached pages without touching your server, and can challenge suspicious visitors. The free plan already includes basic DDoS mitigation. Follow our guide to setting up Cloudflare with your hosting, including the SSL mode and real visitor IP steps that people often miss.

2. Hide your origin IP

A CDN only protects you if attackers cannot reach the server directly. Common leaks: an A record for a subdomain like mail. or ftp. pointing to the origin, email sent from the same IP (it appears in message headers), and old DNS history from before the CDN. Once you are behind a CDN, allow ports 80 and 443 only from the CDN's published IP ranges, and if the IP was exposed during an attack, ask your provider about moving to a new one.

3. Rate-limit expensive URLs in nginx

nginx's limit_req module caps requests per client IP. This example allows 10 requests per second per IP with a burst of 20 for the whole site, and 5 per minute for the WordPress login page. Adjust the PHP socket to your installed version, and keep your existing location rules if they differ:

# /etc/nginx/conf.d/ratelimit.conf  (loaded inside the http block)
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_status 429;

# inside your site's server block
location / {
    limit_req zone=perip burst=20 nodelay;
    try_files $uri $uri/ /index.php?$args;
}

location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Test and apply without downtime:

sudo nginx -t && sudo systemctl reload nginx

Rejected requests receive status 429. One trap: behind a CDN, $binary_remote_addr is the CDN's IP, not the visitor's, so you would rate-limit everyone together. Configure nginx's real IP module (set_real_ip_from and real_ip_header) first, as described in the Cloudflare guide.

4. Cache everything you can

A full-page cache turns an expensive PHP and database request into a file read. Floods against cached pages are cheap to absorb; floods against uncached search, cart or login pages are what take sites down. Disable xmlrpc.php if nothing uses it, and add a challenge or captcha to public forms.

5. Harden the server itself

Expose only the ports you need, keep SSH off password login, and use fail2ban for repeated abuse. Our guide to securing a Linux VPS with SSH keys, UFW and fail2ban has the commands. Linux enables SYN cookies by default, which helps against small SYN floods; confirm with sysctl net.ipv4.tcp_syncookies (the value should be 1).

Is it a DDoS attack or just a busy day?

Real traffic spikes follow a cause: a campaign, a TV mention, a sale. Attack traffic usually shows a sudden jump from many IPs, the same URL or user agent repeated, empty referrers, and countries you do not normally serve. On the server, these commands show connection states and the top client IPs and URLs:

ss -s
ss -tn state syn-recv | wc -l
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
sudo awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Thousands of connections in SYN-RECV, or a handful of URLs taking most of the requests, point to an attack rather than customers.

DDoS incident checklist

1. Confirm the pattern with the logs above, and rule out a bug or a crawler gone wrong.

2. Contact your provider immediately. Send the start time, the target IP or domain, and log samples. At IM HOST, support engineers are available 24/7.

3. Turn on the CDN's attack mode or a challenge rule for the targeted path.

4. Block the worst sources temporarily: specific IP ranges, networks or countries at the CDN, not on the server.

5. Tighten rate limits on the URL being hit, and serve a cached or static version if possible.

6. Keep customers informed on social media or a status page hosted elsewhere.

7. Review afterwards: which endpoint was hit, whether the origin IP leaked, and which limit would have stopped it earlier.

Frequently asked questions

Can a DDoS attack be stopped completely?

Not with one tool. Large floods are filtered at the provider's network, and application-layer floods are handled by a CDN, rate limits and caching. With these layers in place, most attacks become a short slowdown instead of an outage.

Does a VPS come with DDoS protection?

It depends on the provider. At IM HOST, Linux VPS and Cloud VPS include DDoS protection, and Cloud VPS specifies it at the network level. Application-layer rules on your web server remain your part, since you control the configuration.

Is Cloudflare's free plan enough to protect against DDoS?

For many small and medium sites it covers most L7 floods, as long as your origin IP stays hidden and your server blocks direct access. Very targeted attacks on uncached pages may still need stricter rules or a paid plan.

How do I know if my website is under DDoS attack?

Look for a sudden traffic jump with no business reason, many connections from unfamiliar IPs or countries, and the same few URLs hit repeatedly. Your server's access log and the ss command will show this within minutes.

If you want network-level filtering in front of your server plus full control over your firewall and nginx rules, take a look at IM HOST Cloud VPS. Our engineers can help you review your setup before the next attack, not during it.