Linode Library Home
Linode Library RSS Feed
Home :: NodeBalancer
Print View View Source

NodeBalancer Reference Guide

Published: by

This is the NodeBalancer reference guide. Please see the NodeBalancer How-To for practical examples.


Adding a NodeBalancer

Click the NodeBalancers tab, and then "Add a NodeBalancer". You must choose the same location as your back-end Linodes for a given deployment.

NodeBalancer Settings

Here you may adjust the NodeBalancer's display label, along with the 'Client Connection Throttle'. The connection throttle limits the number subsequent new connections from the same client IP address.


Each NodeBalancer config adds another port that the NodeBalancer will listen on. For instance, if you wish to balance both port 80 and 81, you'll need to add two configuration profiles to your NodeBalancer.


The public port for this configuration. Ports 1 through 65534 are available for balancing, provided that the port is not already in use by another config.


You can choose either TCP, HTTP, or HTTPS. HTTP and HTTPS enable some additional options described below.

TCP: Use TCP mode to balance non-HTTP services.

HTTP: HTTP KeepAlives are forced off in HTTP mode.

HTTPS: With HTTPS selected, your NodeBalancer will terminate SSL connections. As with HTTP mode, KeepAlives will be disabled and the client's IP address will be provided in the X-Forwarded-For header.

If HTTP or HTTPS is selected, the NodeBalancer will add an X-Forwarded-Proto header, with a value of either http or https, to all requests sent to the backend. The header value is based on the type of request (HTTP or HTTPS) originally received by the NodeBalancer.


Note that HTTPS requests (and HTTP requests, for that matter) are terminated on the NodeBalancer itself, and that's where the encryption over a public network ends. NodeBalancers use the HTTP protocol to communicate with your backends over a private network. You should have your backends listen to the NodeBalancer over HTTP, not HTTPS.


How initial new connections are allocated across the backend Nodes.

  • Round Robin - Allocates connections in a weighted circular order across the backend Linodes.
  • Least Connections - Tracks each backend Linode's connection count, and allocates new connections to the node with the least connections.
  • Source IP - Modulates the client's IP to allocate them to the same backend on subsequent requests. This works so long as the set of backend Linodes doesn't change, however Session Stickiness affects this behavior.

Session Stickiness

NodeBalancers have the ability for Session Persistence - meaning subsequent requests from the same client will be routed to the same backend Node when possible.

  • None - No additional Session Stickiness will be performed.
  • Table - The NodeBalancer itself remembers which backend a given client IP was initially load balanced to (see Algorithm, above), and will route subsequent requests from this IP back to the same backend, regardless of changes to the number of healthy backend nodes. If a backend node goes offline, entries in the table for that node are removed.
  • HTTP Cookie - Requires the configuration protocol be set to HTTP. The NodeBalancer sets a cookie named NB_SRVID identifying the backend a client was initially load balanced to (see Algorithm, above), and will route subsequent requests from this IP back to the same backend, regardless of changes to the number of healthy backend nodes. If a backend node goes offline, the client is balanced to another backend and the cookie is rewritten.

If you need Session Persistence it is our recommendation to utilize both the Source IP algorithm in combination with either Table or HTTP Cookie if possible.

Certificate and Private Key

If you select the HTTPS protocol, the Certificate and Private Key fields will appear.

The NodeBalancer Certificate and Private Key fields.

Copy your certificate into the Certificate field. If you have chained certificates, you can copy all of them into the text field, one after the other.

Copy your passphraseless private key into the Private Key field.

You can purchase an SSL certificate or create your own.

Health Checks

NodeBalancers perform both passive and active health checks against the backend nodes. Nodes that are no longer responding are taken out of rotation.


When servicing an incoming request, if a backend node fails to connect, times out, or returns a 5xx response code (excluding 501 and 505), it will be considered unhealthy and taken out of rotation.


NodeBalancers also proactively check the health of back-end nodes by performing TCP connections or making HTTP requests. The common settings are:

  • Check Interval - Seconds between active health check probes.
  • Check Timeout - Seconds to wait before considering the probe a failure. 1-30.
  • Check Attempts - Number of failed probes before taking a node out of rotation. 1-30.

Three different Health Check Type exist:

  • TCP Connection - requires a successful TCP handshake with a backend node.
  • HTTP Valid Status - performs an HTTP request on the provided path and requires a 2xx or 3xx response from the backend node.
  • HTTP Body Regex - performs an HTTP request on the provided path and requires the provided PCRE regular expression matches against the request's result body.


NodeBalancers work over the private network. Backend nodes must have a private IP configured via static networking.

Once you have established a basic configuration, you will be asked to set up "Nodes". Nodes are combinations of addresses and ports that you wish to balance.

Node Status

A Node's status, as seen from the perspective of the NodeBalancer, is indicated via its status field. It either has a value of UP or DOWN. The Last Status Change field also indicates the last time this node's status changed.

Node Mode

Changes to a Node's Mode are applied within 60 seconds.

  • Accept - allows the node to accept incoming connections so long as it is healthy.
  • Reject - remove the node from rotation; discontinue health checks on this backend. Existing connections remain active.
  • Drain - will only recieve connections from clients whose session stickiness points to this node.

The use-case for Drain would be to set a node to Drain a day or so in advance of taking the node down. That way existing sessions would likely have ended.

X-Forwarded-For Header

NodeBalancers add an X-Forwarded-For (XFF) HTTP header field, which allows your nodes to identify a client's originating IP address. This is useful for logging purposes. Here's an example XFF HTTP header:


You'll need to configure your web server software to use the XFF header.


If you're using the Apache web server, you can use the mod_rpaf module to replace REMOTE_ADDR with the clent's IP address in the XFF header. After you install the module, you'll need to specify as a proxy in httpd.conf.


If you're using the Nginx web server, you can add the following lines to your Nginx configuration file:

real_ip_header X-Forwarded-For;

This will allow Nginx to capture the client's IP address in the logs.

Creative Commons License

This guide is licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License.

Last edited by Alex Fornuto on Wednesday, March 26th, 2014 (r4349).