Cloudflare mitigates DDoS attacks by sitting in front of your origin as a reverse proxy on a very large anycast network, sampling traffic out of path, generating a real-time fingerprint of the attack, and dropping matching packets at the edge closest to the attacker - so the flood never reaches your server. The part worth understanding is where that protection ends and what your own infrastructure still has to survive.
Most explanations stop at “Cloudflare absorbs the attack.” True, and it skips the mechanism that decides whether a given attack gets absorbed or lands on your origin anyway.
Table of contents
- Why anycast does most of the work
- Detection: sampling out of path
- Layer 3/4 versus layer 7
- What your origin still has to handle
- Where RunxBuild fits
- FAQ
Why anycast does most of the work
The single biggest factor is not clever software. It is that Cloudflare announces the same IP addresses from data centers in hundreds of cities, so a packet aimed at your site is routed to whichever location is nearest the sender.
An attacker with a botnet scattered across the world therefore hits hundreds of separate edges at once, not one server. The flood is divided by geography before any filtering happens. A volumetric attack that would flatten a single origin becomes a manageable slice of traffic at each of many points of presence.
This is why raw network capacity, measured in terabits per second, matters. It is the ceiling on how much junk can be spread thin before the thin slices still add up to trouble.
Detection: sampling out of path
Cloudflare does not inspect every packet inline - that would add latency to legitimate requests. Instead it samples traffic asynchronously, looking for the statistical shape of an attack: a spike in SYN packets, a sudden flood of identical requests, malformed headers, a protocol used abnormally.
When a sample matches a known attack pattern, the system generates a real-time signature, a fingerprint describing exactly what the bad packets look like. That fingerprint is then pushed as a mitigation rule to the optimal location on the network.
The effect is surgical: the rule matches the attack traffic and leaves legitimate requests alone, which is the difference between mitigation and simply turning the site off.
Layer 3/4 versus layer 7
Network-layer attacks (L3/L4) - UDP floods, SYN floods, amplification - are about raw volume and are the easiest for anycast plus fingerprinting to shed. They rarely touch your origin at all once proxied.
Application-layer attacks (L7) are harder. A flood of HTTP requests that each look almost legitimate - hitting a search endpoint, a login, a cart - is expensive to serve and hard to distinguish from a traffic surge. This is where rate limiting, bot detection, managed challenges, and a web application firewall come in, and where the defaults do less for you out of the box.
Knowing which layer an attack targets tells you which control actually helps.
What your origin still has to handle
Cloudflare protects the edge. It does not protect you from an attacker who knows your origin IP and connects to it directly, bypassing the proxy. If your server answers requests on its public address, the whole model leaks.
The fixes are unglamorous: firewall the origin so it only accepts connections from Cloudflare’s IP ranges, do not leak the real IP in DNS records, mail headers, or error pages, and keep the application efficient enough that a modest L7 flood that slips through does not exhaust memory or connections.
Mitigation at the edge buys time. An origin that falls over at 200 concurrent requests still falls over.
Where RunxBuild fits
A CDN in front of your app is one layer. The app behind it is another, and a slow or memory-hungry service makes every layer-7 attack cheaper for the attacker. On RunxBuild you deploy that service from a GitHub repo with runtime logs and metrics in one place, so you can see request patterns and resource use when something spikes.
Autoscaling between a floor and a ceiling plan gives the application headroom to ride out a surge rather than tipping over at a fixed limit - you set the bounds, it scales up around 80% CPU and back down at 20%. That does not replace edge DDoS protection, but it is the difference between a request flood that degrades gracefully and one that takes the service down.
How this fits the rest of the stack
The cost of a project is the sum of its line items, not the headline number, and the RunxBuild hosting calculator is the right place to add them up: the service, the database, the storage, the bandwidth, each a separate figure. Model it before committing, not after the first invoice. The RunxBuild dashboard is where the running project shows its real usage in one place.
Useful related references:
- DDoS protection with a CDN
- Protection against DDoS attacks
- WAF policy explained
- Services introduction
- Autoscaling
FAQ
Does Cloudflare stop all DDoS attacks automatically?
Volumetric network-layer attacks are handled automatically on every plan through anycast and fingerprinting. Application-layer floods often need extra configuration - rate limiting rules, bot management, or a WAF - because they resemble legitimate traffic and the automatic defaults are deliberately conservative to avoid blocking real users.
Can an attacker bypass Cloudflare?
Yes, if they discover your origin’s real IP address and connect to it directly. The defence is to firewall the origin so it only accepts traffic from Cloudflare’s published IP ranges and to avoid leaking the real IP through DNS history, email headers, or verbose error pages.
What is a DDoS fingerprint?
A real-time signature describing the precise characteristics of the attack traffic - packet size, flags, headers, timing. Once generated, it is distributed as a mitigation rule so matching packets are dropped at the edge while legitimate requests pass through untouched.
Is the free plan enough for DDoS protection?
For unmetered network-layer DDoS mitigation, the free plan is genuinely capable. The paid tiers add more application-layer controls, configurable rules, and analytics. The common mistake is assuming the free plan also protects an unfirewalled origin - it does not.
Does DDoS mitigation slow my site down?
No, because detection happens on sampled traffic out of path rather than inline, and the proxy usually sits closer to users than your origin, so the common case is slightly faster delivery, not slower.