Can I take automatic action when the number of requests / connections suddenly increases?
Short answer
Yes. For a sudden vService-wide increase, the Frontend Number of HTTP Requests/s, Frontend Number of New Sessions/s and Frontend Connection conditions are bound to an action (Block or Show Content on HTTP, TCP Connection Management on L7 TCP); as long as the value exceeds the threshold, the action is applied automatically, and it stops when the value drops below the threshold. Since these conditions look at the vService total, legitimate clients are also affected when the threshold is exceeded; a per-client distinction is made with Quarantine. If Bot/DDoS Protection is on, L7 DDoS Protection does the same job with a time window and a hard ceiling through its Total Request Protection, Total Connection Protection and Source IP Connection Protection protections.
Problem: A Sudden Traffic Increase Brings the Service Down
In sudden traffic increases caused by a campaign, news or an attack, the Backend Services take load above their capacity. An automatic response is wanted that blocks part of the traffic, shows a waiting page or limits the clients when the threshold is exceeded.
Solution: Four Methods
Method 1 responds to the vService total and Method 2 to individual clients; the two can also be used together. Method 3 does the same job with protection cards on vServices that have a Bot/DDoS license; Method 4 is the command-line equivalent of Methods 1 and 3.
| Your situation | Suitable method |
|---|---|
| A waiting page or a block for everyone when the vService total exceeds a certain threshold | Method 1: Frontend conditions + action |
| Only the clients that open excessive requests or connections should be blocked for a period | Method 2: Quarantine (per client) |
| Bot/DDoS protection is on; a time-windowed total and per-source limit | Method 3: Bot/DDoS → L7 DDoS Protection |
| Setup from the command line | Method 4: WEB-CLI |
Method 1: Frontend Conditions + Action Recommended
- How it works The condition reads the instantaneous total value of the vService: Frontend Number of HTTP Requests/s the HTTP requests per second, Frontend Number of New Sessions/s the new sessions per second, and Frontend Connection the number of currently open connections. No measurement window is set; as long as the value stays above the threshold, the action is applied to every request.
- Where it is openedLoad Balancer → Conditions · Load Balancer → Actions
- Requirement None
- vService type HTTP · L7 TCP (Frontend Number of HTTP Requests/s only on HTTP; Block and Show content only on HTTP, TCP Connection Management only on L7 TCP)
Step-by-Step Configuration
The condition form is opened with Load Balancer → Conditions → Add (how to add).
Condition Name = yuksek-istek and Criteria = Frontend Number of HTTP Requests/s are selected; Operator = Greater than (>) and the threshold (e.g. 5000) are entered. The form opens with the = operator selected; the value is an integer. For an L7 TCP vService, Frontend number of new sessions/s or Frontend connection is selected.
The condition is saved with Add.
The action form is opened with Load Balancer → Actions → Add.
On HTTP, Action Type = Show Content is selected, and then the waiting page and Status Code = 503 are selected (page preparation: How do I publish a maintenance page?); for a direct block, Block and Status Code = 503 are selected. On L7 TCP, Action Type = TCP Connection Management and Action = Reject or Silent drop are selected.
yuksek-istek is selected in the Conditions field.
The action is saved with Add.
On the Load Balancer → Load Balancer vService List screen, the vService is selected and the edit form is opened with Edit.
The form is saved with Save. In a cluster, the configuration is transferred to the peer device automatically by default (with Synchronize if Manual Sync Mode is on); the threshold is evaluated with each device's own traffic.
Verification
Requests above the threshold are sent with a load testing tool (e.g. ab -n 100000 -c 200 https://www.example.com/).
503 when the threshold is exceeded; 200 when the load dropsIf Hit counter is enabled in the action, the Action Hits tab of the vService dashboard is checked.
An increase at the moment of the thresholdMethod 2: Quarantine (Per Client)
- How it works The requests or connections of each client are counted separately in the Tracking Time window; a client that exceeds the threshold is met with the Quarantine Action for the Quarantine Time, and the other clients are not affected.
- Where it is openedLoad Balancer → Actions → Quarantine
- Requirement None
- vService type HTTP · L7 TCP (on L7 TCP, Tracking key is only IP or Manual and Quarantine action is only Silent drop; HTTP-specific criteria cannot be used)
Step-by-Step Configuration
The action form is opened with Load Balancer → Actions → Add (how to add); Action Name is entered and Action Type = Quarantine is selected.
Tracking Key is left as IP (default), and Tracking time is entered. In the form opened with (+) in the Quarantine Condition field, Criteria = Quarantine condition, Tracking Criteria = Current connections, Total connections or HTTP requests, and the threshold with Tracking operator are entered, and the condition is added. Quarantine time and Quarantine action are selected.
The action is saved with Add. Detailed setup: Can I do rate limiting (X requests per second per IP)?
The HTTP or L7 TCP vService is opened with Edit.
The form is saved with Save.
Verification
In the Logs & Tracking tab of the vService, the <action-name> (QUARANTINE, <duration>) source is opened (quarantine logs).
The client that exceeds the threshold is listedMethod 3: Bot/DDoS → L7 DDoS Protection
- How it works The protections take the measurement in a time window and apply the selected action when the limit is exceeded. Defaults: Total Request Protection 10,000 requests in 10 seconds, Show captcha (HTTP only); Total Connection Protection 5,000 connections in 10 seconds, Silent drop; Source IP Connection Protection 100 connections in 10 seconds per source, Silent drop. There are also Source IP Request Protection for requests per source (1,000 requests in 10 seconds, Show captcha; HTTP only) and Active Source-IP Protection for the number of active source addresses.
- Where it is opened Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management → L7 DDoS Protection card
- Requirement Bot/DDoS protection license; L7 DDoS & Threat Protection on in the vService; L7 DDoS Protection Active
- vService type HTTP · L7 TCP
Step-by-Step Configuration
If the protection is not on in the vService, the vService is edited, the L7 DDoS & Threat Protection box under Details (HTTP · L7 TCP) is checked, and the form is saved with Save (two ways). When the protection is turned on, IP Reputation Protection starts in Active mode (starting modes).
On the Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management tab, the Edit link of the L7 DDoS Protection card is clicked.
DDoS Protection = Active is selected and the window is saved with the Edit button. In the default Monitor mode, exceeding the limit is only recorded; traffic is not blocked.
On the L7 DDoS Protection card, in the window opened with the pencil icon at the top right of the Total Request Protection, Total Connection Protection and Source IP Connection Protection blocks, the limit, Time window and Limit action are set; each window is saved with the Edit button.
Verification
The Bot/DDoS Event Logs → L7 DDoS tab is opened.
The action applied to the traffic exceeding the limitMethod 4: WEB-CLI
- How it works The condition and the action in Method 1 are set up with
lb condition/lb action, and the Total Request Protection in Method 3 withlb threat-protection. - Where it is opened TR7 WEB-CLI →
lb condition·lb action·lb service·lb threat-protection - Requirement WEB-CLI access; Bot/DDoS protection license for Method 3
- vService type HTTP (for L7 TCP, the condition becomes
fe_connand the actiontcp_conn_mgmtwith--tcpAction reject)
Step-by-Step Configuration
WEB-CLI runs each line as a separate command; commands are written on a single line. The > sign is written inside double quotes.
Numeric criteria: fe_req_rate = Frontend Number of HTTP Requests/s, fe_sess_rate = Frontend Number of New Sessions/s, fe_conn = Frontend connection.
lb condition add criteria fe_req_rate --fe_req_rate_op.op ">" --fe_req_rate_op.val 5000 --name yuksek-istekThe --cond field of the action requires the ID of the condition, not its name. lb condition add gives no output when it succeeds; the ID is seen in the id column of the list below (it starts with lbConditions-).
lb condition listlb action add type deny name yuksek-yuk --denyStatusCode 503 --cond <high-request-id>The rules.0, rules.1… lines show the actions bound to the vService.
lb service show <vService>The new action is written to the first empty index, that is, to the number of existing actions. In the example, since the vService has two actions (rules.0, rules.1), --rules.2 is used; writing to a filled index replaces the action there.
lb service update id <vService> --rules.2 yuksek-yukIf the protection is off, it is turned on first; --ddosProtection true sets L7 DDoS Protection to Active (WEB-CLI · threat-protection).
lb service update id <vService> --threatProtection true
lb threat-protection update id <vService> --ddosProtection true --ddosTotalRequestProtection true --ddosTotalRequestLimit 50000 --ddosTotalRequestWindow.val 10 --ddosTotalRequestWindow.unit sVerification
Command: lb threat-protection show <vService>
ddosTotalRequestLimit: 50000Common Mistakes
- Thinking that a vService-wide condition affects only attackers. Frontend conditions look at the total value; when the threshold is exceeded, legitimate users are affected too. Quarantine is used for a per-client distinction.
- Mistaking vService Limits for an automatic action. vService Limits are fixed ceilings; at the ceiling, new requests are kept waiting and no separate action is applied (What happens when the connection limit is reached?).
- Leaving Bot/DDoS in Monitor. While L7 DDoS Protection is in Monitor mode, exceeding the limit is only recorded; for the traffic to be blocked, the mode is set to Active.
- Writing the condition name in the
--condfield. In WEB-CLI,--condexpects the condition ID; if the name is written, the action is bound to a condition that does not exist.
How it is done in the documentation
Related questions
