My users are getting a "418" error; what is happening?

Short answer

418 is the Blocking Status Code value that the WAF uses by default in its blocking response; a request that receives this response has not been sent to the Backend Service. A WAF-originated 418 arises in two ways: while the host group is in Blocking Mode, the attack score of the request reaches the blocking threshold (the source IP being on the blacklist is also added to the score), or in Blocking mode the WAF scan cannot be completed within the 2-second time limit (while Fail-open in the Request Body Limits window is off, the default). For diagnosis, the Request ID value on the blocking page the user sees is written in the Request Unique ID field on the Event Logs screen of the vService: if there is a record, the Attacks tab shows the triggered rule and the false positive is taught with Allow / Teach; if there is no record, either the request was blocked by the scan timeout or its record was hidden from the list with WAF Log Suppression Condition; the two are told apart in the Debug Mode Logs record (on a timeout, "Attack blocked — scan timed out"). 418 can also come from a Load Balancer Block action in which it is selected as the status code, or from the Backend Service itself. To let the traffic through while the examination continues, the host group is set to Monitor Mode; this stops all the WAF blocks in that group caused by rules, the blacklist and the scan timeout.

Problem: Users Are Getting a 418 Response

Users see the page titled "Your Access To This Page Has Been Blocked!" in the browser, and API clients see the HTTP 418 response. The built-in blocking page shows the time of the request, the Request ID value and the IP Address information of the client (Which Smart Variables can I use on the blocking page (%UID, %SRCIP, %WAFSCORE, %WAFINFO …); is it safe to show attack details?). Without finding which layer the block comes from and which rule was triggered, the correct fix cannot be chosen.

Possible Causes

Cause	In which mode it blocks	In Event Logs	In the WAF box of the Debug Mode Logs record
The attack score reached the blocking threshold (signature or structural rule)	Only Blocking Mode	There is a record; the decision is Attack blocked, the signature or rule name is on the Attacks tab	Verdict = Attack blocked
The source IP is on the blacklist	Only Blocking mode	There is a record; Attack Name = Blacklisted IP, Severity = Blacklist	Verdict = Attack blocked
There is a score or blacklist block, but the request matches WAF Log Suppression Condition	Only Blocking mode	The record is written but not listed	Verdict = Attack blocked
The WAF scan could not be completed within the 2-second time limit	Only Blocking mode (apart from an exception that can occur while the rules are being loaded; while Fail-open is off, the default)	No record	Verdict = Attack blocked — scan timed out, Triggered Rules = 369999
Status code 418 is selected in the Load Balancer Block action	-	No record	No WAF box
The Backend Service itself returns 418	-	No record	No WAF box

Definitive rules:

• The status code of a WAF block comes from the Blocking Status Code field (default 418). If a specific status code is selected for a Conditional Blocking Pages row, that code is returned in the requests that match the condition; therefore, a WAF block can also come with a code other than 418.
• In a host group in Learning Mode, in a request that arrives with the Conditional Learning identity and in a request recognized by Teacher, the attack score does not block; a request whose scan cannot be completed within the time limit is also passed, apart from an exception that can occur while the rules are being loaded. In these requests, the WAF does not return 418; a 418 that is seen comes from a layer other than the WAF.
• In Monitor Mode, a request that exceeds the threshold and a source on the blacklist are not blocked; only an Event Logs record is written (decision Not blocked — Monitor mode).
• Requests that match Whitelist Condition, requests treated as static content and requests that start with AGS Root Path never enter the WAF; no WAF-originated 418 is returned to these requests.

Where Is It Monitored?

Screen	Path	What it shows
Event Logs	Left Monitor Panel → WAF-Protected vServices → vService → Event Logs	Blocks caused by the score and the blacklist; the triggered signatures, the matching rule, the teaching suggestion
Global WAF Event Log	Configuration Menu → WAF → Global WAF Event Log	The records of all WAF-protected vServices; if the vService is not known, the Request Unique ID search is done here
Debug Mode Logs	Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → Debug Mode Logs	The Security action value of each request and the WAF box (Verdict, Attacks, Triggered rules); the timeout appears only here
HTTP Logs	The HTTP logs source on the same tab	The response status code (418) and the party that produced the response (Backend service: TR7 or the name of the server)

How to Diagnose?

