Blocking Client Requests

The drop-down list of page rules provides various categorized actions. Among them, there is a category called “Dos Attack Actions”, which is used to control requests. This article will introduce how to intercept requests, i.e., block requests:

The main principle of Block Request is to set a time window to observe whether the request processing rate within that time window exceeds a threshold. When the request processing rate exceeds the threshold for a specified number of consecutive time windows, the system will execute the specified blocking action for a specified duration afterward.

The following parameters can control it:

1. Key: Used to differentiate and categorize requests. By default, it is the client’s IP address. It can be changed to URI, URI parameters, etc. via the drop-down menu. See Key Description for details. One or more keys can be selected. If URI parameter or Cookie is selected, an additional corresponding Argument field must be specified.
2. Throttle At: Requests below this rate will not be subject to any restrictions; requests above this rate but below Reject At will be delayed.
3. Reject At: Requests above this rate will execute the Reject Action. The default unit for both Throttle At and Reject At is requests per second, and requests per minute can also be selected. If their values are set to be the same, requests exceeding the set rate will be directly rejected without any delay for buffering.
4. Time Window: The size of the observation time window.
5. Block Threshold: The number of consecutive occurrences of the observation time window.
6. Block Duration: The specified blocking duration. After this duration, the client will be unblocked, and the Block Threshold will start counting again.
7. Reject Action: Specifies the action to be executed when the Reject Threshold or Block Threshold is reached. See Reject Action Description for details.

Available keys include:

• Client IP address, e.g., 1.1.1.1.
• The requested URI, e.g., /openresty.
• URI query parameter, e.g., arg1 in /openresty?arg1=val1.
• Request Cookie, e.g., the key c1 in cookie: c1=v1.
• The first IP address in the X-Forwarded-For request header, e.g., 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, e.g., 1.1.1.2 in X-Forwarded-For: 1.1.1.1, 1.1.1.2.
• A specific HTTP request header, e.g., Host.
• Encrypted Cookie: Requests will be controlled based on the encrypted Cookie generated by OpenResty Edge. When the client request does not carry an encrypted Cookie, it will fall back to the case without an encrypted Cookie. Therefore, Encrypted Cookie must be used together with other keys.

After the blocking conditions are met, the system can execute the following preset actions, with Return Error Page as the default:

• Close Request Connection: Immediately terminate the connection with the client and no longer respond to the request. Return Error Page, default status code 503: When the block request is in effect, display an error page with status code 503 to the client, indicating that the server is temporarily unable to process the request.
• Complete hCaptcha Verification: The client must pass the hCaptcha challenge to distinguish between human and machine behavior.
• Complete OpenResty Edge Captcha Verification: Verify user identity using OpenResty Edge’s captcha system.
• Redirect Verification: Redirect the request to a verification page; access can only continue after successful verification.
• JavaScript Challenge: Require the user’s browser to execute JavaScript code to verify non-robot operation.
• Mark as Rejected: Only mark the request as rejected, continue with the subsequent page rules.