最終更新日:2026-08-27 15:12:24
Reading time: About 14 minutes
This page describes all configurable actions across security policies, including their meanings, use cases, and user experience impact.
| Action | Request Reaches Origin | User Experience | Use When |
|---|---|---|---|
| Not Used | — | — | Disable the corresponding rule or policy without discarding the configuration |
| Skip | Yes | Normal access | In Bot Management, allow authorized automated traffic |
| Log | Yes | Normal access | Observation period — log the event without affecting the request |
| Deny | No | Receives an error response (default 403) | The request is confirmed as malicious |
| Reset Connection | No | Connection forcibly closed, no response received | Attacks where reducing server response overhead is needed |
| Deny Connection | No | Connection rejected, no response received | In DDoS protection, release and deny TCP connections |
| Cookie Verification | Depends on the result | Brief verification process (usually transparent to users) | Verify whether the client supports cookies |
| JavaScript Verification | Depends on the result | Brief verification process (transparent to users, auto-redirect) | Verify whether the client supports JavaScript (HTML requests only) |
| JavaScript Challenge | Depends on the result | Brief wait (a few seconds), auto-redirect upon passing | Verify whether the client is a real browser environment (HTML requests only) |
| Interactive Challenge | Depends on the result | Displays a challenge, user must actively check a box | Strong verification needed with lenient UX requirements |
| CAPTCHA (To be discontinued) | Depends on the result | Displays a slide CAPTCHA | Being phased out — migrate to Interactive Challenge |
| DDoS Managed Verification | Depends on the result | Brief verification process | During DDoS attacks, automatically selects Cookie or JS verification |
| Bot Managed Verification | Depends on the result | Brief verification process | In Web Bot Detection’s Deny mode, runs verification on first-time or suspicious GET requests |
| Delay | Yes (after delay) | Waits tens of seconds before receiving a response | Countering scanning tools by consuming their connection resources |
| IP Block | No | Receives an error response | After a request triggers a rate limiting condition, block all subsequent requests from that IP |
| Custom Response | No | Receives a custom response | When you need to display specific information to the user |
The corresponding rule or policy is disabled. Use this to temporarily suspend a protection feature while retaining its configuration.
Requests that match the rule pass through directly and skip all subsequent Bot policy checks, but other security checks such as WAF and API Security still apply.
Only available in the Bot Management module.
Difference from a whitelist: The Bot Management Skip action only skips subsequent Bot detection. A whitelist skips all security checks.
Equivalent to “log only, no action taken.” The request reaches the origin normally, and the hit record appears in the attack logs.
Use cases:
The request is rejected directly by the platform without being forwarded to the origin. The client receives an HTTP error response (default 403).
The response content can be customized through Custom Response.
Closes the connection at the TCP layer without returning any HTTP response.
Difference from Deny:
When legitimate browser users encounter a reset connection, they experience a network error rather than “access denied,” which results in a poor user experience. Use only when the request source is confirmed as an attack.
Releases the established TCP connection with the client and rejects new connections.
Only available in the DDoS Protection module. Used to counter large-scale application-layer DDoS attacks. Takes effect at the network layer, with the protection granularity being the scrubbing node IP + attack IP, rather than the hostname.
Returns a redirect response carrying a Set-Cookie header to verify whether the client supports cookies.
Only applicable to Web/H5 traffic. Not suitable for native APP or API traffic — use with caution.
Returns a JavaScript verification code that automatically checks whether the client supports JavaScript in the background. The process is transparent to users — after successful verification, the browser automatically redirects to the target request.
Only applicable to HTML requests in Web/H5 traffic — use with caution.
Returns a JavaScript challenge page that automatically detects whether the client is a real browser environment rather than an automated tool. Users wait a few seconds for the challenge to complete, after which the browser automatically redirects.
Difference from JavaScript Verification:
Only applicable to HTML requests in Web/H5 traffic — use with caution.
Returns an interactive challenge page where users must actively check a box to pass verification and lift the policy restriction.
Use cases: Scenarios requiring strong verification with lenient UX requirements, such as high-risk operations (large transfers, batch operations).
Returns a slide CAPTCHA page. Upon successful verification, the policy restriction is lifted.
This action is being phased out. Migrate to Interactive Challenge.
Dynamically selects the appropriate verification method based on request characteristics, adaptively triggering Cookie Verification or JavaScript Verification to effectively reduce false positives.
Only available in the DDoS Protection module.
Simultaneously initiates Cookie and JavaScript verification for GET requests. This action is applied to first-time or suspicious GET requests only when the Web Bot Detection action is set to Deny.
Only available in the Bot Management module.
Deliberately delays the response by tens of seconds before returning it. Used to counter scanning tools by consuming their connection resources and slowing down the scan rate, rather than directly rejecting the request.
If legitimate users are incorrectly hit by this action, they will experience significant access delays. Ensure the match conditions are precise enough, or use it together with a whitelist.
When a request triggers a rate limiting condition, all subsequent requests from that IP are blocked (not limited to the path that triggered the rate limit).
Only available in the Rate Limiting module.
Blocks the request and responds to the client with a customized status code, Content-Type, and content. Suitable for scenarios where specific information needs to be displayed to the user, such as geo-blocking notifications or branded block pages.
| Policy Module | Available Actions |
|---|---|
| WAF Managed Rules | Not Used, Log, Deny |
| DDoS Protection | Log, Deny, Reset Connection, Deny Connection, DDoS Managed Verification |
| Bot Management | Not Used, Skip, Log, Deny, Reset Connection, JavaScript Challenge, Interactive Challenge, Bot Managed Verification |
| API Security | Not Used, Log, Deny |
| Threat Intelligence | Not Used, Log, Deny |
| IP/Geo Firewall | Deny |
| Rate Limiting | Log, Deny, Cookie Verification, JavaScript Verification, JavaScript Challenge, Interactive Challenge, CAPTCHA (To be discontinued), Delay, Reset Connection, IP Block, Custom Response |
| Custom Rules | Not Used, Log, Deny, Reset Connection, Delay, Custom Response |
| Scan Protection | Not Used, Log, Deny |
Related documents: For standard terminology definitions, see Glossary. To customize block page content, see Configuring Custom Actions.