There are two kinds of flood. One clogs the network pipe with sheer volume. The other sends valid-looking requests that exhaust the application. Different defences stop each, and "free DDoS protection" often only means the first.
The layers, and what each stops
| Layer | Attack it stops | Who usually provides it |
|---|---|---|
| Network filtering (L3/L4) | Volume floods: UDP, SYN, amplification | The host or its upstream, often included |
| Application firewall (L7 WAF) | Floods of real-looking HTTP requests, bad bots, exploit probes | A CDN or a paid add-on |
| Rate limiting and challenge pages | Scrapers and low-and-slow request floods | A CDN, or the app itself |
The null-route problem
When a volumetric attack is aimed at one IP and the host cannot filter it cost-effectively, a common response is to null-route that IP: drop all traffic to it, attack and visitors alike, for an hour or more. Your site is down, which is exactly what the attacker wanted.
Check the acceptable use policy. If it says the host may null-route an address under attack, your "protection" has a trapdoor. Hosts with real mitigation filter the attack and keep you online; that capability is worth paying for if uptime matters.
Putting a CDN in front changes the picture. Your origin IP is hidden behind the CDN, volumetric traffic is absorbed by a much larger network, and you get a WAF and challenge pages for the application-layer stuff. For most sites this is the practical DDoS answer, and the common providers include it on the free tier.
Game servers and app APIs are different
Running on UDP or custom ports, they cannot hide behind a normal web CDN. What they need is always-on network filtering sized for that kind of traffic, from a host that specialises in it. General web-host DDoS protection does not cover a game port.
What to check
- Network-layer filtering included, with a stated capacity
- No clause that lets the host null-route you during an attack
- A WAF available, from the host or via a CDN you can put in front
- The ability to hide your origin IP behind that CDN
- For game or API hosting: always-on filtering built for UDP and custom ports
- A status page and a support channel that answers during an incident
Milon Khan · Link Building & Digital PR Lead
Read the acceptable use policy before you buy, not after an incident. The line that matters is what the host does when an attack is aimed at you: filter it, or drop your traffic. If it is drop, put a CDN in front from day one so your real IP is never the target.
Illustrative example
Knocked offline by the "protection"
A small site catches a modest attack. The host, whose page advertised free DDoS protection, null-routes the address for two hours to shield the rest of its network. The site is dark the whole time, then it happens twice more that week.
Behind a CDN, the origin IP was hidden, the volume was soaked up on a much bigger network, and a firewall took care of the request-level noise. The attacker kept trying. The site stayed up.