← All products

DDoS Protection

Cloudflare DDoS Protection applies automatic detection and mitigation for network-layer and application-layer denial-of-service attacks on traffic that transits the Cloudflare network. This page documents the mitigation path, configuration objects, constraints and plan availability.

Document control

Dana
Technical writer, Integrity Czech Republic s.r.o.

Overview

A distributed denial-of-service attack attempts to make a service unavailable by saturating a resource: link capacity, packet processing, connection state or application concurrency. Attacks are commonly grouped by layer. Network-layer attacks (L3 and L4) target bandwidth and packet handling. Application-layer attacks (L7) issue HTTP requests that are individually well formed and exhaust origin compute or backend dependencies.

Cloudflare mitigates attacks against traffic that reaches its network, either because a hostname is proxied through Cloudflare, because prefixes are announced through Magic Transit, or because a TCP or UDP application is fronted by Spectrum. Traffic that reaches the origin by another path is not mitigated.

Cloudflare states that DDoS mitigation is provided without metering by attack size or frequency on all plans (https://developers.cloudflare.com/ddos-protection/, retrieved 2026-08-28). This describes billing for mitigation, not a guarantee of availability under arbitrary load.

Cloudflare does not publish a network capacity figure in terabits per second on its public network page (retrieved 2026-08-28). Where a capacity commitment is required, obtain it in the contract rather than from documentation.

Architecture

Cloudflare announces the same IP prefixes from its data centres using anycast. Each source is routed to a nearby announcing location, so a geographically distributed attack is divided across many locations instead of converging on one scrubbing site. Mitigation therefore happens in a distributed manner near the sources, and mitigation capacity is the aggregate of the participating locations rather than the capacity of a single site.

At each location, sampling systems compare packet and request characteristics against attack fingerprints in the managed DDoS rulesets and against traffic profiles. When a signature matches, a mitigation rule is applied to the data path. Network-layer mitigation is enforced in packet filters. Application-layer mitigation is enforced by the HTTP DDoS Attack Protection managed ruleset, which can block or challenge matching requests.

Mitigation is autonomous: it is applied by the platform without a customer action or a support request. Cloudflare describes detection and mitigation as beginning automatically and does not publish a guaranteed time to mitigate.

Three delivery models exist and they differ materially:

• Reverse proxy. HTTP and HTTPS traffic for proxied hostnames. Mitigation applies to requests, and the origin address is not exposed in DNS.
• Spectrum. Arbitrary TCP or UDP applications proxied through Cloudflare, for services such as mail, game protocols or VoIP signalling.
• Magic Transit. Customer-owned IP prefixes announced by Cloudflare via BGP, with clean traffic returned to the customer network over GRE, IPsec or CNI. This protects entire networks, including non-HTTP infrastructure.

Capabilities

Configuration model

DDoS protection is delivered as managed rulesets in the ruleset engine, in the same model used by the WAF. Individual rules are vendor-maintained and are not editable. Behaviour is adjusted with overrides.

Two override dimensions exist. Sensitivity controls how readily a rule triggers, with levels typically expressed as default, medium, low and essentially off. Action controls what happens on a match, for example block, managed challenge or a lighter mitigation. Overrides can be applied at ruleset level, at rule level, or scoped by expression where the plan supports it.

Adaptive DDoS Protection is configured separately and profiles traffic by dimension, for example by client country, ASN, user agent or a defined origin group. It is deployed in a monitoring posture first and then switched to enforcement.

For Magic Transit, configuration includes prefix onboarding and BGP announcement control, tunnel configuration for clean-traffic return, and Magic Firewall rules for network-layer filtering. For Spectrum, configuration includes the application definition, origin address, protocol and port.

All of these objects are manageable through the dashboard, the API and the Terraform provider.

Limits and constraints

Values and entitlements below are from Cloudflare documentation retrieved 2026-08-28 and change without notice.

• Mitigation applies only to traffic that transits Cloudflare. A reachable origin IP address, an unproxied hostname, or a service on a port not covered by the zone or Spectrum application remains directly exposed.
• Standard zone protection covers HTTP and HTTPS. Non-HTTP protocols require Spectrum, and whole-network protection requires Magic Transit. Both are Enterprise products.
• Adaptive DDoS Protection requires Enterprise with the Advanced DDoS Protection subscription; it is not part of the baseline entitlement on any plan.
• Override granularity for the HTTP DDoS managed ruleset is plan dependent. Free zones have the most limited control, which constrains tuning for false positives.
• DDoS rules operate on traffic patterns. Application-layer attacks that stay within normal request rates but exhaust an expensive backend may not be mitigated by DDoS rules; those require rate limiting rules, caching or application changes.
• Cloudflare publishes neither a guaranteed time to mitigate nor a network capacity figure. Availability commitments come from the contract and the applicable service level agreement, not from product documentation.
• Magic Transit imposes minimum prefix size requirements for BGP announcement and requires the customer to control the announced address space. Confirm the current minimum with Cloudflare before planning an address migration.
• Analytics retention and the availability of Logpush for attack data differ by plan.

Plan availability

Deployment

Prerequisites.

• Enumerate public hostnames, public IP addresses, announced prefixes, exposed ports and non-HTTP services such as mail, VPN endpoints and management interfaces.
• Record which of those are in scope for proxying, which require Spectrum, and which require Magic Transit.
• Search for existing origin IP disclosure: certificate transparency logs, historical DNS records, mail headers originating from the same host, error pages that reveal a hostname, and default virtual hosts that answer on the IP address.
• Document the integrations that must keep working during and after cutover: monitoring, payment callbacks, partner APIs and inbound webhooks.
• Record the current DNS configuration and TTLs so that the change can be reversed.

Staged validation. Onboard a representative non-production zone or hostname first. Verify that proxying does not alter application behaviour, that client IP addresses are read from the correct header, and that TLS settings match the origin capability. Generate representative load and confirm that legitimate traffic is not challenged.

Configuration.

1. Proxy the hostnames in scope, or announce prefixes through Magic Transit, or define Spectrum applications for non-HTTP services.
2. Rotate origin IP addresses so that previously published addresses no longer serve the application.
3. Restrict the origin firewall to accept traffic only from Cloudflare IP ranges (https://www.cloudflare.com/ips/), or remove inbound exposure entirely by connecting the origin with Cloudflare Tunnel.
4. Enable Authenticated Origin Pulls so that the origin rejects connections that do not present the Cloudflare client certificate.
5. Review the HTTP DDoS managed ruleset overrides. Leave default sensitivity in place unless a specific false positive is observed.
6. Where Advanced DDoS Protection is licensed, deploy Adaptive DDoS Protection in monitoring mode before enforcing it.

Cutover. Lower DNS TTLs in advance, switch traffic during an agreed window, and keep the previous origin path available but firewalled until verification completes.

Verification.

• Confirm from an external network that the origin IP address no longer answers the application on ports 80 and 443.
• Confirm that monitoring, payment callbacks and partner integrations still succeed, checked in their own logs.
• Confirm that attack notifications reach the intended channel by triggering a test notification.
• Confirm that origin logs record the client IP address correctly after proxying.

Rollback. Restore the previous DNS records or withdraw the BGP announcement, re-open the origin firewall to the previous source ranges, and confirm resolution and reachability before closing the incident. Because rollback re-exposes the origin address, treat it as a temporary state and repeat the address rotation before the next attempt.

Operational considerations

Configure attack alerts to a channel that is monitored outside business hours, and agree an incident runbook that names who may change ruleset overrides during an attack. Overrides changed under pressure are a common source of prolonged incidents.

During an attack, distinguish between mitigated traffic and origin impact. A high mitigation count with stable origin latency indicates the mitigation is working. Origin impact with low mitigation counts usually indicates either a bypass path or an attack that resembles legitimate traffic and needs rate limiting or caching rather than DDoS rules.

Keep the origin lockdown current. Cloudflare IP ranges change; subscribe to the published ranges and automate firewall updates, or use Cloudflare Tunnel to remove the dependency on address lists.

Retain post-incident reports and correlate them with origin metrics. Where Logpush is available, export the data rather than relying on dashboard retention.

Failure modes to plan for: an origin address rediscovered through a newly issued certificate, a non-proxied subdomain reintroduced by an automation script, a third-party integration blocked by a sensitivity override applied during an incident and never reverted, and mail infrastructure on the same address space as the web origin.

Known caveats

• Proxying does not make an origin address secret by itself. Origin addresses commonly leak through certificate transparency logs, historical DNS data, outbound mail headers, misconfigured virtual hosts and IPv4 scanning. Address rotation combined with an origin firewall restricted to Cloudflare ranges, or Cloudflare Tunnel, is what closes the path.
• Mail records must not be proxied. If mail and web share an address, rotating the web origin address without separating mail infrastructure leaves the address discoverable through mail headers.
• Adaptive protection is not part of the baseline product. It requires Enterprise with the Advanced DDoS Protection subscription.
• Application-layer attacks below rate thresholds are not a DDoS ruleset problem. Expensive search endpoints, unauthenticated report generation and uncached dynamic pages need rate limiting rules, caching or application-level controls.
• Mitigation actions can affect legitimate automation. Monitoring probes and machine clients cannot solve a challenge action.
• Unmetered mitigation is a billing statement. It is not a statement that any attack size will be absorbed without service impact.

Interoperability

DDoS managed rulesets, WAF rules and rate limiting rules all execute in the ruleset engine, in phase order. DDoS mitigation handles volumetric and fingerprintable floods; WAF and rate limiting handle targeted abuse of specific endpoints. The three are complementary and are usually configured together.

Bot Management fields can be referenced in custom rules to filter automated traffic that is below DDoS thresholds.

Cloudflare Tunnel removes inbound origin exposure entirely and therefore composes well with DDoS protection for origins that do not need to accept direct connections.

Magic Transit composes with Magic Firewall for network-layer policy and with Magic WAN for site connectivity. Spectrum composes with the same DDoS managed rulesets for non-HTTP protocols.

FAQ

Are non-HTTP services covered by a standard zone plan? No. A zone plan covers HTTP and HTTPS for proxied hostnames. TCP and UDP services require Spectrum, and whole networks require Magic Transit.

What is required for mitigation to apply to a service? The traffic must transit Cloudflare. That means a proxied DNS record, a Spectrum application, a Magic Transit announcement or a Cloudflare Tunnel. A DNS-only record does not receive mitigation.

How is a suspected bypass confirmed? Compare origin access logs against Cloudflare request counts for the same period. Requests present at the origin with source addresses outside the Cloudflare ranges indicate a direct path that must be closed at the origin firewall.

References

• https://developers.cloudflare.com/ddos-protection/, retrieved 2026-08-28.
• https://developers.cloudflare.com/ddos-protection/managed-rulesets/, retrieved 2026-08-28.
• https://developers.cloudflare.com/ddos-protection/managed-rulesets/adaptive-protection/, retrieved 2026-08-28.
• https://developers.cloudflare.com/magic-transit/, retrieved 2026-08-28.
• https://developers.cloudflare.com/spectrum/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/, retrieved 2026-08-31.
• https://www.cloudflare.com/ips/, retrieved 2026-08-28.
• https://www.cloudflare.com/network/, retrieved 2026-08-28.

Content snapshot: 2026-08-28.

Changelog