I have a setup that looks like this:
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.
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.
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
.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
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.
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 showingclient_ip
,proxy_ip
and if there was only 1 proxy server between the internet and the BigCommerce application backend it would just showclient_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
andx-forwarded-for
headers just shows 1 IP address, theclient_ip
, while theremote_addr
is set to the proxy IP and theserver_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 theproxy_ip
instead ofclient_ip
?@cvanorman @beebee11 I think you should look at the
ngx_http_realip_module
.add to reverse proxy server on the application side
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.