For one of my websites on Netlify, I have a reverse proxy on top on Netlify and although I know this should be avoided, this configuration is necessary for the moment.
Because of that config, my visitors do not resolve Netlify urls directly. They first pass by my reverse proxy who is going to resolve the Netlify urls and then pass the result.
This results in Netlify only seeing the IP address of our reverse proxy server and therefore, does not allow it to do country-based redirects or statistics on the countries of our visitors (Netlify GeoIP is always returning our reverse proxy country).
For a long time we managed to solve these problems by passing an x-forwarded-for header from the reverse proxy to Netlify containing the client IP address but this stopped working overnight. I’ve read here that X-Nf-Client-Connection-Ip is becoming one of the only supported Netlify headers but I’m not sure that it concerns me because it seems to be rather the headers from Netlify to the outside.
Could you clarify if there is still a way to pass the client IP address when using a reverse proxy on top of Netlify?
We tried with X-Real-IP and X-Client-IP and it does not seems to work.
Would it be possible to ask the engineering team if there is an official header supported and what is it?
This has been the expected behaviour for quite some time now:
While that guide talks about Cloudflare, it’s probably true for any proxying. So, if you were able to get it working through some way, I’d assume that could have been a bug and might have got fixed.
I can try confirming with the devs if that is something that has happened.
Hey @hrishikesh, indeed, our setup must be similar to having Cloudflare in front of Netlify.
But our reverse proxy is not caching or interfering Netlify responses, our only issue is with GeoIP and before that it worked for years thanks to the x-forwarded-for header.
And as stated here, it seems you’ve built some ways to pass the client IP.
Yes thanks, I would love to get clarifications from your engineering team
As confirmed with the devs, nothing has changed about this recently. Moreoever, the devs did mention that:
We don’t parse the x-forwarded-for and choose the client when we geolocate the request.
So even if you were forwarding the header, we never never really respecting it. The devs say that the code around this has not changed for a long time now, so again, I’m really surprised by the fact that you claim it worked fine for… years?
I don’t think that you’d have, I’ll ask anyways. Do you happen to have any logs or response headers from us that indicate that this worked in the past?
Sorry about that. The devs took a closer look, and it appears that we did support this in the past and is now broken. We will let you know as things develop.
,
