Skip to main content
Advanced rate limiting rules allow you to control the number of specific requests accepted by your domain within a defined time window. This functionality is part of WAAP advanced rules. Advanced rate limiting rules are fully defined and managed through the Gcore WAAP API. Rate limiting conditions are evaluated as part of a rule’s condition logic and can be combined with other request attributes to precisely control when an action is triggered. In addition to request thresholds and time intervals, advanced rate limiting conditions support multiple parameters, including request origin, URL patterns, request methods, response status codes, aggregation scope, and tags, enabling flexible and targeted traffic control.

Rate limiting method

Use the request.limit_rate method to implement rate limiting: limit_rate fixed method signature
Specify the tag parameter when configuring tag-based rate limiting rules. The method returns true , and the enclosing rule condition is satisfied when the request count (4), under the granularity (8), exceeds the configured threshold within the specified time window (3), using the configured filters (1, 2, 5, 6, 7, 9).

Implementation

Advanced rules via API

Best practices

Block IPs that exceed request limit for any URL

Each request will be counted individually for each IP. For example, if the IP address 1.2.3.4 sends more than 200 requests within a 5-second timeframe, it will be blocked. Another IP address, such as 1.2.3.5, will only be blocked if it exceeds the allowed threshold of 200 requests in the same time interval.

Embed additional conditions

Rate limit complex URL regex

Embed IP range to the condition

Cluster (PoP) granularity

Rate limit all GET or HEAD redirected (302) requests with specific content type:

Rate limit by tag filter

This functionality allows embedding user-defined tags into the rate limit condition so only tagged IPs requests will be aggregated into the rate limit mechanism. Note that my tag is a user-defined tag that should be defined in a separate rule.

Clarification: rate limit aggregation and rule triggering

Rate limit aggregation is defined exclusively by the parameters of the request.limit_rate(...) condition, such as the aggregation scope, IP list, or tags. When request.limit_rate(...) is combined with additional conditions in the same rule, those additional conditions control when the rule action is applied, not how requests are aggregated. For example, if a rate limit condition is configured without an IP list and combined with a condition such as request.ip == '1.2.3.4', request aggregation will still occur according to the rate limit definition. However, the rule action will only be triggered when the full rule condition evaluates to true, in this case, only for requests originating from 1.2.3.4. This distinction is important when combining rate limiting with other conditions to help ensure the rule behaves as expected.