导航|地址|刷新
Request rate calculation

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

Docs Directory API SDKs Changelog

Search

Log in

WAF

/

Overview

Get started

Concepts

Traffic detections

Overview

Attack score

Leaked credentials

Overview

Get started

Common API calls

Terraform examples

Example mitigation rules

Malicious uploads

Overview

Get started

Example rules

Common API calls

Terraform examples

AI Security for Apps

Overview

Get started

PII detection

Unsafe and custom topic detection

Prompt injection detection

Token counting

Example mitigation rules

Log mode vs production mode

Available fields

Bot score ↗

Threat intelligence

Overview

Get started

Example rules

Available fields

Custom rules

Overview

Create in the dashboard

Create via API

Create using Terraform ↗

Configure a rule with the Skip action

Overview

API examples

Skip options

Common use cases

Allow traffic from IP addresses in allowlist only

Allow traffic from search engine bots

Allow traffic from specific countries only

Block Microsoft Exchange Autodiscover requests

Block requests by attack score

Block traffic by geographical location

Block traffic from specific countries

Build a sequence rule within custom rules

Challenge bad bots

Configure token authentication

Exempt partners from Hotlink Protection

Issue challenge for admin user in JWT claim based on attack score

Require a specific cookie

Require known IP addresses in site admin area

Require specific HTTP headers

Require specific HTTP ports

Stop R-U-Dead-Yet? (R.U.D.Y.) attacks

Update custom rules for customers or partners

Custom rulesets

Rate limiting rules

Overview

Request rate calculation

Create in the dashboard

Create via API

Create using Terraform ↗

Find appropriate rate limit

Rate limiting parameters

Rule examples

Best practices

Troubleshooting

Managed rules

Overview

Deploy in the dashboard

Deploy via API

Deploy using Terraform ↗

Troubleshooting

Create exceptions

Overview

Add an exception in the dashboard

Add an exception via API

Log the payload of matched rules

Overview

Configure in the dashboard

View the payload content in the dashboard

Configure via API

Store decrypted matched payloads in logs

Command-line operations

Overview

Generate a key pair

Decrypt the payload content

Check for exposed credentialsDeprecated

Overview

How it works

Configure via API

Configure using Terraform

Test your configuration

Monitor exposed credentials events

Upgrade to leaked credentials detection

Rulesets reference

Cloudflare Managed Ruleset

Cloudflare OWASP Core Ruleset

Overview

Concepts

Evaluation example

Configure in the dashboard

Configure via API

Configure in Terraform ↗

Cloudflare Exposed Credentials Check Managed RulesetDeprecated

Cloudflare Sensitive Data Detection

Additional tools

Lists

Overview

Custom lists

Bulk Redirect Lists ↗

Managed Lists

Create in the dashboard

Use lists in expressions

Lists API

Overview

JSON object

Endpoints

IP Access rules

Overview

Create a rule

Parameters

Actions

Scrape Shield

Overview

Email Address Obfuscation

Hotlink Protection

User Agent Blocking

Zone Lockdown

Browser Integrity Check

Enable security.txt ↗

Privacy Pass

Replace insecure JS libraries

Security Level

Validation checks

Account-level configuration

Overview

Custom rulesets

Overview

Use the dashboard

Use the API

Use Terraform ↗

Rate limiting rulesets

Overview

Create in the dashboard

Create via API

Create using Terraform ↗

Managed rulesets

Overview

Deploy in the dashboard

Deploy via API

Deploy using Terraform ↗

Create exceptions ↗

Analytics

Security Analytics

Security Events

Security features interoperability

Reference

Alerts

Phases

Legacy features

WAF managed rules (previous version)

Overview

Troubleshooting

WAF managed rules upgrade

Rate Limiting (previous version)

Overview

Troubleshooting

Rate limiting upgrade

Firewall rules ↗

Firewall rules upgrade

Troubleshooting

Bing's Site Scan blocked by a managed rule

Fake bot detection blocking legitimate requests

Issues sharing to Facebook

SameSite cookie interaction with Cloudflare

Rule phase interactions

FAQ

Glossary

Changelog

Overview

Changelog

Scheduled changes

Historical (2024)

Historical (2023)

Historical (2022)

Agent resources

Agent setup ↗

Cloudflare Skills ↗

Code Mode MCP Server ↗

Domain-specific MCP Servers ↗MCP

WAF llms.txt ↗

WAF llms-full.txt ↗

Cloudflare Docs llms.txt ↗

Cloudflare Docs llms-full.txt ↗

Home

/WAF

/Rate limiting rules

/Request rate calculation

Request rate calculation

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

OverviewExample AExample BComplexity-based rate limiting Example C

Cloudflare tracks request rates by maintaining separate counters for each unique combination of values in a rule's The set of parameters of a rate limiting rule that define how Cloudflare tracks the rate for the rule.
" class="glossary-tooltip" tabindex="0" data-astro-cid-hklyqugd>characteristics .

For example, consider a rule with these characteristics:

IP address

HTTP header x-api-key

If two requests share the same x-api-key header value but come from different IP addresses, Cloudflare counts them separately because their characteristic combinations differ.

Counters are not shared across data centers, with the exception of data centers associated with the same geographical location.

By default, request rate is based on the number of incoming requests. Enterprise customers with Advanced Rate Limiting can also base the rate on the cost of serving each request. Refer to Complexity-based rate limiting for more information.

Important notes

Cloudflare does not support global rate limiting counters across the entire network. Each data center maintains its own counters. The exception is when Cloudflare has multiple data centers associated with a given geographical location. In that case, those data centers share counters. This is especially relevant for customers that do not add the IP address as one of the rate limiting characteristics.

