DDoS protection: what hosting providers actually give you
Every second host now lists "DDoS protection" in its plans. Behind that line there may be multi-terabit filtering, or only the right to take your address offline when an attack bothers the neighbours. Here is what protection is made of, how L3/L4 differs from L7, and how to tell from the contract what you are buying.
A DDoS attack is a flood of requests from many machines meant to overload a server or its link so that real visitors cannot reach it. Protection against it is built on the host's network or at an external filtering provider: suspicious traffic is separated from normal traffic and dropped before it reaches the server. The server itself cannot cope with a large attack: once the link to it is full, no settings inside the system will help.
Attack layers: L3/L4 and L7
Attacks are classified by network-model layer, and each class is handled differently.
- Volumetric attacks (L3/L4) fill the link: so much traffic heads for the server that its port or the data centre's upstream links are saturated. Their size is measured in gigabits and terabits per second.
- Protocol attacks (L3/L4) exhaust not the link but the resources that track connections: firewall state tables, the queue of new TCP connections. They are measured in packets per second (pps, Mpps). Some of them are also handled on the server itself, for example with SYN cookies (RFC 4987).
- Application attacks (L7) look like ordinary HTTP requests to a site or API: search, cart and login pages. The link stays almost idle while the web server or database goes down. They are measured in requests per second (rps) and are told apart from visitors by behaviour, not volume.
L3/L4 network filtering is what hosts usually switch on for every customer. L7 protection is harder: the filter has to understand your site, see the contents of HTTPS requests and tell a visitor from a bot. That is why it is more often sold separately, connected through a proxy holding your certificate, or left to the site side: a CDN, a WAF, request rate limits in the web server.
"Protection enabled" versus real filtering
According to the accsly catalog as of 3 November 2026, 1,117 of the 2,236 hosts with VPS plans claim DDoS protection, exactly half. Details could be found for 219 hosts in the catalog, and the picture is mixed:
- 35 hosts state the filtering capacity in Gbps or Tbps;
- 24 state the protection layer (L3/L4 or L7);
- 8 mention L7, and for half of them it is paid or enabled on request;
- in roughly a quarter of the cases protection is a separate paid option, and in roughly another quarter it is explicitly included in the price.
The rest keep it short: "yes", "claimed", "built-in network protection". That is not necessarily bad, but such a phrase does not tell you what will happen during an attack. Three different things hide behind the same words:
- Always-on filtering. All traffic always passes through the filter. An attack is cut off at once, but the filter sometimes catches normal traffic too, for example game protocols over UDP.
- On-demand filtering. The system watches traffic and turns scrubbing on when the flow crosses a threshold. Seconds or minutes pass between the start of an attack and the filter kicking in, and the server may be unreachable during that time.
- Blackhole only. There is no real scrubbing: during an attack the host's network simply stops passing traffic to your address. That protects the neighbours and the host, but not you.
Threshold and blackhole
Every protection has a limit: a volume or packet rate beyond which the host stops filtering. The rules usually say something like "for attacks above N Gbps the address may be temporarily taken offline". This is done with a blackhole: the operator tells neighbouring networks to drop traffic to your address. BGP has a standard BLACKHOLE community for this (RFC 7999), and where possible exactly one address is taken offline, a /32 for IPv4 or a /128 for IPv6, so that neighbours are not affected.
For the server owner this means a simple thing: the attack reaches its goal, just on the network rather than on your server. The address is unreachable for everyone until the blackhole is lifted, and the duration differs between hosts, so look for it in the rules too. If the project cannot survive such downtime, the filtering threshold must be well above the attacks you realistically expect, and the site should have additional L7 protection in front of it.
One more detail is the port. On a plan with a 100 Mbps port even a small attack fills it completely, and the host's filter has to cut it off before it reaches your port. How to read port speed and shared links is covered in Bandwidth and traffic: what 1 Gbps and unlimited really mean.
What to ask the host and check in the contract
- Layers. Only L3/L4, or L7 as well? If L7, how is it connected: through a proxy, by changing DNS, with or without your certificate.
- Capacity. How many Gbps and how many million packets per second the filter handles per address, not for the whole network.
- Mode. Is filtering always on or triggered by a threshold, and how long does it take to kick in.
- Beyond the threshold. Is the address taken offline, for how long, can it be brought back sooner, and what does an upgrade to higher protection cost.
- Where the filter sits. In the data centre itself or at an external provider; does protection cover all the host's locations — sometimes it exists in only one city.
- Price and terms. Is protection included in the plan or a separately paid option, and is there a charge per mitigated attack.
- Liability. Does attack time count towards the availability SLA. Often it does not: the rules exclude attacks from the guarantee.
Get the answers in writing, in a support ticket: if the host's website says little, these are your terms. General tips on reading a plan are in How to read hosting plans: the hidden limits.
What to do yourself
Even with good protection from the host, part of the work stays on your side:
- close everything except the ports you need with a firewall and enable SYN cookies — most Linux distributions already have them on; the basic setup is described in First 10 steps after buying a VPS: security;
- for a site, rate-limit requests to heavy pages (search, login, cart) right in the web server and put a CDN with L7 protection in front of the site;
- if the site is behind a CDN or proxy, do not publish the server's direct address in DNS or in emails, otherwise traffic will go around the filter;
- watch availability from outside to learn about an attack before visitors do — see Server monitoring: uptime, load, alerts;
- keep a fresh backup and a moving plan: if the host cannot cope, the project can be brought up elsewhere.
Plans where protection is included in the price are collected in VPS with DDoS protection. Game servers need protection more often than others, usually L3/L4 for UDP: see VPS for a game server and dedicated servers for games.