What is a DDoS attack? Host mitigation basics

A DDoS attack is a coordinated flood of fake traffic that makes a website, server, or network unavailable to real users. Good hosting does not magically stop it; it filters traffic upstream, absorbs bandwidth spikes, and gives you clear limits before an incident.

How a DDoS attack breaks hosting

A normal request asks your site for a page, image, API response, or login form. A DDoS attack sends hostile requests from many places at once, so the server, firewall, or network link spends capacity on traffic that should never reach the application.

The practical question is not whether a provider says DDoS protection. The practical question is where the bad traffic is stopped. A flood dropped at the network edge is a nuisance. A flood dropped by your PHP worker is still an outage.

For hosting buyers, the attack usually appears as slow pages, connection timeouts, failed checkouts, overloaded origin servers, or support replies saying the traffic looks abnormal. That is too late to learn the protection was mostly a label.

Volumetric, protocol, and app-layer attacks

DDoS is not one failure mode. Hosts mitigate different attack shapes with different tools, and the wrong layer leaves a very visible hole.

Volumetric attacks are the blunt instrument. They try to fill the pipe, so a small VPS cannot solve the problem alone. The host or CDN needs spare network capacity and a way to discard junk traffic before it touches your server.

Protocol attacks sit between bandwidth and application logic. They waste state in network equipment or the operating system. This is where provider firewalls, sensible kernel defaults, and upstream filtering matter more than another CPU upgrade.

App-layer attacks are quieter and uglier. They can look like normal HTTP traffic while pressing on the slowest part of your stack. Caching, WAF rules, rate limits, bot checks, and cheap static fallbacks often beat raw server size.

What hosts actually mitigate

Hosting mitigation usually has layers. A provider may offer a network filter, a firewall rule set, CDN integration, WAF controls, or an emergency null route. Those are not interchangeable.

• Network filtering keeps obvious floods away from the server.
• CDN or edge protection hides the origin and absorbs traffic closer to users.
• WAF and rate limits reduce expensive requests against the application.
• Origin hardening keeps the site useful when the edge is under pressure.
• Support escalation matters when automatic mitigation starts blocking real users.

Provider category matters. Cloudflare and Akamai sit naturally in the CDN and cloud protection lane. AWS and OVHcloud combine cloud or server infrastructure with edge and network controls. Hetzner is relevant when the question is server hosting and what upstream protection is included with the machine.

Do not compare those providers as if they sold the same object. A CDN-first provider protects traffic before the origin. A server-first provider protects the machine and its network path. Many real deployments need both, especially when the cheap plan is crowded.

Protection tiers to read before you buy

The painful part of DDoS mitigation is not the feature label. It is the exception list. Some plans protect only basic floods. Some require a paid tier for WAF rules. Some can filter traffic but still null route the service during severe abuse.

Read the plan page and support terms for coverage, activation, origin exposure, and false-positive handling. If the provider cannot explain those in plain language, assume you will be debugging during the outage.

For a brochure site, CDN caching and a hidden origin may be enough. For an API, game server, checkout, or login-heavy app, ask about application-aware limits and whether support can tune rules without breaking legitimate users.

When CDN protection helps, and when it does not

A CDN helps when visitors can reach cached pages, static assets, or proxied HTTP traffic without touching the origin. It also helps when the origin IP is not exposed in DNS history, email headers, old records, or hardcoded callbacks.

A CDN does less when attackers can hit the origin directly, when the target is non-HTTP traffic, or when the slow part of the application must run on every request. In those cases, the hosting plan and architecture still carry risk.

The practical setup is boring: put public web traffic behind the edge, lock the origin to edge ranges where possible, cache safe pages, rate-limit sensitive routes, and keep an emergency static page ready. Rent boring infrastructure. Outages have enough drama already.

How to choose a mitigation path

Choose edge-first protection when the site is public, mostly HTTP, and can benefit from caching. Compare Cloudflare and Akamai as CDN and cloud protection options, then check whether your origin host supports the same workflow.

Choose infrastructure-first protection when you run workloads that cannot be fully proxied. For VPS and dedicated servers, compare provider pages such as OVHcloud, Hetzner, and AWS for server context, locations, and plan families before you make the security decision.

Avoid a provider when mitigation is described only as unlimited protection with no explanation of traffic type, escalation path, or origin handling. Unlimited language is cheap. Incident behavior is the product.

Data freshness

HostScout keeps provider pages and plan context separate from article advice. This article uses the provider categories available at publication and avoids hardcoded prices, ratings, bandwidth claims, or SLA promises where the underlying protection terms change by plan.