它仍然在反向代理后面，我只是找到了一个模板和几种不同的方法来处理 Discourse。同时仍然使用官方安装方法。
我将很快发布一个指南。以防其他人需要使用它，或者我可能需要再次使用它，哈哈。
只有一个小问题，因为我的安装没有使用 letsencrypt SSL。发送的电子邮件激活链接是 http 而不是 https。有一个将所有 http 重定向到 https 的规则，但我希望从后端强制 https，以便所有链接都使用 https 而不是 http。
编辑：找到了
#强制 SSL
DISCOURSE_FORCE_HTTPS: true
您……您正在使用反向代理，为什么还要将 HTTPS 发送到后端？
设置强制 HTTPS 会告诉 Discourse 将所有对其自身的引用都设为 HTTPS。
是的，但这并没有回答“为什么”的问题。
这样可以保持连接加密。
WAN → 反向代理 = HTTPS
反向代理 → 后端 = HTTPS
这样，如果出于任何原因有人可以访问我的服务器机房，他们就不能仅仅通过插入以太网电缆就能清楚地看到流量。连接仍然会是 HTTPS，这会给入侵者增加一点难度。我希望我的连接是完整的 HTTPS。而不是 WAN HTTPS → 反向代理 HTTP → 后端。
否则，那将仅仅是“蛋壳安全”。
零信任，即使我认识你 10 年以上。
公平地说，如果你对迁移到私有网络这一点毫无信任，或者在反向代理作为守门人的情况下无法构建安全网络。
您的安全措施已做到极致。
您难道没注意到大多数泄露都来自内部吗？这样我就能确信我的服务器安全是万无一失的，唯一可能存在的漏洞就是人为因素，我的员工对此百分之百清楚。
我有一些备受瞩目的云用户，如果他们的数据因某种奇迹般的原因泄露，而我知道我的服务器安全是万无一失的。那么我就可以查看监控录像，确切地知道谁是数据泄露的罪魁祸首。
我认为 AWS 的做法也差不多，据我所见。人为漏洞始终应该是重中之重，无论您的服务器有多安全。一个 U 盘就能毁掉一切。
因为如果你不这样做，它会，例如，发送电子邮件链接，这些链接会指向 http 而不是 https，或者指向 http 而不是 https 的图片。如果 discourse 可以判断它是 https，那么它默认就会这样做；我不太确定为什么现在它不是默认设置，因为如果存在任何 http 链接，Discourse 基本上就无法工作。
这与反向代理和 Discourse 之间的连接无关，而是与 Discourse 自身生成的链接有关。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.