Overview
The rules engine provides a graphical user interface that simplifies how you configure rules. You can configure rules to identify user requests based on the parameters they carry to determine whether a configuration applies to the requests. This provides a more flexible and accurate method to manage configurations and policies that you set in Alibaba Cloud CDN.
Background information
The Alibaba Cloud CDN console provides basic features, including cache expiration rules and parameter rewrite, that are suitable for most scenarios but do not meet the requirements of all users. For example, Alibaba Cloud CDN does not support redirecting requests that contain specific paths, such as /example, to a specific origin server address. To implement flexible custom configurations, you can use the basic features together with the rules engine. You can also use EdgeScript for more complex configurations. For more information, see EdgeScript overview.
Capabilities | Basic features | Basic features + rules engine | EdgeScript (programmable configurations) |
Configurations | General configurations | Flexible configurations | Highly flexible configurations |
Scenarios | Common requirements | Advanced custom requirements | Fully customized requirements |
Ease of use (technical knowledge required) | Low | Medium | High |
Configuration flexibility | Low | Medium | High |
Usage notes
You can create a maximum of 50 rules for each domain name.
You can create a maximum of 20 sub-rules in each rule.
If you create a rule by using the console or calling an API operation, you cannot use regular expression-related operators, including regular expression match and mismatch. However, you can view existing rules that include the operators.
If you create a rule by using the console or calling an API operation, the rule can be referenced a maximum of five times across all features for a domain name.
Rules support up to three levels of nesting. You can configure complete logical statements within each level.
Syntax of rules
A rule consists of logical operators and conditional expressions.
Logic
A logical operator connects expressions in a rule condition to perform a logical operation. The following logical operators are supported:
and: the logical conjunction operator. A rule condition is matched only if all expressions in the rule condition are true.
or: the logical disjunction operator. A rule condition is matched if one of the expressions in the rule condition is true.
Parameters in conditional expressions
The simplest expression includes components described in the following table.
Name | Corresponding parameter in the condition function | Description | Required |
Conditional match | match | The conditional match expression. | Yes |
Logical judgment | logic | The logical judgment parameter of the conditional match expression. Valid values: and/or. | Yes |
Criteria of conditional judgment | criteria | The judgment criteria of the conditional match expression. | Yes |
Match type | MatchType | The type of information to match. The expression attempts to match the specific type of information that is carried in a user request. | Yes |
Match object | MatchObject | A subdivision of the match type. For example, the client IP addresses can be subdivided into IP addresses that are used to connect to points of presence (POPs) and X-Forwarded-For (XFF) IP addresses. | No |
Match operator | MatchOperator | The operator of the match. | Yes |
Match value | MatchValue | The preset value to be matched against the information that is carried in the user request. | Yes |
Condition judgment value negation | negate | Specifies whether to negate the result of a conditional expression. Valid values: true and false. | Yes |
Case sensitivity | caseSensitive | Specifies whether the characters in the match value are case-sensitive. | No |
Rule name | name | The name of the rule. | Yes |
Effective status | status | The effective status of the rule. | Yes |
Configuration of conditional expressions
Match type | Corresponding parameter in the condition function | Description | Match object | Match operator | Match value | Case sensitivity | Corresponding variable in NGINX or Tengine |
Protocol | scheme | The protocol over which the request is sent, such as HTTP or HTTPS. | N/A |
|
| N/A | $scheme |
Request method | method | The request method, such as GET or PUT. | N/A |
|
| N/A | $request_method |
URI | uri | The path in the request URL, excluding request parameters. Example: | N/A |
| The question mark ( |
| $raw_uri or $uri |
File name | basename | The name of the file that is requested by the client. Example: name1. | N/A |
| The question mark ( |
| - |
File name extension | extension | The suffix of the file that is requested by the client, which starts from the last period (.), such as, | N/A |
| The question mark ( |
| - |
Hostname | hostname | The hostname that is carried in the request. The matching priority: host in the request URL > host in the HOST header of the request. | N/A |
| The host of the request. You can specify multiple values. |
| $host or $http_host |
Client IP address | clientip | The IP address of the client. IPv4 addresses such as |
Note For information about IP addresses that are used to connect to POPs and XFF IP addresses, see IP address verification modes. |
| IPv6 addresses such as 240e:XXX:3004:2:3:0:0:3f7 and CIDR blocks such as 120.209.XXX.XXX/31 are supported. You can specify multiple values. | N/A | $remote_addr |
Client IP version | clientipVer | IPv4 or IPv6 |
Note For information about IP addresses that are used to connect to POPs and XFF IP addresses, see IP address verification modes. |
|
| N/A | - |
Internet service provider (ISP) | geolocation | The ISP to which the IP address of the client belongs. |
Note For information about IP addresses that are used to connect to POPs and XFF IP addresses, see IP address verification modes. |
| You can select a value from the drop-down list or enter characters to filter options. Fuzzy match by ID or name is supported. You can specify multiple values. | N/A | $ip_isp_id |
IP location | geolocation | The geographical location of the client IP address. |
Note For information about IP addresses that are used to connect to POPs and XFF IP addresses, see IP address verification modes. |
| You can select a value from the drop-down list or enter characters to filter options. Fuzzy match by ID or name is supported. You can specify multiple values. | N/A | $ip_country_id |
Request parameter | querystring | The parameter that is carried in the request URL. | Enter a parameter name. |
| The question mark ( |
| $arg_{name} |
Request header | header | The header that is carried in the request. | Enter a parameter name or select a parameter from the drop-down list. |
| You can specify multiple values. |
| $http_{name} |
Cookie | cookie | The cookie that is carried in the request. | Enter a cookie name. |
| The question mark ( |
| $cookie_{name} |
User-Agent | useragent | The User-Agent header in the request. | N/A |
| You can select a value from the drop-down list or enter a User-Agent value, such as |
| $http_user_agent |
Range bucket | range | Requests are grouped and executed based on the percentage. | N/A |
| Enter a percentage. | N/A | - |
Time range | time | The time range during which the request was initiated, in UTC+8. Example: 09:10 to 14:22. | N/A |
| Enter a time range, such as 09:10 to 14:22. | N/A | - |
Nginx Var | ngxvar | If all the preceding variables in the table cannot meet your requirements, you can use NGINX variables. For more information, see Alphabetical index of variables. | Select a variable from the drop-down list or enter a variable name in the |
| You can specify multiple values. | N/A | ${name} |
IP address verification modes
The rules engine feature has two IP address verification modes, which affect the determination of POPs on the client IP addresses.
Determine based on the IP address that is used to connect to the POP: This mode verifies the IP address that is used by a client to connect to a POP. If a proxy is used when a client connects to a POP, the IP address that is used to connect to the POP is the IP address of the proxy.
Determine based on the XFF IP address: This mode verifies the first IP address in the XFF header in a client request. The XFF IP address is the client IP address regardless of whether a proxy is used when a client connects to a POP.
The choice between the IP address verification modes varies based on whether a request passes through a proxy before the request is sent to a POP.
Take note that the POP where the feature that references a rule takes effect also affects the choice between the IP address verification modes. For origin features that take effect on L2 POPs, L1 POPs that the requests pass through are regarded as proxies.
For example, the client IP address is 10.10.10.10
and the proxy IP address is 192.168.0.1
.
If no proxy is used when a client connects to a POP, the following rules apply:
The value of the XFF header in the user request is
10.10.10.10
.The client IP address
10.10.10.10
is the IP address that is used by the client to connect to the POP.
If a proxy is used when a client connects to a POP, the following rules apply:
The value of the XFF header in the user request is
10.10.10.10,192.168.0.1
.The client IP address is
10.10.10.10
.The IP address that is used by the client to connect to a POP is the IP address of the proxy, which is
192.168.0.1
.The client IP address is not the IP address that is used by the client to connect to the POP.
Some Internet service providers (ISPs) may assign private IP addresses to clients in specific regions. Therefore, CDN POPs may receive requests from private IP addresses.
Private IP addresses are of the following types:
Type-A private IP addresses: 10.0.0.0 to 10.255.255.255. Subnet mask: 10.0.0.0/8.
Type-B private IP addresses: 172.16.0.0 to 172.31.255.255. Subnet mask: 172.16.0.0/12.
Type-C private IP addresses: 192.168.0.0 to 192.168.255.255. Subnet mask: 192.168.0.0/16.
Match operators
Operator | Corresponding parameter in the condition function | Description |
Equal to | The value of the matchOperator parameter is equals. | The condition is true only when all variables are equal to or not equal to the match value. |
Not equal to | The value of the matchOperator parameter is equals, and the value of the negate parameter is true. | |
Existent | The value of the matchOperator parameter is exists. | The condition is true regardless of whether the variable exists. |
Non-existent | The value of the matchOperator parameter is exists, and the value of the negate parameter is true. | |
Include any | The value of the matchOperator parameter is contains. | The condition is true if variables contain or do not contain any of the match values. You can specify up to 32 match values. The following match modes are supported:
|
Exclude any | The value of the matchOperator parameter is contains, and the value of the negate parameter is true. | |
Greater than | The value of the matchOperator parameter is gt. |
|
Smaller than | The value of the matchOperator parameter is lt. |
|
Greater than or equal to | The value of the matchOperator parameter is ge. |
|
Smaller than or equal to | The value of the matchOperator parameter is le. |
|
Regular expression match | The value of the matchOperator parameter is regex. | You can enter a regular expression as the match value. Note If you create a rule by using the console or calling an API operation, you cannot use regular expression-related operators, including regular expression match and mismatch. However, you can view existing rules that include the operators. |
Regular expression mismatch | The value of the matchOperator parameter is regex, and the value of the negate parameter is true. |
Wildcards
Wildcard | Description |
| One character can be matched. |
| Any characters can be matched. |
Features that can reference rules
Feature | References |
Basic configurations | |
Cache settings | |
Origin settings | |
Access control | Configure a Referer whitelist or blacklist to enable hotlink protection |
Performance improvement | |
Video-related settings | |
Traffic throttling |
Procedure
Log on to the Alibaba Cloud CDN console.
In the left-side navigation pane, click Domain Names.
On the Domain Names page, find the domain name that you want to manage and click Manage in the Actions column.
In the left-side navigation tree, click Rules Engine.
Click Add Rule.
On the Add Rule page, configure the Rule Name and Rule Content parameters.
Click Submit.