I am blocking legitimate users by mistake; how do I find out?

Short answer

First, the layer that gave the block is found. On the HTTP vService, Debug is turned on limited to the user's address only, and the request is examined in the Debug Mode Logs source in the Logs & Tracking tab of the vService; the Security Action column and the WAF and Threat Protection boxes in the preview show which module gave the decision. If the request returned with a code such as 403 while these fields are empty, the block comes from a Load Balancer action; Hit Counter and Action Hits show which action ran. WAF and Bot/DDoS false positives are read on their own Event Logs screens (WAF · Bot/DDoS) and are resolved from there; quarantine and AGS locks are seen in their own tables.

Problem: It Is Not Known Which Rule Gave the Block

A user receives 403, the page does not open or the connection is cut. Since Load Balancer actions, WAF, Bot/DDoS, quarantine and AGS can work together on the same vService, the correct fix cannot be made without finding which layer gave the block. For the flow of finding the source of a specific block step by step: Legitimate users are being blocked; how do I find which rule is blocking them?

Solution: Five Methods

Method 1 shows the layer that gives the decision; Methods 2–5 find the record on that layer's own screen and fix it.

Your situation	Suitable method
First step: it is not known which module gave the decision (HTTP vService)	Method 1: Debug Mode Logs → Security Action
The block is from a Load Balancer action (Block, Show content, Quarantine…)	Method 2: Hit Counter · Action Hits · Set Variable on Hit
The block is from WAF	Method 3: WAF Event Logs → Allow / Teach
The block is from Bot/DDoS	Method 4: Bot/DDoS Event Logs
The user is in quarantine or locked in AGS	Method 5: Quarantine tables · AGS Lockout

Method 1: Debug Mode Logs → Security Action Recommended

• How it works The debug record keeps the details of the request and the decision of the security modules. The Security Action column writes which module terminated the request in the <module> · <verdict> form (e.g. Threat Protection · Blocked); it shows only WAF and Bot/DDoS decisions.
• Where it is opened vService Edit → Details → Debug · vService → Logs & Tracking → Debug Mode Logs
• Requirement None
• vService type HTTP (Debug exists only on the HTTP vService)

Step-by-Step Configuration

1

Adım 1 Open the condition form (if needed)

If there is no condition for the user's address yet, the condition form is opened with Load Balancer → Conditions → Add.

2

Adım 2 Define the user's address

Criteria = Source IP, Source IP Type = Manual are selected and the user's address is entered.

3

Adım 3 Save the condition

The condition is saved with Add.

4

Adım 4 Edit the vService

On the Load Balancer → Load Balancer vService List screen, the HTTP vService is selected and the edit form is opened with Edit.

5

Adım 5 Narrow Debug down to the user

Debug is checked under Details, and the condition from steps 1–3 is selected in the Select Conditions field (conditional debug). If no condition is selected, all requests are recorded.

6

Adım 6 Save

The form is saved with Save; the Status value of the vService becomes Debug Mode. The user is asked to repeat the request.

7

Adım 7 Open the Debug records

In Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking tab, the Debug Mode Logs source is selected (listing screen).

8

Adım 8 Turn on the Security Action column

With Columns, the Security Action and Termination State columns, which are hidden by default, are turned on.

9

Adım 9 Examine the record

The user's request is selected; in the Summary tab of the preview, WAF (Verdict, Attacks, Triggered rules), Threat Protection (Bot Score, Handled By, Action Taken, Monitor mode) and Termination State are read. If Security Action is empty and the response code is an error code such as 403, Method 2 is used.

10

Adım 10 Edit the vService again

When the examination is finished, the vService is opened again with Edit.

11

Adım 11 Turn off Debug

The Debug check under Details is removed; Debug that stays on uses disk and CPU.

12

Adım 12 Save

The form is saved with Save.

Verification

1DecisionTR7 side

In the user's record, the Security Action column and the Summary tab are read.

ExpectedWAF · … or Threat Protection · … ; if empty, a Load Balancer action

Method 2: Load Balancer Actions → Hit Counter · Action Hits · Set Variable on Hit

• How it works The Security Action column does not show Load Balancer actions. Which action ran is found from the action counters (Hit Counter → Action Hits) and from the traffic variable that the action leaves on the request (Set Variable on Hit).
• Where it is openedLoad Balancer → Actions → action → Hit Counter / Set Variable on Hit · vService dashboard → Action Hits
• Requirement None
• vService type HTTP · L7 TCP (Hit Counter exists in actions such as Block, Show content and Quarantine; it does not exist in the TCP Connection Management and Advanced CAPTCHA actions)

Step-by-Step Configuration

1

Adım 1 Edit the action

On the Load Balancer → Actions screen, the suspected action is selected and opened with Edit.

2

Adım 2 Turn on the counter and the variable

Hit Counter is checked. To see on the request itself which action ran, a variable name (e.g. blk_admin; letters, digits and underscores, at most 32 characters) is written in the Set Variable on Hit field; when the action runs, this variable becomes 1.

3

Adım 3 Save the action

The action is saved.

4

Adım 4 Edit the vService (if the variable will be written to the debug record)

On the Load Balancer → Load Balancer vService List screen, the vService is selected and the edit form is opened with Edit.

5

Adım 5 Add the variable to the debug record

