A distributed denial-of-service attack does not try to break into anything. It tries to make a website unavailable by sending more traffic than the infrastructure can absorb, and the attacker does not need to be sophisticated to manage it — only well resourced.
Cloudflare’s answer is not a single filter. It is a set of defences operating at different layers of the network stack, most of them active by default before anyone configures anything. This article covers what those layers are, what happens to an attack as it passes through them, and where the default protection stops being enough.
What a DDoS Attack Targets
Attacks are usually described by which layer of the network they aim at, and the distinction matters because each is stopped by a different mechanism.
Volumetric attacks (Layer 3 and 4) flood the connection itself — traffic floods, amplification attacks, half-open connection floods. The goal is to saturate bandwidth or exhaust the connection table. These are the attacks measured in terabits per second.
Protocol attacks abuse the way connections are established, holding open unfinished handshakes until the server runs out of capacity to accept new ones.
Application-layer attacks (Layer 7) look like ordinary web traffic. They request real pages, often expensive ones such as a search endpoint or a report generator, at a rate the origin cannot sustain. They are far smaller in raw volume and far harder to separate from legitimate users.
A defence that absorbs a terabit-scale flood does nothing about a thousand well-formed requests hitting a database query endpoint. Both need covering.
The Layers of Mitigation
Cloudflare stacks several mechanisms, each handling a different part of the problem.
Anycast network distribution. The same address is announced from every Cloudflare location simultaneously, so an attack aimed at one address is split across the entire network rather than concentrating on one data centre. This is the structural reason large volumetric attacks get absorbed rather than blocked — there is no single point to overwhelm.
Automatic traffic fingerprinting. Traffic patterns are profiled continuously. When a signature matching known attack behaviour appears, mitigation rules are generated and deployed across the network without waiting for a human to approve them.
Rate limiting and connection controls. Abnormal request rates from a single source, or abnormal connection behaviour, are throttled at the edge.
Application-layer inspection. Requests that look legitimate but behave like automation are scored and challenged. This is where the web application firewall and bot detection overlap with denial-of-service defence.
Cached delivery during origin failure. If the origin does become unreachable, cached pages continue to serve, so the site stays visible while the incident is handled.
The important characteristic is that the first three operate before traffic reaches the origin server at all. Nothing has to scale on the customer’s side.
What Happens During an Attack
From the operator’s perspective, a well-mitigated attack is mostly uneventful.
Traffic arrives at the nearest Cloudflare locations and is distributed across the network. Detection systems identify the pattern within seconds and apply mitigation rules. Malicious traffic is dropped at the edge; legitimate visitors continue to be served, usually without noticing anything unusual.
The origin server sees roughly its normal traffic volume throughout, because the attack never reaches it. There is no scaling event, no emergency capacity purchase, and no outage to explain afterwards.
What the operator does see is the analytics: a spike in blocked requests, the attack vector identified, and a record of when mitigation engaged. For background on why this all happens at the edge rather than at your server, see How Does Cloudflare Work? A Plain-English Guide.
Where the Default Stops
Automatic protection handles volumetric and protocol attacks well. Three scenarios need deliberate configuration.
Application-layer attacks against specific endpoints. A login page, a search function, or an interface that performs expensive queries needs rate limiting rules written against it specifically. Generic protection does not know which of your URLs are costly to serve.
Slow-rate attacks. Traffic that stays under automatic thresholds but sustains pressure over hours requires custom rules to catch, because no individual moment looks abnormal.
Attacks that arrive as valid business logic. Cart flooding, inventory scraping, and credential stuffing are denial-of-service in effect but indistinguishable from customers by volume alone. Bot scoring and behavioural rules handle them, and the web application firewall is where those rules live. Default settings do not cover this.
Configuring these is the difference between protection that holds and protection that mostly holds.
Frequently Asked Questions
No. Mitigation happens at the same edge locations that already serve cached content, so inspection adds negligible latency. Visitors are generally unaware that an attack is in progress.
Unmetered volumetric protection is included on every plan. What differs is the depth of application-layer controls, the granularity of custom rules, the attack analytics you can review afterwards, and whether a response commitment is attached.
For volumetric and protocol attacks, no — mitigation engages automatically. Application-layer attacks may need rules tuned while the incident is running, which is why having the configuration prepared in advance matters more than reacting quickly.
When Default Protection Is Not the Whole Answer
Volumetric protection works out of the box on any plan, and for a small site that is often sufficient. What a business needs beyond that is application-layer rules written against its own endpoints, attack analytics it can hand to an insurer or a board, and a response commitment when something is actively going wrong.
ANP Technology configures Cloudflare Enterprise deployments — sizing protection against real traffic and risk, writing the endpoint-specific rules, and staying involved while an incident runs.
