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

An API token is required along with the ID of a WAAP-protected domain. For SDK examples, install the Python or Go SDK. Set these as environment variables before running any of the examples:
To list, update, enable, disable, or delete rules, see Advanced Rules.

Rate limiting with exclusions

Rate-limit IPs that exceed 200 requests in 5 seconds on any /events path, while excluding requests from known mobile and web clients that carry session cookies.

Best practices

Block IPs that exceed request limit for any URL

Each request is counted individually per IP. If 1.2.3.4 sends more than 200 requests within 5 seconds, it is blocked. Another IP, 1.2.3.5, is only blocked when it independently exceeds the same threshold.

Embed additional conditions

Combine rate limiting with other request attributes. In this example, the block action is applied only to Firefox user-agent requests from specific IPs that exceed the rate limit. The rate limit itself still aggregates across all configured IPs regardless of user-agent.

Rate limit complex URL regex

Block requests to any URL that does not end in a known static asset extension ΓÇö images, fonts, scripts, archives. Requests to dynamic paths are rate-limited at 20 per 120 seconds per IP.

Embed IP range to the condition

Rate-limit JPEG requests from a specific private IP range. The request.ip_in_range condition acts as a filter ΓÇö the rate limit aggregation still counts per IP within the range.

Cluster (PoP) granularity

Rate-limit all GET or HEAD requests that return a 302 redirect with a specific content type. The cluster scope counts requests globally across all IPs rather than per individual IP ΓÇö useful for protecting origin from aggregate traffic spikes.

Rate limit by tag filter

Apply rate limiting only to requests that carry a specific user-defined tag. The tag must be assigned by a separate tag rule that runs before this one. This allows targeting specific sessions or clients identified by earlier rules.

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.