Why is the 418 status code returned by default on a block; can I change it?

Short answer

418 (I'm a teapot) is the product default of TR7 WAF; since it differs from the 403, 404 or 5xx responses produced by the application and the infrastructure, it is easily told apart as a WAF block in logs and monitoring tools. Yes, it can be changed: a status code that can carry a body (e.g. 403) is selected from the Blocking Status Code list in the Blocking Page window; a free number is not entered. In Conditional Blocking Pages entries, a separate code can be selected for each condition; entries with Use default status code selected use the general code. The code change is saved with Edit and is applied without a separate deployment step; in WEB-CLI, the field is named --blockingStatusCode.

Problem: The 418 Code Is Unexpected for Clients or Monitoring Tools

Some clients, API gateways or monitoring rules expect a common code such as 403 for a block; 418 may not be recognized by these tools. The status code of the blocking response is to be selected according to the organization's expectation.

Solution: Two Methods

The two methods write the same field; one of them is selected. For a different code depending on a condition, conditional blocking pages are used (Can I define different blocking pages depending on conditions (Conditional Blocking Pages)?).

Your situation	Suitable method
I will change the code from the interface	Method 1: Blocking Status Code
I will change it with a script or the command line	Method 2: WEB-CLI

Method 1: Blocking Status Code Recommended

• How it works The status code of the blocking response is selected from the list; all blocks whose conditional page does not match are returned with this code.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Blocking Page card → pencil icon
• Requirement WAF-enabled HTTP vService
• Selectable codes Codes that can carry a body in the 2xx, 3xx, 4xx and 5xx classes; 1xx, 204 and 304 are not in the list

Step-by-Step Configuration

1

Adım 1 Open the Blocking page window

In the Left Monitor Panel → WAF-Protected vServices → vService → WAF Management tab, the pencil icon at the top right of the Blocking page card in the Inspection & Blocking section is clicked.

2

Adım 2 Check the source selection

Blocking Page Source and the selected page are verified. If the window has never been saved after WAF was turned on, it opens with Content Profile and WAF Blocking Page (English) selected; with the save, the default page switches to this selection (Can I change the blocking page?).

3

Adım 3 Select the code

The code is selected from the Blocking Status Code list (e.g. 403); the codes are listed with their descriptions.

4

Adım 4 Save

Edit is clicked; the change is applied without a separate deployment step. In a cluster setup, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent to the peer device manually.

Verification

1Blocking page cardTR7 side

The sentence of the Blocking page card on the WAF Management tab is examined.

Expected… with status 403

2Blocked requestClient side

A request that triggers a signature is sent to the host group in Blocking mode.

Command: curl -s -o /dev/null -w "%{http_code}\n" "https://www.example.com/?q=%3Cscript%3Ealert(1)%3C/script%3E"

Expected403

In Event Logs, the decision appears as Attack blocked regardless of the status code.

Method 2: WEB-CLI

• How it works The code is written to the --blockingStatusCode field with WEB-CLI.
• Where it is opened WEB-CLI → waf options update
• Requirement WEB-CLI access
• Scope Only the general code; the codes of the conditional pages do not change

Step-by-Step Configuration

1

Adım 1 Write the code

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

Verification

1Setting recordTR7 side

The WAF settings of the vService are displayed.

Command: waf options show poolId <vService>

ExpectedblockingStatusCode 403

Common Mistakes

• Thinking that 418 is a sign of an error. 418 is WAF's deliberate blocking response; why the request was blocked is seen in Event Logs (My users are getting a "418" error; what is happening?). A 418 that has no record in Event Logs may be a request blocked in Blocking mode because its scan could not be completed within the time limit; this request appears in Debug Mode Logs only while the vService is in Debug Mode (Why does a request that received 418 not appear in Event Logs?).
• Thinking that the code of the conditional pages changes as well. A conditional page with its own code selected continues to be returned with that code; only entries with Use Default Status Code selected follow the general code. The conditional page added by the bilingual ready-made template carries, as its own code, the general code at the moment the template was applied.
• Opening the window only for the code and not checking the page selection. On a vService whose saved settings have no source selection, the window opens with Content Profile and WAF Blocking Page (English) selected; when it is saved, the default page also switches to this selection.
• Looking for a code that does not carry a body. Codes that do not carry a body, such as 204 and 304, are not in the list.

How it is done in the documentation

• Blocking Page · Blocking Status Code
• Blocking Page · Conditional Blocking Pages
• WEB-CLI waf options · The Blocking Page

Related questions

• My users are getting a "418" error; what is happening?
• Can a request be blocked with 418 even in Learning or Monitor mode?
• Can I define different blocking pages depending on conditions (Conditional Blocking Pages)?