AI improved debugging and text, so please read it with a pinch of salt.
Hello Cloudron team and community,
I've noticed a recurring issue with the official Discourse app package on Cloudron regarding client IP handling.
The Issue:
Every single web request and API poll in Discourse is logged with the internal Docker proxy/gateway IP (172.18.0.1) instead of the actual client IP address:
172.18.0.1 - - [24/Oct/2026:21:55:38 +0000] "GET /admin/users/... HTTP/1.1" 200 ...
Why this happens:
Ruby on Rails uses ActionDispatch::RemoteIp to inspect the X-Forwarded-For header. By default, Rails discards this header for security reasons unless the sending proxy IP is explicitly defined in Rails' trusted_proxies configuration. Because Cloudron routes traffic through the internal Docker network (172.16.0.0/12), Rails doesn't trust it out-of-the-box and falls back to 172.18.0.1.
The Impact:
- All users appear to share the exact same IP address in the admin panel.
- GeoIP lookups and IP-based security features in Discourse are completely broken.
Proposed Solution:
Could the Cloudron Discourse package be updated to officially include the internal Docker network in Rails' trusted_proxies configuration? (e.g., via a permanent initializer or environment handling):
require "ipaddr"
Rails.application.config.action_dispatch.trusted_proxies = [
IPAddr.new("127.0.0.1"),
IPAddr.new("::1"),
IPAddr.new("172.16.0.0/12")
]
Since manual file modifications inside /app/code/config/initializers/ are completely wiped out during app updates, having this built into the official Cloudron package would permanently solve this headache.
Thanks for your amazing work on Cloudron! Looking forward to your feedback.