导航|地址|刷新
Operators and grouping symbols

Skip to contentDocumentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/ruleset-engine/llms.txt
Use this file to discover all available pages before exploring further.



DocsDirectoryAPISDKsChangelog

Search

Log in






Ruleset Engine

/




Overview


About


Overview

Phases

Rulesets

Rules






Basic API operations


View rulesets

Add rules to phase entry point rulesets

Deploy rulesets






Work with managed rulesets


Overview

Deploy a managed ruleset

Override a managed ruleset


Override examples


Overview

Set WordPress rules to Block

Enable only Joomla rules

Enable only selected rules

Deploy a managed ruleset with ruleset, tag, and rule overrides

Adjust the sensitivity of an HTTP DDoS rule to Low

Adjust an L3/4 DDoS rule ↗





Create an exception






Work with custom rulesets


Overview

Create a custom ruleset

Add rules to a custom ruleset

Deploy a custom ruleset






Rules language


Overview


Expressions


Overview

Edit in the dashboard





Operators and grouping symbols

Values

Actions


Fields


Overview

Fields reference





Functions






Rulesets API


Overview

JSON objects

Endpoints

List and view rulesets

Create a ruleset

Update or deploy a ruleset

Add a rule to a ruleset

Update a rule in a ruleset

Delete a rule in a ruleset

Delete a ruleset






Reference


Phases list






Agent resources


Agent setup ↗

Cloudflare Skills ↗

Code Mode MCP Server ↗

Domain-specific MCP Servers ↗MCP

Ruleset Engine llms.txt ↗

Ruleset Engine llms-full.txt ↗

Cloudflare Docs llms.txt ↗

Cloudflare Docs llms-full.txt ↗













Home

/Ruleset Engine

/Rules language

/Operators and grouping symbols



Operators and grouping symbols


Last updated Apr 16, 2026|Copy as Markdown|View as Markdown|Agent setup

OverviewComparison operators Additional operators in the Cloudflare dashboard Comparing string values Wildcard matching Regular expression matchingLogical operators Supported logical operators Order of precedenceGrouping symbols Group expressions Enforce precedence Nest expressions




The Cloudflare Rules language supports comparison and logical operators:

Comparison operators specify how values defined in an expression must relate to the actual HTTP request value for the expression to return true.

Logical operators combine two expressions to form a compound expression and use order of precedence to determine how an expression is evaluated.

Grouping symbols allow you to organize expressions, enforce precedence, and nest expressions.


Comparison operators


Comparison operators return true when a value from an HTTP request matches a value defined in an expression.

This is the general pattern for using comparison operators:
<field> <comparison_operator> <value>
The Rules language supports these comparison operators:

Name	Operator Notation	Supported Data Types
	English	C-like	String1	IP	Number	Example (operator in bold)
Equal	eq	==	✅	✅	✅	http.request.uri.path eq "/articles/2008/"
Not equal	ne	!=	✅	✅	✅	ip.src ne 203.0.113.0
Less than	lt	<	✅	❌	✅	cf.waf.score lt 10
Less than or equal	le	<=	✅	❌	✅	cf.waf.score le 20
Greater than	gt	>	✅	❌	✅	cf.waf.score gt 25
Greater than or equal	ge	>=	✅	❌	✅	cf.waf.score ge 60
Contains	contains		✅	❌	❌	http.request.uri.path contains "/articles/"
Wildcard (case-insensitive)	wildcard		✅	❌	❌	http.request.uri.path wildcard "/articles/*"
Strict wildcard (case-sensitive)	strict wildcard		✅	❌	❌	http.request.uri.path strict wildcard "/AdminTeam/*"
Matches regex2	matches	~	✅	❌	❌	http.request.uri.path matches "^/articles/200[7-8]/$"
Is in set of values / list3	in		✅	✅	✅	ip.src in { 203.0.113.0 203.0.113.1 } ip.src.asnum in $<LIST>

1 All string operators are case-sensitive unless explicitly stated as case-insensitive, such as the wildcard operator.
2 Access to the matches operator requires a Cloudflare Business or Enterprise plan.
3 Currently, not all Cloudflare products support lists in their expressions. For more information on lists, refer to Inline lists and Lists.


Caution


Comparison operators entered using English notation (such as eq, lt, and gt) must be written in lowercase.




