Troubleshoot common issues that prevent proper Rate Limiting request matches as well as cause errors via the Cloudflare API.
A few common Rate Limiting configuration issues prevent proper request matches:
- Including HTTP or HTTPS protocol schemes in rule patterns (such as https://example.com/*). To restrict rules to match only HTTP or HTTPS traffic, use the schemes array in the request match, e.g. "schemes": [ "HTTPS" ]
- Forgetting a trailing slash character (/). Cloudflare Rate Limiting only treats requests for the homepage (such as example.com and example.com/) as equivalent, but not any other path (such as example.com/path/ and example.com/path). To match request paths both with and without the trailing slash, use a wildcard match (such as example.com/path*)
- Including a query string or anchor (such as example.com/path?foo=bar or example.com/path#section1). A rule like example.com/path will match requests for example.com/path?foo=bar.
- Overriding a rate limit with IP Access Rules.
- Including a port number (such as example.com:8443/api/). The rate limit product doesn't consider port numbers within rules and this affects the rules. By removing the port number from the URL, the rate limit rule will trigger as expected.
Also, there are a few common errors that prevent configuring Rate Limiting via the Cloudflare API:
- Decoding is not yet implemented - Indicates that your request is missing the Content-Type: application/json header. Add the header to your API request to fix the issue.
- Ratelimit.api.not_entitled - Enterprise customers must contact their Cloudflare Account Team before adding rules.
- Other errors are documented in the API documentation. If you're unsure about a particular error, contact Cloudflare Support and provide the failed API request after redacting your API key.
Rate Limiting is designed to limit surges in traffic that exceed a user-defined rate. The system is not designed to allow a precise number of requests to reach the origin server. There might be cases where a delay is introduced between detecting the request and updating the internal counter. Because of this delay (which can be up to a few seconds), excess requests could still reach the origin before an action is enforced at the edge (such as blocking or challenging).