How do I change the evaluation order of Conditional Backend Services blocks?
Short answer
Conditional Backend Services (Content Switching) blocks are evaluated from top to bottom in the order they appear in the vService form, and the first block whose condition is met receives the request; the following blocks are not checked. To change the order, the block is held by the four-way arrow icon on its left edge and dragged onto another block, and the vService is saved with Save. If no block matches, the request goes to the Default Backend Services list.
Problem: A General Rule Shadows a Specific Rule
Since the blocks work with first-match logic, if a general condition (e.g. Path starting with /) is above a more specific condition (e.g. Path starting with /api/), the specific block never matches and the /api/ requests also go to the Backend Services of the general block. For the specific rules to come before the general rules, the block order must be changed.
Solution
Ordering with Drag and Drop
- How it works The block is dropped onto another block; a block dragged down is placed after the target block, and a block dragged up is placed before the target block. The order of the blocks in between is preserved.
- Where it is openedLoad Balancer → Load Balancer vService List → vService edit form → Conditional Backend Services
- Requirement At least two Conditional Backend Services blocks
- vService type HTTP · L7 TCP (Conditional Backend Services in L7 TCP)
Step-by-Step Configuration
On the Load Balancer → Load Balancer vService List screen, the vService is selected and the edit form is opened.
The block to be moved is held by the four-way arrow icon on its left edge and dropped onto the target block; the drop location is highlighted with a dashed frame. When the title of the block (the condition summary) is clicked, the block expands and collapses; it is not used for dragging. The arrow icon is held only for dragging; a single click on the icon removes the block from the form. A block removed by mistake is restored by closing the form without saving it.
By looking at the condition summaries in the block titles, it is verified that the specific conditions come before the general conditions.
The Save button is clicked; the new order is applied as soon as it is saved. In a cluster, the change is transferred to the peer device automatically with auto-sync (default); if Manual Sync Mode is on, it is sent with Synchronize.
Verification
A request that matches the specific condition is sent; on the Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → HTTP logs screen, the Backend Service column of the request is checked. For HTTP logs, a log profile must be assigned to the vService. On an L7 TCP vService, the Backend Service the connection went to is seen on the vService Sessions screen.
The request goes to the Backend Service of the specific blockCommon Mistakes
- Putting the general condition on top. Specific conditions must come before general conditions; otherwise, the specific block never matches.
- Not saving after dragging. The new order is applied when the vService is saved with Save; if the form is closed without saving, the old order is kept.
- Relying on the order of a block with an empty condition. A block with no condition selected receives no requests; its order does not change the result.
- Thinking that the order also affects the actions. The block order determines only the Backend Service selection; the order of the actions is determined separately in the Actions field of the vService (In what order do Actions run; how do I change the order?).
How it is done in the documentation
