I seem to recall hearing that the x-forwarded-for header would no longer have the originating IP but rather the nginx IP or something else? I believe it had to do with the switch to using ALB. Is there another header value we can use instead?
Hey Rob!
You’ll still want to use the X-Forwarded-For header to determine the IP address of the client who made a request to your app, regardless of whether you’re using an ELB- or ALB-based endpoint.
As described in this support article, the main difference with ALBs is that we’ll include 2 IP addresses in the X-Forwarded-For header:
Both the ALB and the local reverse proxy will add an IP address to the X-Forwarded-For header. As a result, the X-Forwarded-For proxy will typically contain two IP addresses when using an ALB (whereas it would only contain one when using an ELB):
- The IP address of the client that connected to the ALB
- The IP address of the ALB itself
If you are using another proxy in front of your app (e.g. a CDN), there might more IP addresses in the list. If your app contains logic that depends on this header (e.g., IP address filtering, or matching header entries to proxies) you will want to account for the additional proxy.
1 Like
Thanks, Frank. Can you tell me the order I should expect the IP addresses to be in? Specifically, which one will be the client’s IP address?
Hi Rob,
The client IP address should be first in the list, followed by each proxy the request encounters, in order. For example, here’s an actual Aptible X-Forwarded-For header value:
X-Forwarded-For: 75.112.238.206, 10.138.2.161
This follows the RFC, which states:
The first element in this list holds information added by the first proxy that implements and uses this header field, and each subsequent element holds information added by each subsequent proxy.
So, if you’re using a web framework to parse this header, it should (ideally) already know how to parse and interpret the header.
— Frank