Additional operators in the Cloudflare dashboard


The Cloudflare dashboard may show the following additional operators, depending on the exact field and the type of rule:


starts with (corresponding to the starts_with() function): Returns true when a string starts with a given substring, and false otherwise.



ends with (corresponding to the ends_with() function): Returns true when a string ends with a given substring, and false otherwise.



is in list (corresponding to <FIELD> in $<LIST_NAME>): Returns true when the field value is present in the specified list, and false otherwise. For more information, refer to Use lists in expressions.



is not in list (corresponding to not <FIELD> in $<LIST_NAME>): Returns true when the field value is not present in the specified list, and false otherwise. For more information, refer to Use lists in expressions.



Note


When writing your own custom expressions, you must use the starts_with() and ends_with() functions in function calls, not as operators. For example:
# Valid function callends_with(http.request.uri.path, ".html")# Invalid use of ends_with functionhttp.request.uri.path ends_with ".html"



Comparing string values


String comparison in rule expressions is case-sensitive. To account for possible variations of string capitalization in an expression, you can use the lower() function and compare the result with a lowercased string, like in the following example:
lower(http.request.uri.path) contains "/wp-login.php"
Wildcard matching is only supported with the wildcard and strict wildcard operators, and regular expression matching is only supported with the matches operator.


Wildcard matching


The wildcard operator performs a case-insensitive match between a field value and a literal string containing zero or more * metacharacters. Each * metacharacter represents zero or more characters. The strict wildcard operator performs a similar match, but is case-sensitive.

When using the wildcard/strict wildcard operator, the entire field value must match the literal string with wildcards (the literal after the operator).
Example Atxt# The following expression:http.request.full_uri wildcard "http*://example.com/a/*"# Would match the following URIs:# - https://example.com/a/ (the '*' matches zero characters)# - http://example.com/a/# - https://example.com/a/page.html# - https://example.com/a/sub/folder/?name=value# Would NOT match the following URIs:# - https://example.com/ab/# - https://example.com/b/page.html# - https://sub.example.com/a/
Example B
# The following expression:http.request.full_uri wildcard "*.example.com/*/page.html"# Would match the following URIs:# - http://sub.example.com/folder/page.html# - https://admin.example.com/team/page.html# - https://admin.example.com/team/subteam/page.html# Would NOT match the following URIs:# - https://example.com/ab/page.html ('*.example.com' matches only subdomains)# - https://sub.example.com/folder2/page.html?s=value (http.request.full_uri includes the query string and its full value does not match)# - https://sub.example.com/a/ ('page.html' is missing)
Slashes (/) have no special meaning in wildcard matches. In this example, the second * metacharacter in the expression http.request.full_uri wildcard "*.example.com/*/page.html" matched folder, team, and team/subteam.

Example C
# The following expression:http.request.full_uri wildcard "*.example.com/*" or http.request.full_uri wildcard "http*://example.com/*"# Would match the following URIs:# - https://example.com/folder/list.htm# - https://admin.example.com/folder/team/app1/# - https://admin.example.com/folder/team/app1/?s=foobar
The matching algorithm used by the wildcard operator is case-insensitive. To perform case-sensitive wildcard matching, use the strict wildcard operator.

To enter a literal * character in a literal string with wildcards you must escape it using \*. Additionally, you must also escape \ using \\. Two unescaped * characters in a row (**) in a wildcard literal string are considered invalid and cannot be used. If you need to perform character escaping, it is recommended that you use the raw string syntax to specify a literal string with wildcards.


Wildcard matching versus regex matching


The wildcard/strict wildcard operators always consider the entire field value (left-side operand) when determining if there is a match. The matches operator can match a partial value.




Regular expression matching


Customers on Business and Enterprise plans have access to the matches operator. Regular expression matching is performed using the Rust regular expression engine.

If you are using a regular expression, you can test it using a tool like Regular Expressions 101 ↗ or Rustexp ↗.

For more information on regular expressions, refer to String values and regular expressions.


Logical operators


Logical operators combine two or more expressions into a single compound expression. A compound expression has this general syntax:
<expression> <logical_operator> <expression>

Supported logical operators


Each logical operator has an order of precedence. The order of precedence (along with grouping symbols) determines the order in which Cloudflare evaluates logical operators in an expression. The not operator ranks first in order of precedence.

