That commit fixed a configuration error that you were relying on, but also that might have allowed any end user to spoof their IP address by setting that header.
If you are confident nothing else can talk to your container, there is actually an easier way that doesn’t require the use of a socket - I have just written a guide on how to do this.
For your setup @CLOUD_PHT you should add this to your container definition (if a run section already exists, add these directives to it, else add the run section):
run:
- file:
path: /etc/nginx/conf.d/outlets/server/real-ip-header.conf
chmod: 644
contents: |
real_ip_header x-forwarded-for;
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
You may also need the following:
- file:
# we need to turn on recursive since we'll have at least two entries; one from the host, one from CloudFlare
path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
chmod: 644
contents: |
real_ip_recursive on;
depending on whether the nginx running on your server is itself processing the Cloudflare header to determine the end user’s real IP (this is suggested) or just adding its own on top. See https://meta.discourse.org/t/handling-the-chain-of-trust-of-the-end-users-real-ip/406372#p-2001772-more-than-one-proxy-7 for more details.
Other readers: be aware this this directive
run:
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
is not appropriate for all setups. Only do this if all connections to the Discourse container from this IP are trusted.
Specifically, a known problem with IPv6 setups is that IPv6 connections to the server are forwarded by docker over IPv4 - the way that it’s done make all connections look like they’re coming from the host’s docker0 IP address. If you apply the above directive to your setup, it’ll allow all users connecting over IPv6 to spoof their IP address at leisure.