Configuration Rules: Cloudflare’s Page Rules Successor

Ten years after the launch of Page Rules, Cloudflare has introduced Configuration Rules, a more flexible way to control zone-wide features. Instead of relying on URL-based matching only, Configuration Rules let you toggle features based on a broader set of HTTP request attributes, such as cookies, source country, or client IP characteristics.

Configuration Rules are already available to all plan levels via the dashboard, API, and Terraform.

Overriding zone defaults selectively

Every HTTP request entering a Cloudflare zone is processed with a default configuration defined by the user. That configuration determines which features—such as Auto Minify, Polish, or Rocket Loader—apply to the request. The limitation has always been that these settings are all-or-nothing.

Configuration Rules change this by letting you override the zone-wide setting for a subset of traffic. For example, if Rocket Loader is enabled for example.com but causes issues on a specific checkout page, you can create a rule that disables it only for that path. Conversely, you can enable features for a particular subdomain like staging.example.com to test them before turning them on globally.

There are currently 16 available actions within Configuration Rules, covering options like disabling Apps, Railgun, or Zaraz, and enabling Auto Minify, Mirage, and Polish. These rules use the same expression syntax as the ruleset engine, and they filter on fields such as:

  • ip.geoip.country
  • http.request.cookies
  • Managed IP Lists
  • Requested URL

Beyond URL matching

The main difference from Page Rules is expressiveness. Page Rules operate on the requested URL alone, which forces users to make decisions based on paths or query strings. That approach breaks down when the decision depends on something like visitor location or client headers.

With Configuration Rules, you can write expressions like setting the Security Level to “I’m under attack” only for visitors from specific countries. This removes the need for workarounds like appending query parameters to URLs for targeted feature testing.

A/B testing without custom code

A/B testing configuration settings previously required either elaborate Page Rules or custom Cloudflare Workers code. Configuration Rules simplify this workflow. Use the expression any(http.request.cookies["app"][*] == "test") to enable Auto Minify, Mirage, and Polish only when a test cookie is present. This lets you compare performance or behavior against production traffic safely and without affecting it.

More precise security controls

A practical example of augmenting existing requirements is protecting a contact page. Page Rules could raise the Security Level to “High” for example.com/contact*, but that would also challenge legitimate visitors. Configuration Rules go further by combining the URL condition with additional checks—for instance, requiring that the traversal is also from a Managed IP List of open proxies commonly used in attacks. The result is a stricter rule with fewer false positives for genuine users.

The addition of Configuration Rules is part of a broader push toward replacing Page Rules with more granular, multi-field rule types. They offer a path for users who previously had no option but to write custom code in a Cloudflare Worker.