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
They cannot hide behind a normal web CDN, and they run on UDP or custom ports. They need always-on network filtering sized for that 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
A site taken offline by its own host
Picture a small site that gets a modest attack. The "free DDoS protection" host null-routes the IP for two hours to protect its wider network. The site is down the whole time, and it happens twice more that week.
Moving the site behind a CDN hid the origin, absorbed the volume on a large network, and added a firewall for the request-level noise. The attacks continued and the site stayed up.



