NOTE: This article covers obtaining the original client IP for logging purposes. If you need to obtain it for use in your code, check out this article.

Because the Cloud Load Balancer acts as a proxy between the client and your server(s), you will no longer see the client’s IP address but one of our cloud node IP addresses instead. This is by design because it allows return traffic to come back through our network to properly cloak your server but also to monitor session and connection state. If you require the client IP for logging, filtering, authentication or other purposes, there are two ways to remedy this.

OPTION 1: We can enable a Cloud IPSEC VPN tunnel between the cloud network and your server(s) or entire datacenter, essentially connecting your infrastructure to our global network. You will then configure your web server with a private IP address supplied by us, and all inbound and outbound traffic will go through the Cloud network. In this scenario your infrastructure is completely cloaked by our cloud and you will see the client origin IP address as usual, however setup is more involved and will require a VPN capable terminator at your datacenter or IPSEC client on your server(s) for implementation. This is recommended for larger deployments only.

OPTION 2: We can pass through the original client IP address by inserting it into the HTTP header request passed from the client to your server(s). The web server may be modified to read the X-Forwarded-For header and write the Client IP address in the appropriate environment variable or Web server data structure. For example, it is possible to insert an ISAPI filter into IIS to read the Client IP from the HTTP header and write this client IP into the appropriate field in a data structure. Downstream server software (for example, the logging module) would then access the Client IP from this Request Object. As another example, an Apache module may be linked into an Apache Web server to write the Client IP into an environment variable, which is accessed by a downstream process.

There are three limitations to keep in mind.

a) This only works with HTTP traffic (and SSL, see c). It cannot work with TCP, FTP, UDP or anything else. Sorry : (

b) We require that the downstream web server read the X-Forwarded-For on a per GET basis rather than on a per connection basis. Usually the client IP address remains constant once a connection is established and as a result the downstream server might read and remember the client IP for the duration of the connection. But to be on the safe side, the server should look at the X-Forwarded-For on each GET to be certain it has not changed.

c) The only way to insert the X-Forwarded-For into the header of an SSL session is for us to decrypt it and re-encrypt it. If you use SSL BRIDGE mode to pass SSL traffic through the Cloud Load Balancer to your server(s), you will need to change this to regular SSL mode which requires that you upload an SSL certificate and assign it to your ALF Pack configuration.

Configuring the Pass-Through Client IP Header
To configure the IP address pass-through header, log into the management portal and edit your server(s). In the settings dialog, you will see the “Use client IP header” option. Enable it and then specify a header name. “X-Forwarded-For” is our recommendation, but sometimes it can be something else, depending on your web server. In our examples, we will use “X-Forwarded-For”.

x-forwarded-for configuration

Retrieving the Client IP Header for logging purposes

To retrieve the client IP header, follow one of the knowledge base articles below that references your particular web server.

Apache 2.0 and 2.2: Please follow the steps in this knowledge base article.

IIS 6 or lower: Please follow the steps in this knowledge base article.

IIS 7.0 or 7.5 on Windows 2008: Please follow the steps in this knowledge base article.

NGINX: See the HttpRealipModule on the NGINX WIKI


Keywords: obtain, obtaining, retrieving, extracting, source ip, client ip