Round Robin
Equal distribution, zero configuration
The simplest load balancing strategy. Each incoming request is sent to the next origin server in the list, cycling through all servers in order. Every server gets an equal share of traffic regardless of its capacity or current load.
How it works
The Worker maintains an internal counter. Request 1 goes to Origin A, Request 2 to Origin B, Request 3 to Origin C, Request 4 back to Origin A, and so on. The counter is edge-local, meaning each Cloudflare data center tracks its own rotation independently.
Use when
- ✓ Your origins have identical capacity and specs
- ✓ You are serving stateless APIs or static content
- ✓ You want the simplest possible setup
- ✓ All origins are in the same region
Do not use when
- ✗ Origins have different CPU/memory capacity
- ✗ Some origins are slower than others
- ✗ You need session persistence
Weighted Round Robin
Proportional traffic based on server capacity
Like round robin, but each server is assigned a weight that determines what percentage of traffic it receives. A server with weight 70 gets roughly 70% of all requests, while a server with weight 30 gets 30%. This lets you match traffic distribution to your actual server capacity.
How it works
You assign a numeric weight to each origin (e.g., 60, 30, 10). The Worker uses weighted random selection to pick an origin for each request. Over time, the distribution converges to match the weights. The selection is per-request, not a fixed rotation.
Use when
- ✓ Your origins have different capacities (e.g., 8GB vs 2GB RAM)
- ✓ You are doing gradual rollouts (new server gets 10% traffic)
- ✓ You are A/B testing between two backends
- ✓ You have a mix of dedicated and shared hosting
Do not use when
- ✗ All origins are identical (use round robin)
- ✗ You need guaranteed exact percentages (weighted is probabilistic)
IP Hash
Consistent routing without cookies
The visitor's IP address is hashed to determine which origin server they hit. The same IP always maps to the same server, providing consistency without requiring cookies. This works with any HTTP client, including browsers, mobile apps, and API consumers.
How it works
The Worker takes the client's IP address (from CF-Connecting-IP), hashes it, and maps the result to an origin index. The mapping is deterministic — the same IP always gets the same server. If an origin goes down, affected users are redistributed to the next available server.
Use when
- ✓ You need consistent routing without cookies
- ✓ You are running a CDN with cache warming at origins
- ✓ Your API consumers expect to hit the same backend
- ✓ You cannot use cookies (some API clients strip them)
Do not use when
- ✗ Many users share the same IP (corporate NAT, VPNs)
- ✗ You need even distribution regardless of IP patterns
Sticky Sessions
Session persistence via cookies
The first request from a visitor picks an origin server, and a cookie is set to keep that visitor pinned to the same server for the duration of their session. This ensures that session state, shopping carts, WebSocket connections, and in-progress work are never lost mid-session.
How it works
On the first request, the Worker selects an origin (round robin) and sets a cookie (eb_lb) with the origin index. On subsequent requests, the Worker reads the cookie and routes to the same origin. If the pinned origin is down, the Worker picks a new one and updates the cookie.
Use when
- ✓ You have session-based applications (login sessions, shopping carts)
- ✓ You use WebSocket connections that need to stay on one server
- ✓ You have in-memory state that cannot be shared across origins
- ✓ You are running traditional server-rendered apps (PHP, Rails, Django)
Do not use when
- ✗ Your application is fully stateless
- ✗ You want even distribution regardless of sessions
- ✗ Cookie-based routing conflicts with your CDN caching
Weighted Sticky Sessions
Capacity-aware distribution with session persistence
Combines weighted distribution with cookie-based session persistence. New visitors are distributed across origins based on their weights, and then a cookie keeps each visitor pinned. This gives you capacity-aware load balancing for stateful applications.
How it works
On the first request, the Worker uses weighted random selection (like Weighted Round Robin) to pick an origin, then sets a cookie. All subsequent requests from that visitor go to the same origin via the cookie. New visitors are distributed proportionally to weights.
Use when
- ✓ You have stateful applications with servers of different capacity
- ✓ You are migrating to a larger server and need gradual traffic shift
- ✓ You run shopping carts or sessions on mixed hardware
Do not use when
- ✗ Your application is stateless (use weighted round robin)
- ✗ All servers have equal capacity (use sticky sessions)
Failover
Primary-backup with automatic recovery
All traffic goes to your primary origin server. The moment it stops responding (connection failure, 5xx error, or timeout), the Worker automatically routes to the next server in the list. When the primary recovers, traffic shifts back. This gives you disaster recovery with zero manual intervention.
How it works
The Worker tries the first origin. If it fails (5xx status, connection refused, or timeout), it retries the next origin in the list. Health checks run periodically in the background, and the Worker tracks which origins are healthy. Failed origins are marked as unhealthy and skipped for subsequent requests until they recover.
Technical details
Overhead
~2ms (on failover)
Use when
- ✓ You have a primary server with a hot standby
- ✓ You need disaster recovery without DNS-level failover
- ✓ You want automatic failback when the primary recovers
- ✓ You have a staging server that should only receive traffic when production is down
Do not use when
- ✗ You want traffic distributed across all origins
- ✗ All origins should actively serve traffic
Geographic Routing
Location-aware traffic distribution
Routes visitors to the origin server closest to their physical location. The Worker uses Cloudflare's edge data (data center colo, country, continent) to make routing decisions. This minimizes latency and helps with data sovereignty requirements like GDPR.
How it works
When a request arrives at a Cloudflare edge, the Worker checks the data center location. It first tries to match by city, then by country, then by continent. If no match is found, it falls back to round-robin across all origins. You configure which origins serve which regions.
Use when
- ✓ You have origins in multiple regions (US, EU, Asia)
- ✓ You need to comply with GDPR or data residency laws
- ✓ You want to minimize latency for global users
- ✓ You serve region-specific content (localized APIs, CDNs)
Do not use when
- ✗ All origins are in the same region
- ✗ You do not care about latency optimization
- ✗ Your application does not have region-specific data