The Custom Debug Log Entries switch under Details → Debug is turned on, Entry name is entered and the Traffic variable content variable with this name (%TR7VAR(blk_admin)) is selected as Entry value. The value is seen in the Custom entries table in the Summary tab of the debug record.

6

Adım 6 Save the vService

The form is saved with Save.

7

Adım 7 Monitor the counts

The run count per action is monitored in the Action Hits tab of the vService dashboard (Can I see how many times an action has been triggered (hit counter, Action Hits)?). If the actions are given different Status Code values (e.g. 403, 404, 429), which action gave the response is also understood from the code on the HTTP Logs screen.

If how many requests a new block rule will affect is to be measured in advance, the same condition is first bound to a Create Traffic Variable action with Hit Counter on; after the match count is monitored in Action Hits, Block is switched to. The Block action has no monitoring mode.

Verification

1Action HitsTR7 side

The Action Hits graph is checked at the time of the user's request.

ExpectedAn increase in the series of the blocking action

Method 3: WAF Event Logs → Allow / Teach

• How it works The WAF event record shows the matching signature or the structural violation and the reason for the decision; a false positive is taught to the rule from the record.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs
• Requirement WAF license; a WAF-enabled HTTP vService
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open Event Logs

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

2

Adım 2 Find and read the record

The record is found with the user's address or the request ID; the Action value (e.g. Attack blocked, Not blocked — Monitor mode) and the description in the Attacks tab are read.

3

Adım 3 Teach the false positive

If the record is really a false positive, it is taught to the rule with Allow / Teach. For a trusted source, Whitelist Condition can be used; if a single signature is problematic, its state is set to Monitor on the OWASP rules screen of the vService (State values).

Verification

1RepeatClient side

The user's request is repeated.

ExpectedThe request passes; no new block record in Event Logs

Method 4: Bot/DDoS Event Logs

• How it works The Bot/DDoS event record shows the protection that gave the decision, the rule, the measured value and the limit; protections in Monitor mode also record the action that would be applied. From the record preview, the address, network, ASN, country, User-Agent or JA4 identifier is added to the exemption list.
• Where it is opened Left Monitor Panel → Bot/DDoS Protected vServices → vService → Event Logs
• Requirement Bot/DDoS protection license; L7 DDoS & Threat Protection on for the vService
• vService type HTTP · L7 TCP

Step-by-Step Configuration

1

Adım 1 Open Event Logs

Left Monitor Panel → Bot/DDoS Protected vServices → vService → Event Logs is opened.

2

Adım 2 Find the record

The user's address is searched for; the first place to look is the IP Reputation tab, because IP Reputation Protection works as Active as soon as the protection is turned on. The description in the preview writes the measured value and the limit together; before an exemption is given, it is verified here that the event is really a false positive.

3

Adım 3 Add an exemption

From the preview menu, the narrowest identifier (preferably a single address) is added to the exemption list. Exempting a country or an ASN opens a much wider door.

Verification

1RepeatClient side

The user's request is repeated.

ExpectedThe request passes

Method 5: Quarantine Tables and AGS Lockout

• How it works Clients caught by a threshold are seen in the Quarantine and Advanced CAPTCHA quarantine tables, and users locked in AGS are seen on the Lockout screen, and they are removed from there.
• Where it is opened vService → Logs & Tracking · Left Monitor Panel → AGS-Enabled vServices → vService → Lockout
• Requirement A vService that uses Quarantine or Captcha quarantine; for AGS, an AGS license
• vService type HTTP · L7 TCP (AGS only HTTP)

Step-by-Step Configuration

1

Adım 1 Check the quarantine table

In the Logs & Tracking tab of the vService, the quarantine source is selected, the user's address is searched for and, if needed, removed with Remove from Table; details: How do I see the clients in quarantine?

2

Adım 2 Check the AGS lock

The locked user is searched for on the Lockout screen of the AGS vService; the lock is removed with Clear Lockouts. The sign-in steps are seen on the Audit Logs screen.

Verification

1TableTR7 side

The user's address or name is searched for in the table again.

ExpectedNo record is found

Common Mistakes

• Leaving Debug on without a condition and for a long time. All traffic is recorded; disk and CPU are used unnecessarily.
• Deciding that there is no block because Security Action is empty. Load Balancer actions do not appear in this column; in addition, if the security module did not produce an event, the column stays -.
• Allowing WAF records in bulk. A record taught without the description being read can also allow a real attack.
• Making decisions by IP while TR7 is behind a CDN or proxy. All users appear with the proxy address and are blocked together; the real client address is resolved with Trusted Proxy (There is a CDN such as Cloudflare / Akamai in front of TR7; how do I get the Real client IP (trusted proxy)?).
• Searching the tables on a single device in a cluster. Quarantine and tracking tables are kept per device; the user can be in the table of the other device.

How it is done in the documentation

• Debug Logs · Debug Logs Listing Screen
• Debug Logs · Summary Tab
• WAF Event Logs · Allow / Teach
• Bot/DDoS Event Logs

Related questions

• Legitimate users are being blocked; how do I find which rule is blocking them?
• How do I see the clients in quarantine?
• Can I see how many times an action has been triggered (hit counter, Action Hits)?
• What does Debug Mode record; how long should I keep it on?