How do I forward client IP instead of proxy IP in Nginx Reverse Proxy?

Posted March 1, 2020 85.7k views
NginxNetworkingUbuntu 18.04


I have a setup that looks like this:

  • Nginx Reverse Proxy with a Floating IP
  • Reverse Proxy is configured to forward requests from users to a 3rd party SaaS application, BigCommerce which then handles the response to the user.

I’m unable to set Trusted IPs/Proxies in the BigCommerce application environment, therefore the client IP is always showing as the last connecting proxy instead of the client IP. Due to how ordering in BigCommerce is tracked, all orders are being marked as ‘potential fraud’ because of an IP location mismatch between the IP being logged and the customer making the order.

My Setup

I’ve been asked what headers I’m sending via the Reverse proxy and it looks like this:

proxy_pass_header  Set-Cookie;

proxy_set_header   Host               $host;
proxy_set_header   X-Real-IP          $remote_addr;
proxy_set_header   X-Forwarded-Proto  $scheme;
proxy_set_header   X-Forwarded-For    $proxy_add_x_forwarded_for;

From what I can see and have been shown from the BigCommerce, the X-Forwarded-For headers are being sent with the correct IPs in the correct order (client_ip, proxy_ip), but X-Real-IP shows as the proxy_ip instead of the client_ip.

Their suggestions have been to override the X-Real-IP header from the Reverse Proxy and I can’t seem to be able to do so. From questions I’ve asked in other online communities, I’ve received suggestions on overriding the $remote_addr with proxy_bind, but that requires running Nginx as a superuser and messing with IP tables.

My Question

Is it possible that the droplet configuration (Possible NAT issue?) is what’s causing the IP to show as the proxy_ip instead of the client_ip or is what I have configured missing something crucial in my setup to ensure the reverse proxy doesn’t overwrite the X-Real-IP with its own public IP address.

Any help or suggestions are greatly appreciated. I’ve also looked into proxy_protocol, but I don’t know if that fits my situation and if that requires BigCommerce to support proxy_protocol in order to correctly identify the client_ip.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
3 answers

Hi @cvanorman

I think that what you have in place is correct in terms of the 4 headers that you’ve configured already.

What is the output of the Nginx access logs? Are you seeing the correct IP there?

  • Hey @ServerEnthusiast, thank you so much for the sanity check here!

    The Nginx access logs show the correct client IP being logged. I believe I’ve narrowed down the issue to there being an additional load-balancer or proxy server in between my reverse proxy setup and the BigCommerce application backend. The x-forwarded-for headers are showing client_ip,proxy_ip and if there was only 1 proxy server between the internet and the BigCommerce application backend it would just show client_ip, right?

    When I setup a test against a PHP backend (1 nginx reverse proxy droplet and 1 nginx droplet running PHP), the x-real-ip and x-forwarded-for headers just shows 1 IP address, the client_ip, while the remote_addr is set to the proxy IP and the server_addr is set to the PHP backend’s IP.

    Would you be able to confirm that my assumption is correct in stating there may be an additional proxy in between my reverse proxy and the BigCommerce backend that’s causing the x-real-ip to report the proxy_ip instead of client_ip?

Hey @cvanorman were you able to find a solution for this? I am too stuck with the same issue.

  • @beebee11, I unfortunately had to abandon this setup due to the way BigCommerce would receive the headers (they’re ignored at the LoadBalancer). After some time spent with their support, it was determined that there was an infrastructure change that prevented the X-Forwarded-For headers to be parsed by their infrastructure, so all orders and logins were being reported from the proxy and not the client’s IP.

    These headers in use with other backends that you have control over should work fine, but it looks like more third party platforms with a reverse proxy will be unsupported in the future.

@cvanorman @beebee11
I think you should look at the ngx_http_realip_module.

add to reverse proxy server on the application side

http {

set_real_ip_from $IP_LOAD_BALANCER;
real_ip_header X-Forwarded-For;