当尝试登录失败（即 force_https=true）时，运行中的 Docker 容器内的 log/production.log 文件显示了什么信息？
@RGJ – 我喜欢你的解决方案！对于最后的建议，我需要启用 force-https 吗？关于 proxy_pass https。
编辑： 如果我只使用 proxy_pass https://192.168.86.108，我会收到 502 错误。
编辑2： 我在 app.yml 中通过 Discourse 隐藏了 80 端口，但它仍然无法工作——我重新读了你的帖子，Discourse 容器是否拥有自己的 Nginx 实例？所以，实际上，我是在将一个代理转发给另一个代理？抱歉，我现在真的有点困惑。
@itsbhanusharma 我需要注释掉 80:80 #http 并采用 @RGJ 的建议使用 proxy_pass https 吗？
为什么在这里不遵循多站点支持的流程？你实际上是在重新发明一个非常脆弱的轮子。
现在提供了这么多链接，@Stephen，我简直不知如何理清头绪。我以为自己遵循的是受支持的操作流程。上面的评论难道不受支持吗？
是的，因为你没有使用 force_https，所以才会出现上方的 unsupported-install 标签。如果你偏离了受支持的配置方案，将无法获得太多帮助。
请从这里开始：
另有一份指南专门介绍如何在多站点环境中处理 SSL 封装。
那么，标准容器是否仅运行 http？我尝试实现的是多站点功能，这如何成立？我并没有尝试托管多个域名，而是只有一个域名。能否请您澄清一下，这如何解决我的问题？
你这句话是什么意思：
我已经在大约 5 个实例上部署了 Discourse 服务器，它们似乎都表现出异常行为；不确定这是否真的是一个 Bug，或者是否有人也遇到过同样的问题。
独立的设施，彼此之间没有任何关联。
但所有设施的设置均与上述内容非常相似。
那么，为什么 nginx 要代理主机呢？这些机器上还在发生什么？
我们有一些未对外暴露的虚拟机，流量通过代理（已对外暴露）路由到内部的 Discourse 虚拟机。每个独立安装的情况都类似。这样说明清楚了吗？
确实如此，但无论如何，这是你必须忍受的技术痛点。在使用场景和拓扑结构如此模糊的情况下，根本无法评论是否存在更好的方法。
我认为正确的解决方案组合如下：
正如 @itsbhanusharma 所述：
编辑 /var/discourse/containers/app.yml 并将端口修改为自定义端口，我使用的是：
- "8080:80" #http
- "4343:443" #https
执行了 ./launcher rebuild app
随后，我修改了外部可访问的代理，将 80/443 端口上的请求转发到 http://internal_ip:8080。
在运行 sudo nginx -t 和 sudo systemctl restart nginx 之后，我登录到 https://discourse.mobiusnode.io 服务器（该服务器此前仍显示上述问题），并启用了 force_https 选项，此后似乎一切正常。
我现在将在其余服务器/基础设施上复现此过程。
为明确起见，这并非我所建议的方案。
我只是要求你在本地 IP 上暴露 80 端口，并在反向代理上终止 SSL。
那么，是否应该不在对外暴露的代理上使用 SSL，而是将普通的 http 请求转发到 Discourse 服务器，并让 force_https 来处理这些请求？这样的话，证书是如何传递的呢？是通过第一个 Nginx 实例吗？这正是我困惑的地方。
嗯，只要它能正常工作，并且你可以干净地重建或升级。看起来你已经在做 @itsbhanusharma 在其最新帖子中建议的事情了。
如果您在多个 SSL 连接之间共享单个 IP 地址，则需要在代理的前端使用 SAN 证书。如果网络是安全的，则其后的一切都可以不进行加密。
如果用户通过 SSL 连接，Discourse 需要启用 force_https，并且您需要确保上述标记的标头被保留并转发。
不，有一种称为 SNI 的技术。
我很清楚这一点，但由于所有证书都来自 Let’s Encrypt，申请单独的证书有什么价值呢？LE 支持 SAN，为什么不使用它呢？