1. The Request ID value on the blocking page and the time of the event are obtained from the user. If the API client does not show the page body, the response body is saved, or the time and the client IP are noted.
2. Left Monitor Panel → WAF-Protected vServices → vService → Event Logs is opened; the value is written in the Request Unique ID field in the server filter, Date Range (default Last 7 day(s)) is selected so that it covers the time of the event, and Save & Get Logs is clicked (How do I find a specific request by its Request Unique ID?). If the vService is not known, the same search is done on the Global WAF Event Log screen.
3. If a record comes, the row is clicked; on the Attacks tab of the preview, Corresponding Rule, Attack Name, Attack Area, Description (with the matching part highlighted) and Learning Suggestion are read. If Attack Name = Blacklisted IP, the block is from the blacklist. If the record is a real attack, nothing is changed.
4. If no record comes, the edit form of the vService is opened on the Load Balancer → Load Balancer vService List screen, Debug mode is selected in the Status field, Save is clicked and the user is asked to repeat the request; Debug mode records only the requests that arrive after it is turned on (What does Debug Mode record; how long should I keep it on?). Turning on Debug mode requires modify permission in the Load Balancer area, and viewing Debug Mode Logs requires monitoring permission in the Load Balancer area; for a user who has only WAF permission, these screens do not open (Logs & Tracking).
5. Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → Debug Mode Logs is opened; the Security Action column, which is hidden by default, is added from the Columns menu. If the value is WAF · Attack blocked — scan timed out · 1 attacks and the WAF box on the Summary tab of the row shows Triggered rules = 369999, the request was blocked by the scan timeout: Why does a request that received 418 not appear in Event Logs?. If the value is WAF · Attack blocked · …, the block is from the score or the blacklist, and the record was hidden from the list with WAF Log Suppression Condition; the condition is seen on the Log Settings card in WAF Management.
6. If the row has no WAF box and Security action is -, the block did not come from the WAF; if Backend Service in HTTP logs is the name of the server, the 418 was produced by the Backend Service; if it is TR7, the Load Balancer actions are examined (Legitimate users are being blocked; how do I find which rule is blocking them?).
7. When the examination is finished, Status is set back to Enabled and saved.

Solution: Four Methods

The methods are alternatives to each other. The permanent fix is Method 1; Method 2 lets the traffic through while the examination continues, and Method 3 changes only the code returned to the client.

Your situation	Suitable method
There is a record in Event Logs and the block is a false positive (including a blacklist hit)	Method 1: Allow / Teach from Event Logs
The traffic needs to be let through immediately while the block is being examined	Method 2: Setting the host group to Monitor mode
API clients cannot handle 418; another code is wanted	Method 3: Blocking Status Code
The mode or the status code is to be changed from the command line	Method 4: WEB-CLI
The same signature produces false positives everywhere on this vService	Can I disable a signature on a single vService only, rather than device-wide?
There is no record in Event Logs; Debug Mode Logs shows a timeout	Why does a request that received 418 not appear in Event Logs?
The block does not come from the WAF	Legitimate users are being blocked; how do I find which rule is blocking them?

Method 1: Allow / Teach from Event Logs Recommended

• How it works The attack in the record is taught as a false positive: the signature is put into an OWASP exclusion for that field, the structural limit is widened, or, on a blacklist hit, the address is added to the Frontend Blacklist Exclusions list. The change to be made is written in advance in the Learning Suggestion row.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs → record → Attacks
• Requirement Modify permission in the WAF area; the record being present in Event Logs (host group in Monitor or Blocking mode)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the Event Logs screen

In the Left Monitor Panel, the WAF-Protected vServices category is selected, the vService is clicked and the Event Logs tab is opened.

2

Adım 2 Enter the scope of the record

On the server filter tab at the beginning of the filter strip, the Request ID given by the user is written in the Request Unique ID field; Date Range is selected so that it covers the time of the event (server filter).

3

Adım 3 Fetch the record

Save & Get Logs is clicked; only the record of this request is listed.

4

Adım 4 Open the record

The row is clicked and the Attacks tab is selected in the preview that opens on the right. The tab opens with the first attack selected; Corresponding Rule, Attack Name, Description and Learning Suggestion are read.

5

Adım 5 Select the false positive attack

In the attack table, the box at the beginning of the row is checked only for the attack that is a false positive. If a real attack is also checked, it is taught as well.

6

Adım 6 Click Allow / Teach

The button above the table is clicked. The button is named Allow on a blocked record, and Teach on a record that was monitored or passed by Teacher (Allow / Teach).

7

Adım 7 Confirm

Yes is clicked in the Are you sure? question. The change is applied without a separate save or deployment step; the first number in the Attacks column of the record drops, and if all the attacks have been taught, the row turns green. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize. Details: How do I allow a request that was blocked by mistake?

Blacklist hit

For an attack with Attack Name = Blacklisted IP, teaching adds the address to the Frontend Blacklist Exclusions list of the vService; the same operation is also done with the Add to Whitelist option in the menu of the Attacker IP row in the preview (the name of the vService is written next to the option). Both ways only take the address out of the blacklist; WAF inspection continues (Does "Add to Whitelist (vService)" in Event Logs exempt an IP from WAF inspection, or does it only add a blacklist exclusion?).

Verification

1Attacks columnTR7 side

The Attacks column of the taught record in Event Logs is examined.

ExpectedFirst number 0; row green

The first number of the column shows how many attacks the same request would trigger with the current rule set (Attacks column).

2Repeat requestClient side

The user repeats the same operation.

ExpectedThe normal response of the application; no new record in Event Logs

Method 2: Setting the Host Group to Monitor Mode

• How it works In Monitor mode, inspection and scoring continue; requests that exceed the threshold are not blocked and are only written to Event Logs; a source on the blacklist is not blocked either. A request whose scan cannot be completed within the time limit is also passed in this mode (the only exception is when the scan is cut off while the WAF rules are being loaded and before the host group is determined: if the vService has a group in Blocking mode, this request is blocked (WAF Mode · Blocking Mode)).
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → mode card → Edit
• Requirement Modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the WAF Management tab

