C’est clair, donc cela concerne davantage ce que Rails ou d’autres gems font avec les en-têtes, et moins ce que le code de Discourse fait.
Il est intéressant de noter que Rails n’utilise pas X-Real-IP, qui est probablement moins couramment utilisé que X-Forwarded-For, mais certainement mieux connu que Forwarded et Client-IP 
.
X-Real-IP est donc probablement obsolète dans la configuration Nginx. Discourse l’utilise en complément de X-Forwarded-For dans les journaux, si je l’interprète correctement ? Je n’ai trouvé aucune autre utilisation ou mention explicite dans le code :
- discourse/lib/discourse_logstash_logger.rb at main · discourse/discourse · GitHub
- logster/lib/logster/message.rb at main · discourse/logster · GitHub
Le passage ci-dessous m’a semblé incorrect à deux égards lorsque je l’ai vu pendant le débogage du partage de la limitation de débit et les erreurs enregistrées concernant l’adresse IP cliente « unix: » invalide après notre mise à niveau de Discourse (nous utilisons un proxy via socket UNIX devant le conteneur et nous nous appuyons sur X-Forwarded-For).
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
Mais je comprends que « ça marche » pour faire de $remote_addr la seule source de vérité fiable, et real_ip_header la méthode canonique pour que les administrateurs contrôlent l’unique adresse IP que Discourse/Rails reçoit. Je vois qu’elle a déjà été ajoutée à Serve Discourse from a subfolder (path prefix) instead of a subdomain 
.