Every rate limiting rule includes the Cloudflare data center ID (cf.colo.id) as a mandatory characteristic. This ensures counters remain scoped to each data center. This characteristic does not appear in the rule configuration in the dashboard, but it is added behind the scenes. When creating rate limiting rules via API, you must include the cf.colo.id characteristic explicitly.

The available characteristics depend on your Cloudflare plan. Refer to Availability for more information.

In some situations, Workers subrequests to the same zone count as separate requests, which causes the rate limiting rule to trigger sooner than expected. Refer to Troubleshooting for details.

Example A

Consider the following configuration for a rate limiting rule:

Rate limiting rule #1

When incoming requests match:
http.request.uri.path eq "/form" and any(http.request.headers["content-type"][*] eq "application/x-www-form-urlencoded")

Choose action: Block

Duration (mitigation timeout): 10 minutes

Requests: 1

Period: 10 seconds

With the same characteristics:

Data center ID (included by default when creating the rule in the dashboard)

IP

Header value of > x-api-key

The following diagram shows how Cloudflare handles four incoming requests in the context of the above rate limiting rule.

Since request 1 matches the rule expression, the rate limiting rule is evaluated. Cloudflare defines a request counter for the values of the characteristics in the context of the rate limiting rule and sets the counter to 1. Since the counter value is within the established limits in Requests, the request is allowed.

Request 2 matches the rule expression and therefore Cloudflare evaluates the rate limiting rule. The values of the characteristics do not match any existing counter (the value of the X-API-Key header is different). Therefore, Cloudflare defines a separate counter in the context of this rule and sets it to 1. The counter value is within the request limit established in Requests, and so this request is allowed.

Request 3 matches the rule expression and has the same values for rule characteristics as request 1. Therefore, Cloudflare increases the value of the existing counter, setting it to 2. The counter value is now above the limit defined in Requests, and so request 3 gets blocked.

Request 4 does not match the rule expression, since the value for the Content-Type header does not match the value in the expression. Therefore, Cloudflare does not create a new rule counter for this request. Request 4 is not evaluated in the context of this rate limiting rule and is passed on to subsequent rules in the request evaluation workflow.

Example B

Consider the following configuration for a rate limiting rule. The rule counting expression defines that the counter will increase by one when the response HTTP status code is 400:

Rate limiting rule #2

When incoming requests match:
http.request.uri.path eq "/form"

Choose action: Block

Duration (mitigation timeout): 10 minutes

Requests: 1

Period: 10 seconds

With the same characteristics:

Data center ID (included by default when creating the rule in the dashboard)

IP

Header value of > x-api-key

Increment counter when: http.request.uri.path eq "/form" and http.response.code eq 400

The following diagram shows how Cloudflare handles these four incoming requests received during a 10-second period in the context of the above rate limiting rule.

Since request 1 matches the rule expression, the rate limiting rule is evaluated. The request is sent to the origin, skipping any cached content, because the rate limiting rule includes a response field (http.response.code) in the counting expression. The origin responds with a 400 status code. Since there is a match for the counting expression, Cloudflare creates a request counter for the values of the characteristics in the context of the rate limiting rule, and sets this counter to 1.

Request 2 matches the rule expression and therefore Cloudflare evaluates the rate limiting rule. The request counter for the characteristics values is still within the maximum number of requests defined in Requests. The origin responds with a 200 status code. Since the response does not match the counting expression, the counter is not incremented, keeping its value (1).

Request 3 matches the rule expression and therefore Cloudflare evaluates the rate limiting rule. The request is still within the maximum number of requests defined in Requests. The origin responds with a 400 status code. There is a match for the counting expression, which sets the counter to 2.

Request 4 matches the rule expression and therefore Cloudflare evaluates the rate limiting rule. The request is no longer within the maximum number of requests defined in Requests (the counter has the value 2 and the maximum number of requests is 1). Cloudflare applies the action defined in the rate limiting rule configuration, blocking request 4 and any later requests that match the rate limiting rule for ten minutes.

Complexity-based rate limiting

Note

Only available to Enterprise customers with Advanced Rate Limiting.

Not all requests cost the same to serve. A simple API read might use minimal resources, while a complex database query or file export might require significantly more. Request-count-based rate limiting treats these equally — 100 lightweight requests and 100 expensive requests increment the same counter.

Complexity-based rate limiting addresses this by tracking a cost score that your origin server assigns to each request, and enforcing a maximum total score per client over a given period. This way, a client that sends a few expensive requests can be rate limited before reaching a high request count, regardless of the total number of requests sent.

To use complexity-based rate limiting, your origin server must return an HTTP response header containing a numeric score for each request. This score represents the complexity or cost of serving that request. The value must be between 1 and 1,000,000. You configure which header name the rule reads from.

Complexity-based rate limiting rules must contain the following properties:

Score per period: Maximum total score allowed per period. When the total exceeds this value, the rule action executes.

Period: The time window for evaluating the total score.

Response header name: The HTTP response header, set by your origin server, containing the score for each request.

Cloudflare keeps counters with the total score of all requests with the same values for the rule characteristics that match the rule expression. The score increases by the value provided by the origin in the response when there is a match for the counting expression (by default, it is the same as the rule expression). When the total score is larger than the configured maximum score per period, the rule action is applied.

If the origin server does not provide the HTTP response header with a score value or if the score value is outside of the allowed range, the corresponding rate limiting counter will not be updated.

Example C

Consider the following configuration for a rate limiting rule. When there is a rule match, the complexity score counter will increase based on the value in the
…(内容过长已截断)

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