Cloudflare 通过为规则 特征 中的每组唯一值组合维护独立计数器来跟踪请求速率。
例如，考虑一条具有以下特征的规则：
- IP 地址
- HTTP 标头
x-api-key
如果两个请求共享相同的 x-api-key 标头值但来自不同的 IP 地址，Cloudflare 会分别计数，因为它们的特征组合不同。
计数器不会跨数据中心共享，但属于同一地理位置的数据中心除外。
默认情况下，请求速率基于传入请求的数量。拥有 Advanced Rate Limiting 的 Enterprise 客户还可以基于处理每个请求的成本来计算速率。更多信息请参阅基于复杂度的速率限制。
考虑以下速率限制规则配置：
速率限制规则 #1
当传入请求匹配：
http.request.uri.path eq "/form" and any(http.request.headers["content-type"][*] eq "application/x-www-form-urlencoded")
选择操作：Block
持续时间（缓解超时）：10 minutes
请求数：1
时间段：10 seconds
具有相同特征时：
- Data center ID（在仪表板中创建规则时默认包含）
- IP
- Header value of >
x-api-key
下图显示了 Cloudflare 在上述速率限制规则上下文中如何处理四个传入请求。
由于请求 1 匹配规则表达式，因此会评估该速率限制规则。Cloudflare 为该速率限制规则上下文中的特征值定义一个请求计数器，并将其设置为 1。由于计数器值在 Requests（请求数） 中设定的限制内，该请求被允许。
请求 2 匹配规则表达式，因此 Cloudflare 会评估该速率限制规则。这些特征值与任何现有计数器都不匹配（X-API-Key 标头的值不同）。因此，Cloudflare 在此规则上下文中定义一个单独的计数器，并将其设置为 1。计数器值在 Requests（请求数） 中设定的请求限制内，因此该请求被允许。
请求 3 匹配规则表达式，并且与请求 1 具有相同的规则特征值。因此，Cloudflare 将现有计数器的值增加到 2。计数器值现已超过 Requests 中定义的限制，因此请求 3 被阻止。
请求 4 不匹配规则表达式，因为 Content-Type 标头的值与表达式中的值不匹配。因此，Cloudflare 不会为此请求创建新的规则计数器。请求 4 不会在此速率限制规则的上下文中评估，而是传递给请求评估工作流中的后续规则。
考虑以下速率限制规则配置。规则计数表达式定义了当响应 HTTP 状态码为 400 时，计数器将加一：
速率限制规则 #2
当传入请求匹配：
http.request.uri.path eq "/form"
选择操作：Block
持续时间（缓解超时）：10 minutes
请求数：1
时间段：10 seconds
具有相同特征时：
- Data center ID（在仪表板中创建规则时默认包含）
- IP
- Header value of >
x-api-key
在以下情况时递增计数器：
http.request.uri.path eq "/form" and http.response.code eq 400
下图显示了 Cloudflare 在 10 秒时间段内收到的这四个传入请求，在上述速率限制规则上下文中的处理方式。
由于请求 1 匹配规则表达式，因此会评估该速率限制规则。该请求会发送到源站并跳过任何缓存内容，因为速率限制规则在计数表达式中包含响应字段（http.response.code）。源站以 400 状态码响应。由于计数表达式匹配，Cloudflare 为该速率限制规则上下文中的特征值创建请求计数器，并将此计数器设置为 1。
请求 2 匹配规则表达式，因此 Cloudflare 会评估该速率限制规则。这些特征值对应的请求计数器仍在 Requests（请求数） 中定义的最大请求数以内。源站以 200 状态码响应。由于响应不匹配计数表达式，计数器不会递增，保持其值（1）。
请求 3 匹配规则表达式，因此 Cloudflare 会评估该速率限制规则。该请求仍在 Requests（请求数） 中定义的最大请求数以内。源站以 400 状态码响应。计数表达式匹配，将计数器设置为 2。
请求 4 匹配规则表达式，因此 Cloudflare 会评估该速率限制规则。该请求已不再在 Requests（请求数） 中定义的最大请求数以内（计数器值为 2，最大请求数为 1）。Cloudflare 应用速率限制规则配置中定义的操作，阻止请求 4 以及之后十分钟内匹配该速率限制规则的任何请求。
并非所有请求的处理成本都相同。简单的 API 读取可能只使用极少资源，而复杂的数据库查询或文件导出可能需要显著更多资源。基于请求计数的速率限制对这些请求一视同仁——100 个轻量请求和 100 个高成本请求会递增同一个计数器。
基于复杂度的速率限制通过跟踪源站为每个请求分配的成本分数，并在给定时间段内对每个客户端强制执行最大总分来解决此问题。这样，发送少量高成本请求的客户端可以在达到较高请求计数之前就受到速率限制，而与发送的请求总数无关。
要使用基于复杂度的速率限制，源站必须返回一个包含每个请求数值分数的 HTTP 响应标头。该分数表示处理该请求的复杂度或成本。值必须介于 1 和 1,000,000 之间。您可以配置规则从哪个标头名称读取。
基于复杂度的速率限制规则必须包含以下属性：
Cloudflare 会为匹配规则表达式且规则特征值相同的所有请求维护总分计数器。当存在计数表达式匹配时（默认情况下与规则表达式相同），分数会按源站在响应中提供的值增加。当总分大于配置的每时间段最大分数时，将应用规则操作。
如果源站未提供带分数值的 HTTP 响应标头，或分数值超出允许范围，则相应的速率限制计数器不会更新。
考虑以下速率限制规则配置。当规则匹配时，复杂度分数计数器将根据源站提供的 x-score 响应标头中的值递增。
速率限制规则 #3
当传入请求匹配：
(http.request.uri.path eq "/graphql")
具有相同特征时：
- Data center ID（在仪表板中创建规则时默认包含）
- Header value of >
x-api-key
当速率超过时：Complexity based
- 每时间段分数：
400 - 时间段：1 minute
- 响应标头名称：
x-score
选择操作：Block
采用以下行为：Block for the selected duration
持续时间（缓解超时）：10 minutes
下图显示了 Cloudflare 在一分钟时间段内收到的四个传入请求，在上述速率限制规则上下文中的处理方式。
由于请求 1 匹配规则表达式，因此会评估该速率限制规则。源站以 200 状态码响应，并在 x-score HTTP 响应标头中提供复杂度分数 100。Cloudflare 为该速率限制规则上下文中的特征值创建请求计数器，并将此计数器设置为 100。
请求 2 匹配规则表达式，因此 Cloudflare 会评估该速率限制规则。这些特征值对应的请求计数器仍在每时间段最大分数以内。源站以 200 状态码响应，请求计数器增加 200。该请求的当前复杂度分数现为 300。
请求 3 匹配规则表达式，因此 Cloudflare 会评估该速率限制规则。这些特征值对应的请求计数器仍在每时间段最大分数以内。源站以 200 状态码响应，请求计数器增加 150。该请求的当前复杂度分数现为 450。
请求 4 匹配规则表达式，因此 Cloudflare 会评估该速率限制规则。该请求已不再在规则中定义的每时间段最大分数以内（计数器值为 450，最大分数为 400）。Cloudflare 应用速率限制规则配置中定义的操作，阻止请求 4 以及之后十分钟内匹配该速率限制规则的任何请求。