The HTTP requests and HTTP responses use header fields to send information about the HTTP message. Header fields are colon-separated name-value pairs that are separated by a carriage return (CR) and a line feed (LF). A standard set of HTTP header fields is defined in RFC 2616, Message Headers. There are also non-standard HTTP headers available that are widely used by the applications.
XFF is industry-standard (but not HTTP standard) mechanism for storing the customer IP address into an HTTP Request Header called the X-Forwarded-For header. Typically, you configure your Apache servers to log the value from the X-Forwarded-For header instead of logging the client IP.
The X-Forwarded-For Header
Most mainstream proxy servers support what is known as the X-Forwarded-For header, which is a custom header that gets inserted into the HTTP request by the proxy so that the Client IP Address can be read by the target web/app server.
Elastic Load Balancing stores the IP address of the client in the X-Forwarded-For request header and passes the header along to your server.
The X-Forwarded-For request header takes the following form:
The following example is an X-Forwarded-For request header for a client with an IP address of 203.0.113.7.
The clientIPAddress in the X-Forwarded-For request header is followed by IP addresses of each successive proxy that passes along the request. The last IP address is the IP address that connects to your back-end application instance. For example, if your HTTP request already has a header when it reaches the load balancer, the IP address from which the request came is appended at the end of the header followed by the IP address of the load balancer. In such cases, the X-Forwarded-For request header takes the following form:
X-Forwarded-For: clientIPAddress, previousRequestIPAddress, LoadBalancerIPAddress
If you have back-end application instances in multiple Availability Zones, the X-Forwarded-For request header can contain one or more load balancer IP addresses. Because Elastic Load Balancing uses a different load balancer for each Availability Zone, a client request can be passed from one load balancer to another before reaching a back-end application instance. For example, if you have back-end instances in Availability Zones us-east-1a and us-east-1b, a client request might be handled initially by the load balancer in us-east-1a. If the instances in us-east-1a are unhealthy, are deregistered, or if sticky sessions are used and the back-end instance is in us-east-1b, the load balancer in us-east-1a routes the request to the load balancer in us-east-1b. Each of the load balancer then adds its IP address to the X-Forwarded-For request header.
If more than one load balancer is involved in a client request, the X-Forwarded-For request header takes the following form:
X-Forwarded-For: clientIPAddress, previousLoadBalancerIPAddress-1, previousLoadBalancerIPAddress-2
The following example is an X-Forwarded-For request header that arrived at a back-end application instance in the us-east-1b Availability Zone. The client (203.0.113.7) made a request that arrived first at a load balancer in us-east-1a (10.12.33.44). Subsequently, the load balancer for us-east-1a routed the request to the load balancer in us-east-1b (10.73.23.88).
X-Forwarded-For: 203.0.113.7, 10.12.33.44, 10.73.23.88
The X-Forwarded-Proto request header helps you identify the protocol (HTTP or HTTPS) that a client used to connect to your server. Your server access logs contain only the protocol used between the server and the load balancer; they contain no information about the protocol used between the client and the load balancer. To determine the protocol used between the client and the load balancer, use the X-Forwarded-Proto request header. Elastic Load Balancing stores the protocol used between the client and the load balancer in the X-Forwarded-Proto request header and passes the header along to your server.
Your application or website can use the protocol stored in the X-Forwarded-Proto request header to render a response that redirects to the appropriate URL.
The X-Forwarded-Proto request header takes the following form:
The following example contains an X-Forwarded-Proto request header for a request that originated from the client as an HTTPS request:
The X-Forwarded-Port request header helps you identify the port a HTTP/HTTPS load balancer uses to connect to the client.
Elastic Load Balancing supports the load balancing of applications using HTTP, HTTPS (Secure HTTP), TCP, and SSL (Secure TCP) listener protocols. For a quick overview of the different configurations available for your load balancer
Apache can use the Rpaf module to read the X-Forwarded-For header from Nginx Proxy
RPAFproxy_ips 22.214.171.124 # The Nginx connecting IP address
RPAFheader X-Forwarded-For # Apache is looking for this header to use as the “client IP”
Reference for using XFF in a 3 Tier Arch: http://www.andrewboring.com/technotes/client-ip-x-forwarded-across-multiple-proxies
Logging the client IP behind Amazon ELB with Apache
Configure Apache to Not Log Requests / adding x-forwarded to combined
Apache: get the originating host ip
Environment variables can be set on a per-request basis using the mod_setenvif and/or mod_rewrite modules. For example, if you want to record requests for all GIF images on your server in a separate logfile but not in your main log, you can use:
SetEnvIf Request_URI \.gif$ gif-image
CustomLog gif-requests.log common env=gif-image
CustomLog nongif-requests.log common env=!gif-image
Or, to reproduce the behavior of the old RefererIgnore directive, you might use the following:
SetEnvIf Referer example\.com localreferer
CustomLog referer.log referer env=!localreferer
Module Rewrite – URL Rewriting Guide