Got it, so it is more about what Rails or other gems do with the headers, and less about what Discourse code does.
Interesting that Rails does not make use of X-Real-IP, which is probably less commonly used than X-Forwarded-For, but certainly better known than Forwarded and Client-IP 
.
Probably X-Real-IP is then obsolete in the Nginx config. Discourse expands uses it along with X-Forwarded-For in logs, if I interpret it correctly? I couldn’t find any other explicit use/mention in the code:
- discourse/lib/discourse_logstash_logger.rb at main · discourse/discourse · GitHub
- logster/lib/logster/message.rb at main · discourse/logster · GitHub
The below just looked wrong in two ways when I saw it while debugging shared rate limiting and logged errors about the invalid “unix:” client IP after our Discourse upgrade (we use a UNIX socket proxy in front of the container and do rely on X-Forwarded-For).
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
But I get the “it works” to reliably make $remote_addr the only point of truth, and real_ip_header the canonical way for admins to control the single IP Discourse/Rails gets. I see it was added to Serve Discourse from a subfolder (path prefix) instead of a subdomain already 
.