DDoS-protected VPS: what 'always-on' protection covers, and what it can't

Short answer: DDoS protection at the hosting provider filters volumetric network attacks, the layer 3 and 4 floods, before they reach your server. It does not understand your application, so an HTTP flood, abusive bots or a login brute force still need rate limiting, caching or a CDN on your side. “Always-on” means traffic is filtered all the time, instead of being diverted only after an attack has been noticed.

Almost every VPS offer now says “DDoS protected”, and the phrase covers very different things. Sometimes it means a scrubbing system in front of the network, and sometimes only that the provider will disconnect your IP to protect everyone else. This guide explains what each kind of attack does, what network-level protection can and cannot stop, what you still have to configure yourself, and which questions show you what a host actually provides.

What kinds of DDoS attack matter?

• Volumetric and amplification attacks (layer 3/4). The goal is to fill the pipe. UDP floods are the classic case, and amplification is the cheap way to make them big: the attacker sends small requests with your IP as the forged source to open DNS, NTP, memcached or similar servers, and their much larger replies all arrive at you. Measured in gigabits and packets per second.
• Protocol attacks. SYN floods and similar floods of half-open or malformed connections. They exhaust state rather than bandwidth: the connection table of your kernel, a firewall or a load balancer fills up long before the uplink does.
• Application-layer attacks (layer 7). Real TCP connections making valid-looking HTTP requests, often aimed at whatever is most expensive to answer, such as search, login, cart or uncached pages. A few hundred requests per second can take down a site whose bandwidth is barely touched.

The first two are what a hosting provider’s protection is built for. The third is the one that takes most small sites offline, because it needs so little traffic.

What do “always-on” and “on-demand” mean?

• Always-on: all traffic to your IP passes through filtering all the time, and only clean traffic is forwarded. There is no switch-over when an attack starts, so there is no gap at the beginning of one.
• On-demand: traffic flows normally until monitoring detects an attack. Only then is it diverted to a scrubbing system. It is cheaper to run, but the first part of each attack reaches you before the diversion takes effect.
• Null-routing (blackholing): the provider drops all traffic to the attacked IP, at its edge or upstream. That protects the provider’s network and its other customers. For you it means being offline for as long as the null route stays, which is exactly what the attacker wanted. On some cheap plans this is the whole of the “protection”.

What can network-level protection not do?

• Tell a bot from a visitor at layer 7. A filter in front of the network sees well-formed TCP connections carrying encrypted HTTPS. Without your TLS keys it cannot even read the requests, let alone judge whether ten thousand GET /search?q=… a minute come from people.
• Stop a login brute force or credential stuffing. That is a few requests per second, nowhere near a flood, and it is your application’s problem to rate-limit.
• Absorb what stays under the threshold. Mitigation reacts to traffic that looks abnormal for the network. An attack too small to look abnormal there can still be large for one VPS: enough to saturate its port, fill its connection table or keep its CPU busy with packet processing.
• Protect what is not on the server. Your DNS provider, your domain registrar and the third-party APIs your site depends on are attacked separately and protected separately.

An application that falls over under load shows the same symptoms whether the load is an attack or a successful launch: 502 and 504 errors from the proxy in front of it. See 502 Bad Gateway and 504 Gateway Timeout for that side of the problem.

What do you still configure yourself?

Rate limiting in nginx

nginx can limit requests per second (limit_req) and open connections (limit_conn) per client IP. The zones go in the http context, which on Debian and Ubuntu includes every file in /etc/nginx/conf.d/:

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_conn_zone $binary_remote_addr zone=conns:10m;
limit_req_status  429;
limit_conn_status 429;

limit_conn conns 20;                        # at most 20 open connections per IP

location / {
    limit_req zone=perip burst=40 nodelay;  # 10 requests/s, short bursts up to 40
    # ... your existing root / proxy_pass lines
}

location = /wp-login.php {
    limit_req zone=login burst=5;           # about 5 login attempts a minute
    # ... your existing fastcgi_pass lines
}

sudo nginx -t && sudo systemctl reload nginx

Start generous and tighten while watching the error log. A page with 60 assets loads 60 requests at once, so serve static files from their own location without limit_req, or raise the burst. Many users behind one company or mobile-carrier address also share an IP. If the site sits behind a CDN or reverse proxy, set up nginx’s real_ip module first (set_real_ip_from with the proxy’s ranges, plus real_ip_header). Otherwise every request appears to come from the proxy’s addresses, and you rate-limit the proxy.

Caching

A request answered from cache costs almost nothing, and one that reaches PHP or a database costs a lot. Serve static files directly from nginx with long cache headers, and put a page cache in front of dynamic pages that are the same for every visitor. A flood against cached pages mostly measures how fast nginx can send a file.

fail2ban for the clients that keep hitting the limit

nginx logs every rejected request as limiting requests in its error log, and fail2ban ships a filter for exactly that line. Turn the jail on to ban addresses at the firewall once they keep tripping the limit:

[nginx-limit-req]
enabled  = true
maxretry = 10
findtime = 1m
bantime  = 1h

