알겠습니다. 즉, 헤더를 어떻게 처리하는가는 Rails나 다른 gem들이 하는 일과 더 관련이 있고, Discourse 코드가 하는 일과는 덜 관련이 있다는 거군요.
Rails가 X-Real-IP를 사용하지 않는다는 점이 흥미롭네요. X-Forwarded-For보다는 덜 일반적으로 사용되지만, Forwarded나 Client-IP보다는 확실히 더 잘 알려진 헤더이거든요. 
아마 X-Real-IP는 Nginx 설정에서 이제 불필요한 것이겠죠. 제 이해가 맞다면, 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
아래 설정은 공유 레이트 리미팅을 디버깅하던 중, Discourse 업그레이드 후 잘못된 “unix:” 클라이언트 IP에 대한 오류가 기록되는 것을 보고 두 가지 측면에서 잘못되었다고 느꼈습니다. (우리는 컨테이너 앞에 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를 제어하는 표준적인 방법으로 사용하는 "동작한다"는 논리는 이해합니다. 이미 https://meta.discourse.org/t/serve-discourse-from-a-subfolder-path-prefix-instead-of-a-subdomain/30507 에 추가되었던 것을 확인했습니다. :+1:.