A Cloudflare load balancer is identified by the DNS hostname whose traffic you want to balance (, for example). The load balancer defines which origin server pools to use, the order in which they should be used, and how to geographically distribute traffic among pools.
Active - Passive Failover
An active-passive failover sends traffic to the servers in your active pool until a failure threshold (configurable) is reached. At the point of failure, your load balancer then redirects traffic to the passive pool.
This setup ensures uninterrupted service and helps with planned outtages, but it might lead to slower traffic overall.
To set up a load balancer with active-passive failover:
- Create a load balancer with two origin pools (
- In the list of origin pools, set the following order:
- For Traffic Steering, select .
With this setup, your load balancer will direct all traffic to
primary has fewer available origins than specified in its Health Threshold. Only then will your load balancer direct traffic to
In the event that all pools are marked down, Cloudflare uses the fallback pool, which is the option of last resort for successfully sending traffic to an origin. Since the fallback pool is a last resort, its health is not taken into account, and Cloudflare reports its status as No Health. You can select the fallback pool via the API or in the Cloudflare dashboard. For more on working with fallback pools, see .
Active - Active Failover
An active-active failover (or round-robin approach) distributes traffic to servers in the same pool until the pool reaches its failure threshold (configurable). At the point of failure, your load balancer would then re-direct traffic to the fallback pool.
This setup speeds up overall requests, but is more vulnerable to planned or unplanned outtages.
To set up a load balancer with active-active failover, either:
- Create a load balancer with a single origin pool (
primary) with multiple origins (
origin-2) and set the same for each origin.
- Create a load balancer with two origin pools (
secondary) and — for Traffic Steering — select .
Load balancing and existing DNS records
Adding a Load Balancer does not create a DNS record or SSL certificate. To generate an SSL certificate, create a proxied DNS record for the Load Balancer. The Load Balancer record takes precedence over a DNS record for the same host name.
When you create a load balancer on Cloudflare, you can either:
- Use a unique hostname with no existing DNS record, or
- Use a hostname that has an existing DNS record, either as an A, AAAA, or CNAME record.
If a chosen hostname has an existing DNS record, the load balancer will supersede the DNS record if the DNS record is an A, AAAA, or canonical name (CNAME) record. It will not supersede other record types.
If the load balancer is disabled, preexisting DNS records will be served.
If there is no preexisting DNS record with the same name, disabling the load balancer will prevent clients from resolving the host, and requests will fail.
If a Load Balancer is manually disabled, traffic is not served to the associated origins or the fallback. If all pools in a Load Balancer are manually disabled or unhealthy, traffic goes to the fallback pool. No health checks run on the fallback pool and it will return the same HTTP status as your origin.
If the pool serving as your fallback pool is also disabled:
- If Cloudflare proxies your hostname, you will see a 530 HTTP/1016 Origin DNS failure.
- If Cloudflare does not proxy your hostname, you will see the SOA record.
HTTP keep-alive (persistent HTTP connection)
Cloudflare maintains keep-alive connections to improve performance and reduce cost of recurring TCP connects in the request transaction as Cloudflare proxies customer traffic from its edge network to the site's origin.
Ensure HTTP Keep-Alive connections are enabled on your origin. Cloudflare reuses open TCP connections for up to 15 minutes (900 seconds) after the last HTTP request. Origin web servers close TCP connections if too many are open. HTTP Keep-Alive helps avoid premature reset of connections for requests proxied by Cloudflare.
When using HTTP cookies to track and bind user sessions to a specific server, configure to parse HTTP requests by cookie header. Doing so directs each request to the correct application server even when HTTP requests share the same TCP connection due to keep-alive.
For example, F5 BIG-IP load balancers set a session cookie at the beginning of a TCP connection (if none exists) and then ignore all cookies from subsequent HTTP requests on the same TCP connection. This tends to break session affinity because Cloudflare sends multiple HTTP sessions on the same TCP connection. Configuring the load balancer to parse HTTP requests by cookie headers avoids this issue.
Railgun (wide area network optimization)
Railgun is a web proxy system built for Cloudflare, that allows dynamic content for a website to be cached while also allowing changes to the site to take effect almost instantly. Railgun is currently available to customers with a Business or Enterprise plan, or via one of Cloudflare’s Optimised Partners.
Railgun compresses web objects, even rapidly changing pages like news sites or personalized content. Using Railgun in conjunction with Cloudflare Load Balancing speeds up connections between Cloudflare datacenters and DNS origin servers so that uncacheable requests have minimal latency.
Set up a Railgun listener in front of the load balancer so that the load balancer can handle HTTP connections normally. Load balancing long-lived TLS connections between the sender and listener is very difficult.
Use the same load balancer settings as if Railgun were not in place — for example, HTTP keep-alive connections should be enabled and set to a 90-second timeout, since Railgun is working as an HTTP reverse proxy.
If Railgun is placed behind the load balancer, observe the following guidelines to avoid interruptions with site traffic:
- Use the
railgun-nat.confconfiguration file to set the internal addresses of the hosts Railgun will be optimizing (
localhost:8080, for example). This is important to avoid looping the request outbound to the internet and back to the load balancer only to be forwarded to the origin.
- Ensure no firewall rules are in place that will interfere with traffic between the listener and the origin server.
- Ensure port 2408 is open and passed through the load balancer so that it does not interfere with the TLS connection between the listener and sender.
Cloudflare Load Balancer objects have the following properties:
|Name / type||Description / example||Constraints|
|created_on||The creation timestamp for the load balancer.||Read-only|
|default_pools||A list of Pool IDs ordered by failover priority. Cloudflare steers traffic to the first pool in the list, failing over to the next healthy pool and so on down the list.|
Pools defined here are used by default, or when
|description||A user-supplied description of the load balancer|
|enabled||Enables the load balancer when set to||Default value: |
Valid values: (
|fallback_pool||The Pool ID for the “pool of last resort,” the pool the load balancer should direct traffic to if all other pools are unhealthy. In most configurations, this is the secondary/passive pool.||Max. length: |
|id||The load balancer ID||Max. length: |
|modified_on||Timestamp of the last modification to the load balancer configuration||Read-only|
|name||The public DNS hostname of your Cloudflare load balancer.|
If you have an existing DNS record with the same name as your load balancer, the load balancer will have precedence. The pre-existing DNS record is not used unless you delete the Cloudflare load balancer.
|pop_pools||A mapping of Cloudflare PoP identifiers to a list of pool IDs (ordered by their failover priority) for the PoP (datacenter). Any PoPs not explicitly defined will fall back to using |
|proxied||When set to true, HTTP Proxy mode is enabled; when false, DNS-only mode.||Default value: |
Valid values: (
|region_pools||A mapping of region/country codes to a list of Pool IDs (ordered by their failover priority) for the given region. Any regions not explicitly defined will fall back to using |
|session_affinity||Specifies the type of session affinity the load balancer should use. The default value is |
The supported session affinity types are
When set to
Subsequent requests by the same client to the same load balancer will be sent to the origin server encoded by the cookie.
If the cookie has expired or the origin server is unhealthy, a new origin server is identified and a new cookie generated. The
|Default value: |
|session_affinity_ttl||Sets the time to live for this load balancer’s session affinity cookies.|
This parameter is ignored unless a supported session affinity policy is set.
The current default of 23 hours will be used unless
The accepted range of values is between 1800 and 604800. Once the expiry time has been reached, subsequent requests may get sent to a different origin server.
|steering_policy||The traffic steering policy for this load balancer|
The constraint values have the following effect on traffic steering:
|Default value: |
|ttl||The time to live (TTL) of the DNS entry for the IP address returned by this load balancer. This only applies to load balancers where the proxy mode is DNS-only.|
Managing load balancers via the Cloudflare API
The endpoint for managing load balancers is
The Cloudflare API supports the following commands for load balancers. (Examples are given for the user-level endpoint but apply to the account-level endpoint as well.) For detailed instruction, see .
|Create Load Balancer|
|Delete Load Balancer|
|List Load Balancers|
|Load Balancer Details|
|Update Load Balancer|