Name	English Notation	C-like Notation	Example	Order of Precedence
Logical NOT	not	!	not ( http.host eq "www​.cloudflare​.com" and ip.src in {203.0.113.0/24} )	1
Logical AND	and	&&	http.host eq "www​.cloudflare​.com" and ip.src in {203.0.113.0/24}	2
Logical XOR (exclusive OR)	xor	^^	http.host eq "www​.cloudflare​.com" xor ip.src in {203.0.113.0/24}	3
Logical OR	or	||	http.host eq "www​.cloudflare​.com" or ip.src in 203.0.113.0/24	4

Caution


Logical operators entered using English notation (such as not, and, and or) must be written in lowercase.




Order of precedence


When writing compound expressions, it is important to be aware of the precedence of logical operators so that your expression is evaluated the way you expect.

For example, consider the following generic expression, which uses and and or operators:
Expression1 and Expression2 or Expression3
If these operators had no order of precedence, it would not be clear which of two interpretations is correct:

Match when Expression 1 and Expression 2 are both true or when Expression 3 is true.

Match when Expression 1 is true and either Expression 2 or Expression 3 is true.

Since the logical and operator has precedence over logical or, the and operator must be evaluated first. Interpretation 1 is correct.

To avoid ambiguity when working with logical operators, use grouping symbols so that the order of evaluation is explicit.


Grouping symbols


The Rules language supports parentheses ((,)) as grouping symbols. Grouping symbols allow you to organize expressions, enforce precedence, and nest expressions.

Only the Expression Editor and the Cloudflare API support grouping symbols. The Expression Builder does not.


Group expressions


Use parentheses to explicitly group expressions that should be evaluated together. In this example, the parentheses do not alter the evaluation of the expression, but they unambiguously call out which logical operators to evaluate first.
(Expression1 and Expression2) or Expression3
Because grouping symbols are so explicit, you are less likely to make errors when you use them to write compound expressions.


Enforce precedence


Grouping symbols are a powerful tool to enforce precedence for grouped elements of a compound expression. In this example, parentheses force the logical or operator to be evaluated before the logical and:
Expression1 and (Expression2 or Expression3)
Without parentheses, the logical and operator would take precedence.


Nest expressions


You can nest expressions grouped by parentheses inside other groups to create very precise, sophisticated expressions, such as this example for a rule designed to block access to a domain:
( (http.host eq "api.example.com" and http.request.uri.path eq "/api/v2/auth") or (http.host matches "^(www|store|blog)\.example\.com" and http.request.uri.path contains "wp-login.php") or ip.src.country in {"CN" "TH" "US" "ID" "KR" "MY" "IT" "SG" "GB"} or ip.src.asnum in {12345 54321 11111}) and not ip.src in {11.22.33.0/24}
Note that when evaluating the precedence of logical operators, parentheses inside strings delimited by quotes are ignored, such as those in the following regular expression, drawn from the example above:
"^(www|store|blog)\.example\.com"

PreviousEdit in the dashboardNextValues


Was this helpful?

YesNo

Edit pageReport issue




On this page

Overview

Comparison operators

Additional operators in the Cloudflare dashboard

Comparing string values

Wildcard matching

Regular expression matching

Logical operators

Supported logical operators

Order of precedence

Grouping symbols

Group expressions

Enforce precedence

Nest expressions


Edit pageReport issue














Getting started
PlansContact salesPartnersFind a partnerStartupsUnder attack?Domain name search


Company
AboutCareersInvestorsPressPress kitGlobal network




Public interest
Project GalileoAthenian ProjectCloudflare for CampaignsProject FairshotImpact/ESG


Compliance
Compliance resourcesTrust HubData ProtectionResponsible AITransparency reportReport abuse




Resources
App innovation reportCloudflare RadarCase studiesStatusSupportEventsBlog


Developers
DocumentationLearning centerCommunity




Solutions
SSE and SASE platformCloudflare AI CloudAI SecurityFrontend Development PlatformMulti-Tenant Platform DevelopmentWeb Security Platform


Start BuildingLog In












© 2026 Cloudflare, Inc.

Privacy policy|Report security issues|Terms of use|Trademark
|
Your privacy choices








Docs




------
导航页 打开网址