Legitimate users are being blocked; how do I find which rule is blocking them?

Short answer

First, what the user sees is determined, because each protection layer leaves a different trace. With the default settings, a block page with code 418 points to WAF (Blocking Status Code), 403 or another selected code points to the Load Balancer Block action or a block by Bot/DDoS protection, a CAPTCHA page points to the Advanced CAPTCHA action or Bot/DDoS protection, and a connection that drops without a response points to Silent Drop (Quarantine, Block, TCP Connection Management or Bot/DDoS). If the layer that issued the block cannot be pinned down, Debug Mode narrowed to the user's IP is turned on in the vService, and the Security Action field in the Debug Mode Logs record is read; this field shows WAF and Bot/DDoS decisions, it does not show Load Balancer actions. Step-by-step diagnosis of each layer: I am blocking legitimate users by mistake; how do I find out?

Problem: The Layer That Issued the Block Is Unknown

A user reports being unable to access the site. Since WAF, Bot/DDoS, Load Balancer actions, Quarantine and AGS can work together on the same vService, which layer to check is determined first; the record of each layer is kept on its own log screen.

Where Is It Monitored?

Screen	Path	What it shows
WAF Event Logs	WAF-Protected vServices → vService → Event Logs	WAF blocks and detections
Bot/DDoS Event Logs	Bot/DDoS Protected vServices → vService → Event Logs	Bot/DDoS decisions
Action Hits	Load Balancer vServices → vService → Dashboard	Trigger counts of the actions with Hit Counter on
Quarantine Logs · Advanced CAPTCHA Tracking Logs	vService → Logs & Tracking	Clients in quarantine and CAPTCHA passes
Lockout	AGS-Enabled vServices → vService	Accounts and sources locked in AGS
Debug Mode Logs	vService → Logs & Tracking (while in Debug Mode)	The Security Action and Termination state values of a single request

Solution

The response the user sees determines the layer; then that layer's own log screen is checked and the record is corrected.

From Symptom to Layer

• How it works The response the user sees largely determines the layer that issued the block; then that layer's own log screen is checked.
• Where it is opened The user's screen · the related log screen (Logs & Tracking · What Is Done Where?)
• Requirement The user's IP address, the time of the event, and the screen or status code the user saw.
• vService type HTTP · L7 TCP

Step-by-Step Configuration

1

Adım 1 Collect the symptom

The IP address, the time of the event, and a screenshot of the screen seen or the status code in the browser developer tools are obtained from the user. If TR7 is behind a CDN or proxy and no Trusted Proxy profile is assigned to the vService, all users appear in the records with the proxy's address.

2

Adım 2 Match the layer

What the user sees	Possible layer	Where to look
Block page with code 418	WAF (Blocking mode; the code may have been changed in the Blocking Status Code field)	WAF Event Logs
403 or another selected code	Load Balancer Block or Show Content action (the Status code default of Block is 403) or a Bot/DDoS block (the Response status code default is 403)	The action's Hit Counter · Action Hits · Bot/DDoS Event Logs
CAPTCHA page or CAPTCHA loop	Advanced CAPTCHA action or the CAPTCHA response of Bot/DDoS	Advanced CAPTCHA Tracking Logs · Bot/DDoS Event Logs
No response, the connection drops	Quarantine (default Silent Drop), Block's Deny Type = Silent Drop, TCP Connection Management, Bot/DDoS	Quarantine Logs · Bot/DDoS Event Logs
The login is not accepted, the account is locked	AGS Lockout	Lockout screen
The symptom is unclear	-	Conditional Debug Mode → Security Action
Many users at the same time	Trusted Proxy is missing; all users appear from a single address	There is a CDN such as Cloudflare / Akamai in front of TR7; how do I get the Real client IP (trusted proxy)?

While Bot/DDoS protections are in Monitor mode, no block is applied; only a record is created.

3

Adım 3 Find and correct the record in the related layer

The use of the log screen in the table and the correction of the record (Allow/Teach in WAF, narrowing the condition in the action, removing from quarantine) are explained step by step on this page: I am blocking legitimate users by mistake; how do I find out? For quarantine: How do I see the clients in quarantine?

Verification

1RepeatClient side

After the correction, the user repeats the same request.

ExpectedThe request passes

2RecordTR7 side

The related log screen is filtered by the user's IP.

ExpectedNo new block record is created

Common Mistakes

• Assuming every 403 is WAF. The default block code of WAF is 418; 403 comes from the Block action or a Bot/DDoS block.
• Deciding there is no block because Security Action is empty. Load Balancer actions do not appear in this field; Hit Counter and Action Hits are checked.
• Searching with the user's real IP behind a CDN. Without Trusted Proxy, the records contain the proxy's address.
• Blaming the Bot/DDoS protection in Monitor mode. In Monitor mode, no block is applied; only a record is created.
• Asking for support without collecting information if the problem persists. What to add to the support ticket: Which information should I collect before contacting TR7 support?

How it is done in the documentation

• Logs & Tracking · What Is Done Where?
• WAF Blocking Page · Blocking Status Code
• Block · Deny Type

Related questions

• I am blocking legitimate users by mistake; how do I find out?
• How do I see the clients in quarantine?
• There is a CDN such as Cloudflare / Akamai in front of TR7; how do I get the Real client IP (trusted proxy)?