Usage of $proxy_add_x_forwarded_for on edge proxies

nanaya me at nanaya.pro
Tue Jan 12 21:50:47 UTC 2021


On Wed, Jan 13, 2021, at 02:46, Maxim Dounin wrote:
> The X-Forwarded-For is expected to contain multiple addresses, with 
> the last one being from the last proxy.  It is up to the reader of 
> the header to trust or not particular values from the header.
> 
> For example, in the realip module nginx provides set_real_ip_from 
> and real_ip_recursive directives to configure which addresses to 
> trust (see http://nginx.org/r/set_real_ip_from and 
> http://nginx.org/r/real_ip_recursive).  Similarly, in the geo 
> module there are "proxy" and "proxy_recursive" parameters, and in 
> the geoip module there are "geoip_proxy" and 
> "geoip_proxy_recursive" directives.
> 
> In some cases it might be a good idea to trust X-Forwarded-For 
> values provided by clients: for example, the are some well-known 
> public proxies, such as Opera Mini proxies.  And it might be a 
> good idea to trust almost everything if you are trying to extract 
> some non-essential details, such as best-guess geoinformation.
> 
> And it is always a good idea to preserve X-Forwarded-For provided 
> by client, if any.  In particular, it can be used in abuse reports 
> and various investigations.
> 
> If you want to use something without extra complexity, consider 
> using X-Real-IP header instead, which is expected to contain only 
> one client address as set by your edge/frontend servers.
> 

Is it not better to just handle all of those at the outermost proxy (with set_real_ip_from etc) and only pass the "sanitized" $remote_addr value to the upstream? At least for simple config, similar to the default REMOTE_ADDR in fastcgi_params etc.

It seems like a lot of potential point of failures trying to pass the value around. And people sharing this possibly dangerous config around without warning of its implication isn't helping, I think.

I guess X-Real-IP could work although I don't remember seeing it used by anything but nginx. And then I think there have been a bunch of problems caused by applications blindly trusting X-Forwarded-For which usually ends up with stripping everything but the last non-private ip by default - essentially a more complex version of outermost proxy passing $remote_addr for that header.


More information about the nginx mailing list