Why is traffic not distributed evenly across the servers?

Short answer

Uneven distribution usually has an explanation: the algorithm (algorithms such as Weighted Round Robin and Least Connection do not distribute evenly by design, while the default Round Robin ignores Weight), persistence (Persistence or self-persistent algorithms pin clients), long-lived connections, Backend Service status (servers that failed the health check, are in Maintenance Mode, are a Backup Service or whose Connection Limit is full) and measurement (Conditional Backend Services, each device in a cluster showing only its own traffic). The cause is found with the Live Stats and Dashboard screens of the vService.

Possible Causes

Cause	Description	Where to look
Weight + an Algorithm That Uses Weight	Different Weight values produce a proportional distribution	The W= suffix in the name cell in Live Stats
Round Robin and Weight	The default Round Robin ignores Weight; the expected ratio does not form	vService → Details → LB Algorithm
Dynamic Algorithms	Least Connection, Least Response Time, Least Bandwidth, Random, Fastest and Fastest+ distribute the load according to the current state of the servers	vService → Details → LB Algorithm
Persistence	New cookie, Current cookie, Hash and Session Affinity Manager (SAM) pin clients to a server; a newly added server first receives only new clients	vService → Details → LB Algorithm → Persistence
Self-Persistent Algorithms	Source, URI, URL Param, HDR and RDP Cookie make the distribution depend on the variety of the values; users behind NAT appear as a single IP	vService → Details → LB Algorithm
Long-Lived Connections	On L7 TCP and Network vServices, the decision is per connection; long connections (database pool, WebSocket) accumulate on servers	Live Stats → Current Sessions
Health Status	A server that failed the health check (Unhealthy) does not receive traffic; a server with no health check defined (No check) always stays in traffic	The status strip in the name cell in Live Stats
Maintenance Mode	A server in maintenance does not receive new traffic	The yellow status strip in Live Stats
Backup Service	The backup server does not receive traffic as long as the main servers are running	Backend Service form → Backup service; the backup service icon next to the name in the list
Connection Limit	A server whose limit is full is skipped, and the others receive extra load	Backend Service → Details → Connection Limit
First Algorithm	By design, it fills the first server first	vService → Details → LB Algorithm
Conditional Backend Services	Traffic is first split according to the conditions, and each branch is balanced within itself	vService → Conditional Backend Services
Cluster	Each device shows only the traffic passing through itself; values are not summed across devices	The own column of each device in Live Stats
Network vService	L4 persistence sends the same source IP to the same server; Source Hash and Destination Hash pin by addresses; while Protocol ANY - L3 is selected or Port Range is on, distribution is done only with Round-Robin or Weighted Round-Robin	Network vService → Details → LB Algorithm

Diagnosis Steps

1. Live Stats → Backend Services: The Current Sessions values of the Backend Services, request/connection rates, W= suffixes and the status strip (green = Healthy, dark green = No check, red = Unhealthy, yellow = Maintenance / Draining / Not balancing) are compared (Live Stats · Backend Services).
2. Dashboard → Backend tab: The request and connection distribution charts over time are examined (Backend Request Distribution).
3. Load Balancer Management: The algorithm and persistence sentences are read (LB Algorithm).
4. Live Stats → Source IP Statistics: It is checked whether the traffic comes from a few source IPs (NAT, proxy) (Source IP Statistics).

Common Misconceptions

• "Load balancing always distributes evenly." Most algorithms deliberately do not distribute evenly; an equal share is the goal only of Round Robin and of Weighted Round Robin with equal Weights.
• "When a new server is added, the load is shared immediately." Because of Persistence and open connections, the new server first receives only new clients.
• "The values of a single device show all the traffic." In a cluster, each device shows only its own traffic; Live Stats lists each device in a separate column.
• "Counters that reset after a configuration save mean a failure." When the configuration is reloaded, the counters can be reset (scope and limits).

How it is done in the documentation

• Live Stats · Backend Services
• Dashboard · Backend Request Distribution
• Load Balancer Management · LB Algorithm
• HTTP (L7) vService · Best Practices

Related questions

• All users coming from behind a corporate NAT go to a single server; why?
• Persistence is causing uneven load distribution; what can I do?
• What is the difference between Round Robin and Weighted Round Robin?