If you need to know how to fix Cloudflare WAF not working, the issue is usually not the firewall engine itself but a routing, rule, or mode mismatch somewhere in your stack.
This guide walks through the most common causes and the exact checks that restore Cloudflare Web Application Firewall protection.
What Cloudflare WAF actually does
Cloudflare WAF is part of the broader Cloudflare security platform and helps inspect HTTP and HTTPS traffic at the edge before it reaches your origin server.
It relies on managed rules, custom WAF rules, firewall rules, bot controls, and security features such as rate limiting, JavaScript challenges, and threat intelligence signals.
When WAF appears to stop working, the problem usually falls into one of these categories: the traffic is bypassing Cloudflare, the rule is not matching, the security setting is too permissive, or another Cloudflare feature is overriding the expected action.
Confirm traffic is actually going through Cloudflare
The first step in figuring out how to fix Cloudflare WAF not working is verifying that requests are proxied through Cloudflare.
If DNS is set to DNS only, the orange cloud is off, or users are reaching your origin IP directly, the WAF cannot inspect that traffic.
Check these basics
- In the Cloudflare dashboard, confirm the DNS record is proxied.
- Verify the public DNS record resolves to Cloudflare IPs, not your origin IP.
- Block direct access to the origin server where possible.
- Test from an external network, not just inside your own infrastructure.
You can also inspect response headers such as cf-ray or server: cloudflare.
If those headers are missing, the request may not be passing through Cloudflare at all.
Review WAF mode and security settings
Cloudflare offers several security layers, and some are easy to confuse.
The WAF may seem inactive if the configuration is set to logging only, if thresholds are too relaxed, or if a feature is disabled for the zone.
Check the security posture
- Make sure the relevant WAF managed ruleset is enabled.
- Confirm the security level is not set so low that obvious attacks pass through.
- Review whether Super Bot Fight Mode, bot management, or rate limiting is masking the expected WAF behavior.
- Look for exceptions, allowlists, or skip rules that bypass inspection.
On Cloudflare, a single skip action can override multiple security layers.
If a rule is designed to skip WAF for certain paths, IP addresses, or user agents, the firewall may be working exactly as configured while still appearing ineffective.
Check whether the rule actually matches the request
A very common reason people search for how to fix Cloudflare WAF not working is that the rule exists but never matches live traffic.
This happens when the condition is too narrow, uses the wrong field, or targets a request pattern that changed.
Common matching problems
- The URI path is different from what you expected.
- The method is POST, but the rule only checks GET traffic.
- The host header or subdomain is not included in the filter.
- The rule uses a country, ASN, or IP range that no longer applies.
- The user agent or query-string condition is too specific.
Use Cloudflare firewall events or security analytics to review whether the request triggered the rule.
If there is no event, the rule likely never matched.
If there is an event but no block, the configured action may be different from what you intended.
Inspect rule priority and conflicts
Cloudflare evaluates security logic in layers, and rule order matters.
A later block rule can be neutralized by an earlier allow rule, while a skip rule can prevent a managed WAF rule from running at all.
This is especially important in environments with multiple administrators or inherited templates.
What to review
- Custom WAF rules
- Firewall rules
- IP Access rules
- Page Rules or Redirect Rules that alter request flow
- Transform Rules that change headers or paths before inspection
If you recently added a new rule, test whether a broader allowlist or bypass rule already exists.
The most specific rule is not always the one that wins.
Verify managed ruleset status and sensitivity
Cloudflare managed rules are designed to catch common attacks such as SQL injection, cross-site scripting, remote file inclusion, and protocol abuse.
If the managed ruleset is disabled, in log mode, or tuned too loosely, malicious requests may pass through.
Look for these issues
- Managed ruleset not deployed to the zone
- Rule action set to log instead of block
- Exclusions that skip critical inspection points
- False-positive tuning that suppresses too much traffic
Review any exclusions carefully.
An exclusion added to solve one false positive can create a permanent blind spot if it applies to an entire path, parameter, or application segment.
Test with known bad payloads and expected events
To move from guesswork to evidence, test with safe, controlled requests that should trigger the WAF.
Use a staging environment when possible, and compare the Cloudflare event log against origin logs.
Useful validation steps
- Send a request containing a benign pattern that matches a managed rule signature.
- Check whether the action is block, challenge, or log.
- Compare edge events to origin server access logs.
- Confirm the response code and security event ID.
If Cloudflare shows a security event but the origin still receives the request, you may be testing against a bypass path, an origin exposure issue, or a separate hostname not covered by the same rules.
Check SSL/TLS and origin configuration
Sometimes the WAF is not the real problem.
SSL/TLS settings, origin certificates, and proxy behavior can affect whether traffic is visible to Cloudflare in the first place.
Misconfigured TLS can also cause fallback behavior that makes the site appear partially protected.
Review the transport layer
- Use a valid Cloudflare SSL/TLS mode for your setup.
- Confirm the origin certificate or public certificate is valid.
- Avoid mixed proxy and direct-origin access for the same application.
- Ensure load balancers and reverse proxies preserve the correct host and client IP headers.
If your origin or upstream proxy strips headers such as CF-Connecting-IP or X-Forwarded-For, downstream logging can become misleading, making it look like the WAF missed the attack when the request was actually intercepted at the edge.
Look for application-specific bypasses
Modern applications often include paths that bypass normal request handling, such as API gateways, file upload endpoints, health checks, or third-party integrations.
These can create the impression that the WAF is failing when the traffic is simply traveling through a different path.
Examples of bypass-prone areas
- API subdomains with separate DNS records
- Webhook endpoints whitelisted for partners
- Health check URLs excluded from security inspection
- Legacy domains still pointing to the origin
Inventory every hostname and route that serves the application.
In many cases, one forgotten subdomain or direct origin endpoint is enough to undermine the security posture of the entire site.
Use logs and analytics to isolate the root cause
Cloudflare Security Events, Firewall Analytics, and Logpush data provide the clearest view of what the edge saw and how it responded.
These tools help separate configuration problems from traffic patterns and application changes.
Focus on these signals
- Matching rule ID and rule name
- Action taken by Cloudflare
- Client IP and country
- Requested host, path, and method
- Whether a bypass, skip, or allow action occurred first
For larger environments, exporting logs to SIEM platforms such as Splunk, Datadog, or Elastic can help correlate WAF events with application behavior and incident timelines.
When to escalate to Cloudflare support
If you have confirmed proxying, verified rule matching, removed conflicting bypasses, and still cannot get the WAF to respond correctly, the issue may involve a zone-level anomaly or product-specific limitation.
At that point, Cloudflare support can review event IDs, configuration state, and zone metadata.
Have this information ready?
- Zone name and affected hostname
- Timestamp of the failed block
- Relevant Security Event IDs
- Rule names and actions
- Any recent configuration changes
A clean audit trail makes it much faster to determine whether the problem is a misconfiguration, an expected bypass, or a platform-side issue.
Best practices to prevent WAF failures
Once you restore protection, the goal is to keep the setup consistent and observable.
The strongest Cloudflare deployments treat the WAF as part of a broader security workflow rather than a one-time setup.
- Document every bypass and exception with an owner and expiration date.
- Review rule changes after application releases.
- Monitor logs for traffic hitting unprotected hostnames or paths.
- Test managed rules after major Cloudflare or application updates.
- Restrict direct origin access with firewall rules or authenticated origin pulls.
With the right checks in place, how to fix Cloudflare WAF not working becomes a repeatable troubleshooting process: verify proxying, confirm matching, remove conflicts, validate logs, and close direct access paths.