了解しました。つまり、これは Rails や他の gem がヘッダーをどのように処理するかという話であり、Discourse のコードがどう動くかという話ではありませんね。
Rails が X-Real-IP を使用していないのは興味深いです。X-Forwarded-For よりも使用頻度は低いかもしれませんが、Forwarded や Client-IP よりも確実に知名度が高いはずです 
。
おそらく Nginx の設定では X-Real-IP は時代遅れなのでしょう。Discourse はログで X-Forwarded-For と共に X-Real-IP を拡張して使用しているのでしょうか？私の解釈が正しいとすれば、コード内の他の明示的な使用箇所や言及は見つかりませんでした：
- discourse/lib/discourse_logstash_logger.rb at main · discourse/discourse · GitHub
- logster/lib/logster/message.rb at main · discourse/logster · GitHub
以下は、共有レート制限のデバッグ中に無効な「unix:」クライアントIPに関するエラーをログで確認した際、2点において不自然に見えました（Discourse アップグレード後、コンテナの前にUNIXソケットプロキシを使用しており、X-Forwarded-For に依存しています）。
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
しかし、「これで動く」というのは、$remote_addr を唯一の信頼できる情報源とし、real_ip_header を Discourse/Rails が受け取る単一のIPを管理者が制御するための標準的な方法とする、という理解で正しいと思います。これが Serve Discourse from a subfolder (path prefix) instead of a subdomain にすでに追加されていたことを確認しました 
。