Skip to content
Cloudflare Docs

Troubleshooting

Interaction between Cloudflare challenges and Rules features

If you are issuing a challenge for a given URI path that has one or more Rules features enabled, you should exclude URI paths starting with /cdn-cgi/challenge-platform/ in your rule expressions to avoid challenge loops.

For example, define a compound expression for your rule using the and operator and the starts_with() function:

<OTHER_RULE_CONDITIONS> and not starts_with(http.request.uri, "/cdn-cgi/challenge-platform/")

HTTP DCV and redirects

Before a certificate authority (CA) will issue a certificate for a domain, the requester must prove they have control over that domain. This process is known as domain control validation (DCV).

If you are using HTTP DCV and also have Single Redirects set up in your zone, consider excluding the /.well-known/* path from your rule to avoid DCV issues. For details and other resources refer to the SSL/TLS documentation.

Content-Length header removed from response

Cloudflare may remove the Content-Length header from responses delivered to website visitors. If the visitor must receive the Content-Length header, configure the origin server to include a cache-control: no-transform HTTP header in the response.

This rule may not apply to your traffic

If your rule expression is matching a hostname for which you have neither created a DNS record nor enabled proxying traffic through Cloudflare, you will get a pop-up window with a couple of options:

  • If no DNS record exists for the hostname: Whether to proceed with the rule creation or to create a new proxied DNS record for that hostname.
  • If there is a DNS record for the hostname, but traffic is not being proxied: Whether to proceed with the rule creation or to enable proxying for the existing DNS record.

If you choose to create a new DNS record, the new record will have a rules tag and the following associated comment:

Created during Cloudflare Rules deployment process for <RULE_NAME>

URL rewrites affect other Rules features executed later

If you rewrite a URI path using a URL rewrite, this may affect other Rules features executed later — such as Origin Rules — if they include the URI path in their filter expression.

Consider the following origin rule configuration:

  • Rule expression: http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/")
  • Host header > Rewrite to: assets.example.com

If you configure a new URL rewrite with the following configuration:

  • Rule expression: http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/")
  • Path > Rewrite to > Dynamic: regex_replace(http.request.uri.path, "^/downloads/", "/")

The origin rule will no longer match /downloads/* paths, since URL rewrites run before Origin Rules and the URI path will be rewritten from "/downloads/" to "/".

Solution

To prevent this situation, use raw fields in your rule expression. Raw fields are immutable during the entire request evaluation workflow, and they are not affected by the actions of previously matched rules.

In the current example, you could use the raw.http.request.uri.path field in both rules:

URL rewrite

  • Rule expression: http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/")
  • Path > Rewrite to > Dynamic: regex_replace(raw.http.request.uri.path, "^/downloads/", "/")

Origin rule

  • Rule expression: http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/")
  • Host header > Rewrite to: assets.example.com

This way, the two rules will work as intended. Additionally, this allows you to use the same expression in the two rules, even when the first rule is updating the URI path value.

For a list of raw fields, refer to the Fields reference.