Limit Request Rate

The page rules dropdown menu offers multiple categorized action options. Among them, the “DoS Attack Actions” category contains actions for controlling request traffic.

Select the Limit Request Rate action:

Request rate limiting works based on the Leaky Bucket Algorithm, and we can manage requests using the following three parameters:

  1. Key: By default, this is the client’s IP address, but it can be changed to URI, URI parameters, or Cookies via the dropdown menu. If URI parameters or Cookies are selected, an additional Argument field must be specified;
  2. Regulating Threshold: Requests with a rate below this threshold are unaffected; requests with a rate between this threshold and the rejection threshold will be processed with a delay;
  3. Rejection Threshold: Requests exceeding this rate will be directly returned with HTTP status code 503, meaning the request is rejected.

These two threshold parameters default to requests per second but can also be set as requests per minute.

If both thresholds are set the same, requests exceeding that rate will be immediately rejected.

Requests will be rate-limited based on the set key. Possible keys include:

  • Client IP address, e.g., 1.1.1.1.
  • The request’s URI, for example, /openresty.
  • URI query parameters, such as the arg1 in /openresty?arg1=val1.
  • Request Cookie, like the key c1 in cookie: c1=v1.
  • The first IP address in the X-Forwarded-For request header, such as the 1.1.1.1 in X-Forwarded-For: 1.1.1.1, 1.1.1.2.
  • The last IP address in the X-Forwarded-For request header, such as the 1.1.1.2 in X-Forwarded-For: 1.1.1.1, 1.1.1.2.
  • Specific HTTP request headers, for example, Host.

Upon reaching the rate limit condition, the system can perform the following preset actions, defaulting to Return Default Error Page:

  • Close request connection: Immediately terminate the connection with the client, no longer responding to the request.
  • Return error page, default status code 503: When rate limiting is in effect, display an error page with a 503 status code to the user, suggesting the server is temporarily unable to process the request.
  • Complete hCaptcha verification: Require the user to pass an hCaptcha challenge to differentiate between human and machine behavior.
  • Complete OpenResty Edge Captcha verification: Use OpenResty Edge’s captcha system to verify the user’s identity.
  • Redirect verification: Redirect the request to a verification page, which must be passed before continuing access.
  • JavaScript challenge: Require the user’s browser to execute JavaScript code to verify non-robotic operation.

By default, this action applies to all requests, rate-limited on the basis of the client address. This rule might be too broad, so we can apply more fine-grained condition control in the following ways. Just like action settings, conditions are also organized by categories such as URI, request, response, and client information. Here we take Country from client information as an example, setting the action to be executed only for requests from Japan:

Enter Japan’s country code JP; codes for all continents, countries, provinces, and cities can be found in the Edge documentation: client-country.

After completing the action and condition settings, click the “Create” button in the lower right corner to apply the rule. The page will automatically redirect back to the rule list page.