sudo apt install -y fail2ban      # Debian, Ubuntu (Rocky, Alma: dnf from EPEL)
sudo fail2ban-client reload
sudo fail2ban-client status nginx-limit-req

This helps against a handful of noisy sources, not against a botnet of thousands of addresses that each stay under the limit. The same tool protects SSH; see securing SSH access.

The firewall only sees what reaches the VM

UFW, nftables or Windows Firewall decide what your server accepts, so they shrink what an attacker can aim at: no open database ports, no forgotten admin panels. They cannot do anything about a flood that fills the line before it reaches them, which is why that part has to happen upstream. Set the firewall up anyway with UFW in five steps, and confirm that Linux’s SYN-flood defence is on (it is by default on current distributions):

sysctl net.ipv4.tcp_syncookies     # 1 = enabled

Hiding a website behind a CDN

A CDN or reverse proxy in front of a website takes the layer 7 load: it caches, it challenges suspicious clients, and it spreads the traffic over a network far larger than any single server. It only works if attackers cannot simply go around it to your server’s IP address, and that address leaks in predictable ways:

• DNS history from before the move, which public services keep.
• A mail server on the same IP, whose address is in every message header.
• Subdomains that are not proxied (direct., ftp., cpanel.).
• The TLS certificate served on the bare IP, which internet-wide scanners index.

Then close the back door: allow ports 80 and 443 only from the address ranges your CDN publishes, so a request that bypasses it never gets an answer.

How do I tell whether I am under attack?

Find the interface name with ip -br link (often eth0 or ens18). The traffic tools below are packages of the same name: in the normal repositories on Debian, Ubuntu and Alpine, and in EPEL on Rocky and AlmaLinux.

vnstat -l -i eth0             # live rx/tx rate and packets per second
sudo iftop -n -i eth0         # which addresses the traffic comes from
nload eth0                    # simple live graph of in and out

ss -s                                     # summary of socket states
ss -Htan state syn-recv | wc -l           # half-open connections; thousands = SYN flood

# established connections per client address
ss -Htn state established | awk '{print $4}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head

# is the connection-tracking table filling up?
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max
sudo dmesg | grep -i 'nf_conntrack: table full'

• Huge inbound Mbit/s or packets per second: a volumetric attack. Your provider’s filtering should be dealing with it. If it reaches the server anyway, tell support, with timestamps.
• Thousands of SYN-RECV, or conntrack at its maximum: a protocol attack, or a load the box is too small for.
• Normal bandwidth but an exploding access log: layer 7. Find the top addresses and URLs in the log, then use rate limiting, caching and the CDN.
• CPU busy in si (softirq) or ksoftirqd on top: the kernel is spending its time on packets. The high CPU usage guide explains how to read that.

How do I protect a game server from DDoS?

Game servers are a common DDoS target, and the attacker is often someone who plays on them. They are also awkward to protect: many games talk over UDP, and UDP is the protocol most amplification floods use, so filters treat it with suspicion. A filter profile tuned for web traffic can drop or throttle legitimate game packets, and players then see lag, rubber-banding or disconnects while the server itself looks healthy.

• Ask the host, before you order, how game traffic and UDP are handled, and what to do if legitimate players get filtered.
• Expose only the game port. Keep RCON, admin and query ports firewalled or limited to your own IP.
• Do not publish the server’s IP where you do not have to. A domain name lets you move the server later without telling every player.

For a worked example, see running a Minecraft server on a VPS. The Palworld and Rust server guides are two more.

What should I ask a host about DDoS protection?

• Is it included, or an add-on? Some providers bill protection monthly or per attack.
• Always-on or on-demand? If it is on-demand, how long does diversion take after an attack starts?
• What is the null-route policy? When is an IP blackholed, for how long, and is it automatic?
• Is layer 7 covered, and how? Most network protection is layers 3 and 4 only. That is normal, but you should know it.
• Will I be told? Do you get a notification or a log of what was filtered, or do you find out from your users?
• How is UDP and game traffic treated, and can false positives be reported and fixed?
• Does filtering add latency, and where does it happen: in the same location, or at a scrubbing centre somewhere else?
• What does the big number measure? A capacity figure on a pricing page can describe the whole network’s connectivity rather than how much attack traffic can be filtered. Ask which one it is.

How does DDoS protection work at VMHeaven?

Every server and hosting plan includes always-on, automatic DDoS mitigation at no extra cost, in whichever location it runs; there is no add-on to buy and nothing to switch on. Amsterdam and Frankfurt sit on a redundant premium carrier blend with 1 Tbit/s of aggregate capacity, and that figure is total carrier capacity, not a mitigation rating. Like any network-level filter, the protection works on traffic, not on your application, so rate limiting, caching and the CDN decision above stay your part, on the dedicated servers as much as on a VPS.

Every line has it, so pick the line for the workload: Standard KVM for general-purpose servers and websites, Hi-CPU KVM for game servers and other single-thread work, and DMCA Ignored KVM if you need offshore DMCA-ignored hosting. DDoS protection is one item on our checklist for choosing an offshore VPS host; if you are still choosing a city, read Frankfurt or Amsterdam.

Frequently asked