A distributed denial-of-service (DDoS) attack tries to make your website unavailable by overwhelming it with traffic — so much traffic, or so many requests, that legitimate visitors cannot get through. It is one of the few attacks where the target does not need to have a vulnerability: the site can be perfectly patched and still go down.
DDoS protection is widely sold and widely misunderstood. This guide explains the types of attack, how mitigation works, and — most importantly — what it cannot do.
The three kinds of DDoS attack
Attacks are usually grouped by the layer they target:
Volumetric attacks (Layers 3/4)
The attacker floods the network with traffic — UDP floods, ICMP floods, DNS amplification — aiming to saturate the connection itself. The goal is to fill the pipe so nothing else gets through. These are measured in gigabits or terabits per second, and the largest recorded attacks are now measured in tens of terabits. No single server can absorb that; only a large distributed network can.
Protocol attacks (Layers 3/4)
These exploit the way network protocols work rather than raw volume: SYN floods that exhaust a server’s connection table, fragmented packet attacks, or Ping of Death-style malformed packets. They use less bandwidth than volumetric attacks but can still take a server offline by exhausting a specific resource.
Application-layer attacks (Layer 7)
These target the application itself: HTTP floods that request pages as fast as possible, Slowloris attacks that open many connections and hold them open, cache-busting requests that force the server to generate every page from scratch, and attacks on expensive endpoints such as search or login. They can be devastating at relatively low bandwidth, because each request forces real work — a database query, a page render, a login attempt. A few thousand well-chosen requests per second can be worse than a gigabit flood.
DNS attacks are a related category: floods of DNS queries, including random-subdomain (“water torture”) attacks designed to exhaust the DNS resolver.
How mitigation works
Effective DDoS protection works in layers, and each layer handles a different kind of attack:
Edge absorption. Traffic is routed through a large, distributed anycast network — Cloudflare’s network, for example, is described as providing unmetered, unlimited DDoS protection at Layers 3, 4, and 7 to all customers, with mitigation handled by its Autonomous Edge. The network’s capacity absorbs volumetric floods before they reach your server. Your origin server never sees the bulk of the attack.
Automatic detection and rulesets. Managed rulesets identify known attack patterns — SYN floods, DNS amplification, HTTP floods, Slowloris, botnet traffic — and block or challenge them. Adaptive protection learns your site’s normal traffic patterns and adjusts to them, which helps against attacks that mimic legitimate traffic.
Rate limiting and connection controls. At the application layer, rate limiting caps how many requests a single client can make, and web application firewall (WAF) rules block known malicious patterns. These run at the edge, before requests reach your origin.
Caching. A CDN caches static content at the edge, so repeated requests for the same page do not reach your server at all. Cache-busting attacks try to defeat this by requesting unique URLs; mitigation rules can detect that pattern and challenge it.
Origin hardening. Even with edge protection, the origin server should not be directly reachable: firewall rules should accept traffic only from the protection service’s IP ranges, and the server’s real IP address should not be published in DNS. If attackers can find the origin IP, they can bypass the edge entirely.
Cloudflare reports that its automatic mitigation typically begins within seconds of detection, with no manual intervention and no caps on attack size or duration on its platform. That is a description of one provider’s service, not a universal guarantee — always check what your own provider actually offers.
What “DDoS protection included” may — and may not — mean
The phrase appears on many hosting plans, and it covers very different things:
Network-level filtering at the data centre (common): the provider’s upstream network drops obvious floods before they reach your server. This handles volumetric and protocol attacks reasonably well, up to the network’s capacity.
Application-layer protection (less common on basic plans): WAF rules, rate limiting, and bot management that understand HTTP traffic. Without this, an Layer 7 attack can pass straight through network filtering, because each individual request looks like legitimate traffic.
A named mitigation capacity or SLA (check the terms): some providers state a capacity or an availability commitment for mitigation; others simply say “DDoS protection” with no numbers, no SLA, and no remedy if it fails.
Ask your provider which layers are covered, whether there is a cap on mitigated traffic, whether mitigation is always on or triggered manually, and what happens if an attack exceeds the protection — is the site null-routed (taken offline deliberately to protect the network), and for how long? [TO BE CONFIRMED: what DDoS protection Offshore Hosting includes on each plan — confirm before publishing any such claim.]
The practical limits
This is the part that matters most:
Protection is not prevention. Mitigation reduces the impact of an attack; it does not make attacks impossible. A sufficiently large or novel attack can still degrade or interrupt service.
Layer 7 attacks are hard to distinguish from real traffic. An attacker that mimics legitimate users — real browsers, real-looking requests, distributed across many IPs — is difficult to block without also blocking real visitors. Aggressive mitigation can cause false positives: real customers challenged, blocked, or shown captcha pages.
Your application is still a bottleneck. Edge protection stops traffic that never reaches you, but it cannot fix an application that does one expensive database query per request, or a login endpoint with no rate limiting. Harden the application itself: cache aggressively, rate-limit expensive endpoints, and make sure a single request cannot consume disproportionate resources.
DNS and email can be attacked too. If your DNS is hosted on the same infrastructure as your site, a DNS flood can take both down. Separating DNS, and using a provider with its own DDoS protection for DNS, is part of the plan.
Origin exposure bypasses everything. If your server’s real IP leaks — through an old DNS record, a mail server header, or a subdomain that points directly at the origin — attackers can target it directly and ignore the edge entirely. Audit your DNS records for direct origin exposure.
Mitigation can cost you. Some providers charge for mitigation above a threshold, or null-route the target IP during a large attack. Read the terms before you need them, not during an incident — and read the SLA the way our guide to reading a hosting SLA and uptime claim explains.
DDoS protection is not security in general. It does not patch software, stop intrusion, prevent data theft, or authenticate email. Pair it with HTTPS (SSL certificates and HTTPS), email authentication (SPF, DKIM, and DMARC), and the rest of your security baseline.
What to do before an attack
Put a CDN or edge protection service in front of the site before you are attacked. Setting one up during an incident, while DNS is being changed and caches are cold, is far harder.
Hide the origin IP: proxy all DNS records, remove old records that point directly at the server, and firewall the origin to accept only the protection service’s traffic.
Enable caching for static content and rate-limit login, search, and form endpoints.
Keep a known-good backup off the server, and know how to restore it.
Have a communication plan: who decides to escalate, how customers are told, and where status updates are posted.
Monitor: set up alerts for traffic spikes and error rates, so you notice an attack in minutes, not hours.
During an attack
Stay calm and work the checklist: confirm it is an attack rather than a traffic spike or a broken deployment; check the protection service’s dashboard for what is being blocked; tighten rate limits on the affected endpoints; contact your hosting provider and ask what they are seeing upstream; and communicate with your users. Do not make infrastructure changes in the middle of an incident unless you have tested them — a wrong firewall rule can finish what the attacker started.
Key takeaways
DDoS attacks come in three kinds — volumetric, protocol, and application-layer — and each needs a different defence.
Edge networks absorb volume; WAF and rate limiting handle application-layer abuse; origin hardening closes the bypass.
“DDoS protection included” varies enormously: ask which layers are covered, whether there are caps, and what happens when protection is exceeded.
Application-layer attacks can look like legitimate traffic, and over-aggressive mitigation can block real users.
Protection is a layer, not a guarantee. Harden the application, hide the origin, cache aggressively, and have a plan before you need it.
Discovering your site has been hacked is a bad day that gets worse with the wrong first moves. This guide gives the order of operations: contain, preserve evidence, clean or rebuild, rotate every credential, and harden the site afterwards.
A 99.9% uptime claim allows about 43 minutes of downtime a month — but only if you know what counts, what is excluded, and how to claim. This guide decodes the SLA.
SPF, DKIM, and DMARC are three DNS records that prove your mail is really from you. This guide explains each one, the setup order, and the safe path to enforcement.