Having extensively load-tested our global API (Rust/Actix on Fly.io) behind Cloudflare’s proxy, I’ve observed a non-trivial incidence of false positives with their managed DDoS rulesets, particularly under rapid, legitimate traffic bursts. The core issue appears to be the heuristic and threshold-based nature of these rules, which can conflate aggressive but benign client behavior with attack patterns.
My team’s incident last quarter is illustrative. We launched a feature triggering synchronous, cache-miss-heavy requests from our mobile clients. Traffic increased by ~400% over two minutes. Cloudflare’s HTTP DDoS Managed Ruleset (specifically rule `100035B`) began issuing JS challenges and blocks to a segment of users, correlating with our 95th percentile latency spiking from 85ms to over 2 seconds. The mitigation was triggered by the request rate threshold, despite the traffic being geographically distributed and from authenticated sources.
Our subsequent analysis, comparing request logs from our origin against Cloudflare’s firewall events, revealed the following configuration nuances that contributed to the problem:
* **The default sensitivity of the "Super High" sensitivity level** is, unsurprisingly, very high. It's designed for outright attack scenarios, not for legitimate flash crowds.
* **Lack of granularity in rule actions.** Many rules are binary: either "block" or "JS challenge." There's often no intermediate "log only" mode for testing, forcing a production trial.
* **Thresholds are global across your zone** by default, not easily scoped to specific endpoints. A surge to `/api/v1/new-feature` can trigger mitigations affecting `/api/v1/login`.
We implemented a two-phase mitigation, which I detail for reproducibility:
1. **Rule tuning:** We overrode the default sensitivity for the relevant ruleset to "Medium" and used the `cf.client.bot` field in a custom rule to bypass DDoS protections for verified bots.
2. **Endpoint-specific exemptions:** We employed Cloudflare Transform Rules to add a custom header for known, high-volume but legitimate endpoints, then created a firewall rule to skip DDoS evaluation for requests containing that header.
```sql
# Example Firewall Rule to bypass DDoS managed rules for specific paths
(http.request.uri.path matches "^/api/v1/feature-webhook/")
and (http.request.headers["x-internal-bypass-ddos"] eq "true")
-> skip
```
The outcome was a elimination of false positives for those patterns, though it required diligent monitoring to ensure we weren't simply carving a hole for a future attack. The trade-off between protection and availability is palpable.
My question to the community: have you conducted similar empirical analyses on Cloudflare's managed rules? I'm particularly interested in:
* Quantitative data on false positive rates under burst conditions.
* Strategies for safely lowering sensitivity while maintaining protection for truly malicious traffic.
* Experiences with the new Adaptive DDoS Protection tiers—do they offer better heuristic discrimination?
The vendor documentation is, as expected, optimistic. Real-world telemetry is far more valuable.
--perf
--perf
Thanks for sharing this detailed breakdown. Your point about the default sensitivity of the "Super High" profile is key - it's a setting I think many teams adopt without considering its global, one-size-fits-all nature. It applies that sensitivity across all your zones and routes, which can be overkill.
We faced a similar issue during a product launch last year. The solution for us was moving away from the broad managed rulesets and using the new Advanced DDoS Protection configurations to apply stricter rules only to our login endpoint and API paths that were actually sensitive. This let us keep more permissive settings elsewhere. It's a bit more work, but it prevented those blanket challenges on surge traffic from legitimate users.
Keep it constructive.
That specific scenario with the cache-miss storm triggering rule `100035B` is a classic, painful pattern. It hits right at the weakness of heuristics that can't distinguish between a coordinated attack and a swarm of legitimate, eager clients all hitting the same uncached resource at once.
One thing we did that helped alongside adjusting sensitivity was to implement a short, custom rate-limit at the Cloudflare level specifically for the feature launch paths, set slightly higher than we thought the traffic surge would create. It acted as a more predictable "bumper" that kept requests per second under the threshold where the DDoS heuristics would get spooked. It's a bit of a hack, using one tool to avoid triggering another, but it gave us the control we needed for that critical window.
Have you looked into whether the new Advanced DDoS configurations let you write an exception for that rule ID based on a request header from your authenticated mobile clients? That's on my list to test.
api first