In a Discourse forum setup using Nginx as a front-end proxy with Let’s Encrypt SSL outside the Docker container, user dax reported that oneboxing fails for internal links over HTTPS, treating them as external. The issue was resolved by enabling force_https in Discourse’s admin settings dax, despite running Discourse via Unix socket with SSL handled externally. Falco cautioned that misconfigured reverse proxies can break the site but confirmed that correct HTTP headers (like X-Forwarded-Proto, X-Forwarded-For, and Host) allow HTTPS to function properly even without the internal SSL template Falco. tophee later asked for clarification on required headers, sharing their Nginx config which includes standard proxy headers. After enabling force_https, dax confirmed the issue was resolved. The discussion highlights the importance of proper header forwarding and SSL enforcement in reverse-proxied Discourse installations.
We set Nginx has a front-end proxy for discourse docker (with sock Add an offline page to display when Discourse is rebuilding or starting up).
Then we set HTTPS Lets’ Encrypt outside the container (acme.sh) and everything works fine except onebox for internal link.
Onebox is not able to show the preview of internal links. They are as external links
Just made a backup, we will try to check the “force_https” setting. Do you confirm that even if discourse runs through sock, and so the “ssl template” is commented out, everything should work fine?
Our reverse proxy is configured to redirect all http traffic to https.