Left Monitor Panel → WAF-Protected vServices → vService → WAF Management is opened. At the top, there is a mode card for each host group; if there are multiple groups, the group that the blocked request fell into is seen in the Host Group row of the Request & Location tab in the Event Logs preview.

2

Adım 2 Open the host group window

Edit on the relevant mode card is clicked; the host group window opens (WAF Mode Edit screen).

3

Adım 3 Select Monitor mode

In the WAF Mode field, Monitor mode is selected.

4

Adım 4 Save

Edit in the window is clicked; the mode is applied without a separate deployment step. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize. After the false positive is resolved, the group is switched back to Blocking Mode with the same steps.

Verification

1Event Logs decisionTR7 side

The same request is repeated and the pointer is held over the Action icon of the new record in Event Logs.

ExpectedNot blocked — Monitor mode

If the request still receives 418, the block does not come from this host group: the request falls into another host group in Blocking mode, or the 418 comes from a layer other than the WAF; the two are told apart with the WAF box in the Debug Mode Logs record.

Method 3: Blocking Status Code

• How it works The status code in the blocking response of the WAF is changed (e.g. 403). The blocking decision does not change; only the code returned to the client changes.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Inspection & Blocking → Blocking Page card
• Requirement Modify permission in the WAF area
• vService type HTTP (the setting is common to all the host groups of the vService)

Step-by-Step Configuration

1

Adım 1 Open the WAF Management tab

Left Monitor Panel → WAF-Protected vServices → vService → WAF Management is opened.

2

Adım 2 Open the Blocking page window

The pencil icon of the Blocking Page card in the Inspection & Blocking section is clicked; the Blocking Page window opens (Blocking Page Edit screen).

3

Adım 3 Select the status code

The new code is selected from the Blocking Status Code list (default 418; the list contains the codes that can carry a body, and a free number cannot be entered). The Conditional Blocking Pages rows that have Use Default Status Code selected also use this code.

4

Adım 4 Save

Edit is clicked; the setting is applied without a separate deployment step. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize. Details: Why is the 418 status code returned by default on a block; can I change it?

Verification

1Blocked requestClient side

A request that is known to be blocked is repeated.

Command: curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/

ExpectedThe selected code (e.g. 403)

The sentence on the Blocking page card also shows the new code (with status 403).

Method 4: WEB-CLI

• How it works The settings in Method 2 and Method 3 are changed with WEB-CLI commands.
• Where it is opened WEB-CLI → waf host-groups · waf options
• Requirement WEB-CLI access and modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Get the host group ID

The id field takes the ID of the host group, not its name; the ID is read from the list (waf host-groups):

waf host-groups list poolId <vService>

2

Adım 2 Set the host group to Monitor mode

In place of <group-id>, the ID from step 1 is written:

waf host-groups update poolId <vService> id <group-id> --mode monitor

Blocking mode is set back with --mode blocking.

3

Adım 3 Change the status code (if needed)

waf options update poolId <vService> --blockingStatusCode 403 --syncWithDefaultFwRules false

--syncWithDefaultFwRules is not a stored setting but a write trigger: only when true is written is the Any paths rule rebuilt with its default definition; if it is not written in the command, the rule set is not touched. The false in the command states this explicitly (Sync with Default WAF Rules; basic inspections).

Verification

1RecordTR7 side

The host group record is displayed again.

Command: waf host-groups show poolId <vService> <group-id>

Expectedmode monitor

Common Mistakes

• Looking for the block outside the WAF when there is no record in Event Logs. Requests blocked by the scan timeout are not written to Event Logs; the WAF box in Debug Mode Logs is examined (Why does a request that received 418 not appear in Event Logs?).
• Attributing every 418 to the WAF. 418 can also be selected as the status code in the Load Balancer Block action, and the Backend Service itself can return 418; if there is no WAF box in Debug Mode Logs, the block is from another layer.
• Assuming that switching to Monitor mode will also stop the 418s outside the WAF. Monitor mode stops only the WAF blocks in that host group (including the scan timeout); a 418 that comes from the Load Balancer Block action or from the Backend Service continues (Can a request be blocked with 418 even in Learning or Monitor mode?).
• Teaching all the attacks of the record. If the same request also contains a real attack, it is taught as well; only the false positive attack is checked.
• Leaving Monitor mode on. If the host group is not set back to Blocking Mode after the false positive is resolved, attacks are not blocked.
• Changing the status code to a success code such as 200. The blocked request appears successful to the client, and test tools do not notice the block.

How it is done in the documentation

• Event Logs · Request Unique ID
• Event Logs · Attacks Tab
• Blocking Page · Blocking Status Code
• WAF Mode · Blocking Mode
• Debug Logs · Summary Tab

Related questions

• What does a blocked user see?
• How do I tell that a legitimate request was blocked by the WAF?
• Why does a request that received 418 not appear in Event Logs?
• Which decisions does the WAF make for a request; what do Action in Event Logs and Verdict in Debug Mode Logs mean?