Skip to content

Rule phase interactions

Cloudflare evaluates request processing features in phases. A rule that appears correct in isolation can behave differently when another product has already modified or terminated the request.

Custom rules are evaluated against the rewritten URL

Cloudflare applies URL Rewrite Rules before custom rules.

If a transform rule rewrites /public-login to /internal/login, later WAF phases will evaluate the rewritten path.

This means that:

  • A custom rule matching /public-login may not fire after the rewrite.
  • A custom rule matching /internal/login may fire even though the visitor requested /public-login.

Resolution

When troubleshooting a custom rule, check whether a rewrite rule already changed the URL before WAF evaluation. You can use Trace to check the evaluation order of your rules based on an example request.

For more information, refer to the request execution order in Phases list.

IP Access rules can bypass custom rules

IP Access rules run before WAF custom rules.

If an IP Access rule with an Allow action matches a request, Cloudflare will not evaluate later custom rules for that request.

What this means

  • A custom rule may appear to "not fire" for a specific IP address even though the expression is correct.
  • Allowlisting a source IP address too early can prevent other app security logic from running (namely custom rules).

Resolution

If a request is unexpectedly bypassing a custom rule, check for matching IP Access rules first.

Skip and Allow do not behave the same way

The Allow action in IP Access rules has a different behavior from the Skip action available in WAF custom rules.

The Allow action in IP Access rules bypasses WAF custom rules, rate limiting rules, WAF Managed Rules (except for country-level entries), and deprecated firewall rules. Any matches do not appear in Security Events. An allowed request never reaches WAF custom rules, including any logging or tracking rules.

The Skip action in WAF custom rules instructs Cloudflare to selectively skip certain application security products or components, such as WAF managed rules. Depending on the configuration of the custom rule with the Skip action, other security products will still evaluate the request and might block it.

WAF custom rules do not have an Allow action. To control what a matching request bypasses, you must use the Skip action and select the specific products or phases to skip.

Resolution

Review your configuration (namely IP Access rules and custom rules with the Skip action) to ensure the intended behavior is achieved.

If specific rules of WAF managed rulesets are blocking requests you want to allow, you can create managed rules exceptions to skip specific managed rules or rulesets for particular requests instead of skipping WAF Managed Rules entirely.

Page Rules do not use the same request view as modern rules

Page Rules are legacy behavior and do not line up exactly with modern Rules products.

In mixed configurations, you may see:

  • A rewrite affecting custom rules and Managed Rules
  • Different results between a Page Rule and a modern rule that appear to target the same path

Resolution

When possible, migrate older Page Rules behavior to the current Rules products so the request is evaluated in one model.

When a WAF decision looks incorrect:

  1. Check for earlier request rewrites.
  2. Check for matching IP Access rules.
  3. Confirm whether the request was expected to stop in the custom rules phase or skip later phases.
  4. Review whether a managed rule still ran after a custom rule match.
  5. Use Trace when available to confirm the actual phase-by-phase result.