Can a request be blocked with 418 even in Learning or Monitor mode?

Short answer

In practice, no. In a Virtual Host Group in Learning Mode and Monitor Mode, the WAF does not block the request: a request that contains an attack, a request that comes from a blacklisted address and a request whose scan cannot be completed within the 2-second time limit are also passed to the Backend Service. The only exception is when the scan is cut off while the WAF rules are being loaded and before it is determined which host group the request belongs to: if the vService has at least one host group in Blocking Mode, this request is also blocked (except for requests that arrive with the Teacher and Conditional Learning identity; it is not blocked while Fail-open in Request Body Limits is on). Apart from this, a 418 seen in these modes comes from another source; the main possibilities are: the request fell into another Virtual Host Group of the same vService that is in Blocking Mode and was blocked there by the WAF (the WAF block returns with the Blocking Status Code, default 418, or with the code of the Conditional Blocking Pages row whose condition matches); a Bot/DDoS Protection action, a Load Balancer Block or Show Content action, or an AGS Bot Protection Policy action with 418 selected as the status code answered the request; or the Backend Service itself returned the 418. The source is found from the Security Action and Termination State columns in the Debug Mode Logs record of the request that arrives while the vService is in Debug Mode: in a WAF block, Security action starts with WAF · Attack blocked, and in a Bot/DDoS block with Threat Protection; if neither is present, Termination state shows whether the response was given by TR7 (Load Balancer or AGS action) or by the Backend Service.

In Learning and Monitor Mode

Request	Learning mode	Monitor mode
Request that contains an attack	Passed; written to the learning log	Passed; if its score reached the threshold, written to Event Logs with the Not blocked — Monitor mode decision
Source IP on the blacklist	Passed	Passed; written to Event Logs with the Not blocked — Monitor mode decision
Request whose scan cannot be completed within the 2-second time limit	Passed; not written to the learning log (if the scan was cut off before the host group was determined, the exception below applies)	Passed; not written to Event Logs (if the scan was cut off before the host group was determined, the exception below applies)
Request that arrives with the Teacher or Conditional Learning identity	Passed	Passed

• The blocking response of the WAF (Blocking Status Code and the blocking page) is used only in a group in Blocking Mode. A request whose scan cannot be completed within the time limit is also blocked only there. The only exception: if the scan is cut off while the WAF rules are being loaded and before the host group of the request is determined, a request that comes to a group in Learning or Monitor mode is also blocked as long as the vService has at least one group in Blocking mode; requests that arrive with the Teacher and Conditional Learning identity do not fall under this exception (WAF Mode · Blocking Mode). If Fail-open in the Request Body Limits window is on, these requests are passed both in Blocking mode and in the exception (What happens to a request if the scan exceeds a certain time (2-second scan limit)?).
• The mode is assigned not to the vService but to the Virtual Host Group, and the request falls into a group according to its Host header; on the same vService, while one group is in Learning or Monitor mode, another group can be in Blocking mode (Can I use different modes for different domains on the same vService?). Blocking Status Code and Conditional Blocking Pages are applied across the vService.

Finding the Source of the 418

The source is distinguished from the Debug Mode Logs record of the requests that arrive after the Status field of the vService has been set to Debug Mode; no record is created for requests that arrived before Debug mode was turned on. The Security Action and Termination State columns are hidden by default and are added from the column selector.

Source	Security Action	Termination State
The request fell into another Virtual Host Group in Blocking mode and the WAF blocked it	WAF · Attack blocked; for a request whose scan cannot be completed within the time limit, WAF · Attack blocked — scan timed out	TR7 answered the request (TR7 intercepted or Handled by TR7)
Status code 418 selected in a Bot/DDoS Protection action (e.g. Response Status Code in Bot Protection)	Block decision starting with Threat Protection	TR7 answered the request
Status code 418 selected in a Load Balancer Block or Show Content action	No block decision	TR7 answered the request
Status code 418 selected in an AGS Bot Protection Policy action (Deny Status Code for Deny and Tarpit, Block Status Code for Block, Status Code for Show Content)	No block decision	TR7 answered the request
The Backend Service returns 418	No block decision	Normal

• Which group the request fell into is understood from the host name in the Request column of the record.
• A Load Balancer action and an AGS Bot Protection Policy action look the same in these two columns; to tell them apart, a record with status code 418 is searched for in the actions of the vService and in AGS Bot Protection Policies.
• Except for the timeout, a WAF block also appears in the vService's Event Logs with an Attack blocked record; the record is found with the Request ID on the blocking page (My users are getting a "418" error; what is happening?). A request blocked by the timeout is not written to Event Logs (Why does a request that received 418 not appear in Event Logs?).
• General diagnosis of which layer the block comes from: Legitimate users are being blocked; how do I find which rule is blocking them?

Common Misconceptions

• "A 418 returned in Learning or Monitor mode comes from the WAF." In a group in these modes, the WAF does not return a blocking response, except for the exception of a scan cut off while the rules are being loaded; the 418 comes from another source: mostly from another group in Blocking mode, from a Bot/DDoS Protection, Load Balancer or AGS Bot Protection Policy action, or from the Backend Service.
• "A request whose scan exceeds the time limit is blocked in every mode." This request is blocked only in Blocking Mode, while Fail-open is off; in Learning and Monitor mode, it is passed. The only exception is when the scan is cut off while the rules are being loaded and before the host group is determined: if the vService has a group in Blocking mode, this request is blocked in every group, unless it arrives with the Teacher or Conditional Learning identity.
• "Only the WAF returns the 418 code." 418 is the default Blocking Status Code value of the WAF; it can also be selected as the status code in Bot/DDoS Protection, Load Balancer and AGS Bot Protection Policy actions. If the Blocking Status Code has been changed, the WAF block also returns with a code other than 418.

How it is done in the documentation

• WAF Mode · Learning Mode
• WAF Mode · Monitor Mode
• WAF Mode · Blocking Mode
• Blocking Page · Blocking Status Code
• Debug Logs · Debug Logs Listing Screen
• Debug Logs · Termination State Values

Related questions

• My users are getting a "418" error; what is happening?
• What happens to a request if the scan exceeds a certain time (2-second scan limit)?
• Can I use different modes for different domains on the same vService?
• Why does a request that received 418 not appear in Event Logs?