Verstanden, also geht es mehr darum, was Rails oder andere Gems mit den Headern machen, und weniger darum, was der Discourse-Code tut.
Interessant, dass Rails X-Real-IP nicht nutzt, was wahrscheinlich weniger häufig verwendet wird als X-Forwarded-For, aber sicherlich besser bekannt ist als Forwarded und Client-IP 
.
Wahrscheinlich ist X-Real-IP dann in der Nginx-Konfiguration veraltet. Discourse erweitert die Nutzung zusammen mit X-Forwarded-For in den Logs, wenn ich das richtig interpretiere? Ich konnte keine andere explizite Verwendung/Erwähnung im Code finden:
- discourse/lib/discourse_logstash_logger.rb at main · discourse/discourse · GitHub
- logster/lib/logster/message.rb at main · discourse/logster · GitHub
Das unten sah für mich in zweierlei Hinsicht falsch aus, als ich es beim Debugging der gemeinsamen Rate-Beschränkung sah und Fehlermeldungen wegen der ungültigen „unix:“-Client-IP nach unserem Discourse-Upgrade protokollierte (wir verwenden einen UNIX-Socket-Proxy vor dem Container und verlassen uns auf X-Forwarded-For).
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
Aber ich verstehe den „es funktioniert“-Aspekt, um $remote_addr zuverlässig als einzigen Wahrheitspunkt zu machen, und real_ip_header als den kanonischen Weg für Admins, die einzelne IP zu steuern, die Discourse/Rails erhält. Ich sehe, dass es bereits zu Serve Discourse from a subfolder (path prefix) instead of a subdomain hinzugefügt wurde 
.