A lot of hosting providers say they include DDoS protection. It's printed on the features page, mentioned in sales emails, and listed right next to "99.9% uptime" as if it's all equally guaranteed. But when an actual attack hits, the gap between real mitigation and a marketing checkbox becomes very clear, very fast.
So how do you tell the difference before you're in the middle of an outage? Here's what to actually look at.
What Real DDoS Protection at the Hosting Layer Looks Like
Genuine DDoS mitigation happens upstream, before malicious traffic ever touches your server. It works by inspecting traffic at the network edge, identifying attack patterns, and scrubbing out bad packets while passing clean traffic through.
The key question is: where does the protection actually sit? If a provider's protection only lives on the server itself, it's already too late. By the time attack traffic arrives at your server's network interface, your bandwidth is already consumed. The server is trying to process junk it should never have seen.
Good DDoS protection hosting routes traffic through a scrubbing layer before it hits the server. This can mean on-premise scrubbing centers, upstream filtering at the data center level, or integration with a purpose-built mitigation network. The exact implementation varies, but the principle is the same: stop the attack upstream.
Questions to Ask Any Hosting Provider
Marketing pages won't tell you what you need to know. These questions will.
What is the total mitigation capacity?
Modern volumetric attacks can exceed 1 Tbps. If a provider can't tell you their mitigation capacity in concrete numbers, that's a red flag. Phrases like "enterprise-grade protection" without specifics mean nothing. Look for providers who cite actual throughput figures, even if they're in the hundreds of Gbps range.
Is mitigation always on, or does it activate after detection?
Some providers use "reactive" mitigation, where protection only kicks in once an attack is detected. That detection window, even if it's just a few minutes, can be enough to bring down a site. Always-on filtering is significantly more reliable. Ask directly: is traffic always being inspected, or only during an active attack?
What happens to legitimate traffic during mitigation?
Some DDoS defenses are blunt instruments. They block entire IP ranges or geographies to stop an attack, taking out real users alongside the bad traffic. Ask whether their mitigation distinguishes between attack traffic and real visitors, and how.
Does protection cover Layer 7 as well as Layer 3/4?
Volumetric (network-layer) attacks are the most common type, but application-layer attacks are harder to stop and increasingly common. We've covered why in detail in Application-Layer DDoS Attacks: Why They're Harder to Stop Than Simple Floods. If a provider only mentions bandwidth or packet-per-second limits, they may not be equipped to handle HTTP floods targeting your application logic.
The Marketing Language to Watch Out For
Here are some phrases that sound reassuring but don't actually tell you much:
- "DDoS protection included" - Included how? At what capacity? On what layer?
- "We monitor for DDoS attacks 24/7" - Monitoring is not the same as mitigation. Knowing you're under attack doesn't stop it.
- "Protected by enterprise-grade infrastructure" - This means nothing without specifics.
- "Your server is protected against DDoS" - If the protection only exists at the server level, it's largely useless against large-scale attacks.
- "We have never experienced a major DDoS outage" - This might mean they have great protection. It might also mean they haven't been targeted yet.
How to Verify Protection Without Waiting for an Attack
Check the data center's upstream providers
A hosting provider is only as protected as their upstream network. Look up who they peer with and whether their data center partners have published DDoS mitigation capabilities. Providers using Tier 1 carriers or well-known scrubbing networks like those run by Cloudflare, Akamai, or Radware are generally in better shape than those routing through smaller regional networks.
Look at their SLA language
A provider that takes DDoS protection seriously will include it in their service level agreement, not just their marketing page. If the SLA says nothing about attack mitigation, or if it explicitly excludes DDoS as a covered outage cause, take that seriously. It tells you where the accountability actually sits.
Ask about null-routing policy
Many providers respond to large DDoS attacks by null-routing the targeted IP, which means they effectively take your site offline themselves to protect the rest of their infrastructure. This is a legitimate practice at some level, but it matters a lot when and how it happens. Ask: at what attack volume do you null-route? For how long? Is there any alternative path for legitimate traffic during that period?
Search for historical incidents
Look at the provider's status page history, their community forums, and independent hosting review sites. Search for posts about DDoS outages. A provider with real mitigation will have incidents, but they'll resolve quickly. A provider relying on null-routing will show extended outages whenever a customer gets targeted.
How DDoS Protection Fits Into Your Broader Security Stack
Even great DDoS protection at the hosting level doesn't replace other security layers. An application firewall (WAF) handles different threats, like SQL injection and credential stuffing, that a DDoS filter isn't designed to catch. For details on how those two layers work together, see Why Layered Website Security Protection Beats Any Single Tool Every Time.
The point of DDoS protection hosting is to keep your site reachable during a flood. The WAF handles malicious requests that get through. Backups and monitoring cover recovery if something does go wrong. These aren't competing tools - they're complementary ones.
When we configure DDoS mitigation for servers here, it operates upstream at the network level so attack traffic is filtered before it reaches the server's bandwidth. We also combine that with application-layer filtering so that low-volume but targeted HTTP floods don't slip through. You can read more about how that architecture works on our DDoS protection overview.
The Bottom Line
Don't take "DDoS protection included" at face value. The difference between a host that blocks attacks and one that just watches them happen can mean hours of downtime, lost revenue, and a damaged reputation.
Ask specific questions. Read the SLA. Check the data center's upstream network. And look at what actually happens when a customer gets hit, not what the marketing page promises will happen.
Real protection is verifiable. If a provider can't give you straight answers about their mitigation capacity, architecture, and null-routing policy, that tells you something important.
