在花费一周时间寻找将 Discourse 与 Apache 并存的解决方案后，我不得不请求大家对我的下一步操作提供建议，因为鉴于 Discourse 偏向 Nginx 的设计，在 Apache 后方为 Discourse 启用 SSL 似乎几乎不可能实现。
我当前的托管环境结构如下：
我希望保留安装 WordPress 的灵活性，因此我并未确信 Nginx 是最佳选择，因为据我了解，Apache 与 WordPress 的兼容性更好。
我的目标： 在不将 Discourse 单独部署到另一个 droplet 的情况下，为整个域名（包括 Discourse）启用 SSL。如果这需要有限地使用 Nginx，我也能接受。我只需要知道应该参考哪些教程来解决这个混乱的局面。
谢谢。
我正在寻找类似的东西，但你们的进程已经领先了。如果不介意的话，我有几个关于你们配置的问题想确认一下：
仅供参考，我已在生产环境中对 Discourse 前端的 Apache2 和 nginx 反向代理（使用 Unix 套接字）进行了广泛测试，结果发现 nginx 并非“快得多”。
在此配置下，nginx 仅“稍快一些”，用户几乎察觉不到速度差异。
此外，Google Webmaster 工具中的 PageSpeed 测试（基于 LightSpeed）在一段时间内的平均值显示，两种反向代理之间并无显著差异。
这条仅供参考的评论并非基于理论或重复他人观点，而是基于真实生产环境的测试结果。
我们所有 Discourse 实例均部署在 Apache2 反向代理之后（最初使用的是 nginx 反向代理），因为我们喜欢在服务器上运行多个网站（虚拟主机），而这些服务器上已托管了 LAMP 应用。
任何希望使用 Apache2 而非 nginx 作为反向代理的用户都可以放心使用！这一事实使得 Discourse 能够被更广泛的用户和主机（Apache2 和 nginx）轻松采用。
@fzngagan 我不是要重新开始，而且那个教程是针对 CentOS 的，而我已在帖子中明确说明我使用的是 Ubuntu。
@EricGT 请查看我在我自己的帖子中分享的解决方案，因为如果你使用的不是 Nginx 或 CentOS，几乎不可能找到支持——正如这个帖子所证明的：我的问题没有得到任何回答，反而引发了一场关于 Apache 与 Nginx 的题外争论。
这确实可能是事实，但 Apache 的支持更为广泛。Discourse 是唯一一款基本上强迫用户必须使用 Nginx 的论坛软件。这就是为什么我更倾向于继续使用 Apache，因为它更常见、对新用户更友好，而且更容易找到支持。“调优”并不是我感兴趣的内容。
然而，Discourse 社区却 actively 劝阻这种做法，并拒绝为希望这样做的人提供支持，唯一的例外是链接到一些不受支持的教程。我已经创建了多个帖子并提出了更多问题，但只有你（在另一个帖子中）通过分享你的配置而稍微接近提供了支持。作为新手，我却被期望自行解读并将其应用到自己的环境中。其他所有内容要么是“看看这个过时的教程”，要么是题外闲聊。
正如我们多次明确说明的，由于时间和精力的限制，我们在免费支持方面所能提供的帮助是有限的。因此，我们提供了一个标准化的安装方案，该方案适用于 95% 尝试安装的用户，并且我们对此提供全面支持。
如果您希望了解针对自定义安装的付费支持选项，我建议您查看 #marketplace。
本论坛主要采用点对点模式，因此你的说法完全站不住脚。此外，我从未提出过复杂问题，只是寻求澄清，或对那些虽被持续链接但已过时或错误的现有教程进行更新。我曾向托管服务商 DigitalOcean 寻求帮助以配置正确的反向代理，他们的支持令人惊叹，即便对于开源软件而言也是如此。
你的回复让我觉得，这里的“支持”不过是一种推销的幌子。
亲爱的 @OrbitStorm：
首先，我们在生产环境中使用 Discourse，并通过 Apache2 反向代理（在多个实例中）运行，配置过程没有任何问题；除了大家都会毫不犹豫地去“谷歌搜索寻求帮助”这一常规操作外，一切顺利。
其次，我从未要求 Discourse 团队或 meta 论坛上的任何人支持 Apache2 作为我们的反向代理，因为该配置并未获得官方支持。据我所知，Discourse 也并未“官方”支持多容器配置、反向代理（如 Apache2）、Kubernetes、Docker Swarm 以及近乎无限的其他配置组合。Discourse 团队免费提供这一优秀的软件，并在 GitHub 上公开所有代码和每一次提交，因此限制其“官方支持的配置”是合理且正确的。我认为 Jeff 对此总结得非常到位：
正如我们多次明确指出的那样，由于时间和精力的限制，我们免费支持的范围是有限的。——Jeff A.
第三，Discourse 确实提供了一些针对“非官方支持”配置的教程，例如将 Apache2 用作反向代理；但配置反向代理本身并非“Discourse 特有的任务”，而是一项“通用的系统管理员任务”，适用于任何后端应用，包括 Discourse。
我们在多个 Web 应用（包括 Discourse、Docker Registry 以及其他 Docker 容器和应用）前使用 Apache 作为反向代理。使用 Apache2（或 nginx）作为反向代理与 Discourse 本身并无直接关联，它是一项通用的系统管理任务。
第四，网络上关于如何为应用配置 Apache2 作为反向代理的信息非常丰富。因此，就此事对 Discourse 团队进行指责不仅毫无必要，也无助于你的诉求。使用“闹剧”等词汇来欺凌他人，既不准确，也无助于解决问题（对任何人都没有帮助）。
因此，在此为你总结一下，@OrbitStorm（这是我关于你主题的最后一条回复，请仔细阅读）：正如之前所说，包括 J. A. 友善而耐心的话语，你其实有多种选择：
你可以轻松上网学习如何配置 Apache2 作为反向代理（这正是我们所做的）。学习这项通用的系统管理任务既有趣又免费。
如果你不愿学习、无法自行解决或没有时间，可以聘请专业人士代为完成。
你可以在这里抱怨发泄，称 meta 论坛为“闹剧”，并向所有人抛洒侮辱，试图通过欺凌迫使团队为你个人在不受支持的配置下提供支持。
作为一名 Discourse 用户和拥有数十年经验的系统管理员，我强烈建议你不要选择第 3 条（欺凌和恐吓对 meta 团队不会奏效，我可以向你保证）；如果你不想花钱寻求帮助，请考虑第 1 条。
为 Discourse 配置 Apache2 作为反向代理其实非常简单。Discourse meta 论坛上有一些相关帖子（有些较新，有些较旧），网络上也有无数关于如何为 Web 应用配置 Apache2 作为反向代理的教程。技术原理是相同的。我建议在反向代理模式下运行时暴露 Unix 套接字。
说实话，将 Apache2 配置为 Discourse 的虚拟主机反向代理是一件很有趣的事情。为什么要让这件事变得充满压力，并对创造这一优秀软件并免费分享它的开发者们恶语相向呢？Discourse 是一份免费的礼物！如果你希望以非官方支持的配置来使用 Discourse，没有人会阻止你！
最后，@OrbitStorm，我强烈建议你（以 Discourse 用户而非团队成员的身份）改变在 meta 论坛上通过欺凌来寻求支持的做法。正如我前面所说，我在“非官方支持”的配置中运行 Discourse，并在此发布过更新和代码以帮助他人（回馈这个优秀的社区）。我和其他人一样，已经发布了易于遵循的可用代码，用于配置 Apache2 作为反向代理。
请明智地选择第 1 条（自己动手）或第 2 条（聘请他人）；并请放弃目前的第 3 条做法（恐吓、欺凌和辱骂 meta 团队）。如果你执意选择第 3 条，可以去我们的 Unix 和 Linux 论坛发帖，在那里你想怎么欺凌我就欺凌我，随你便 
太长不看版：啥玩意儿？
你堆砌了这么一大段文字来回应，却从未真正触及原始话题，只是徒劳地试图扮演“白衣骑士”去保护一个根本没人攻击的东西。你甚至给我贴上了“霸凌者”的标签（笑？），只因为我回应了一个人发布的离题胡言乱语。那人对我进行了人身攻击，质疑我的智力，并把这个帖子当成了推广 Nginx 的讲坛（相关评论已被刻意删除，以掩盖该论坛对新用户滋生的毒性氛围）。你的第一帖也差不多，看似回答了我的问题，实则并未给出任何实质解答。你就是问题的一部分。
你一直强调“义务”，可你现在不就是这样吗？不断回复我的帖子，只为抬杠（就像 Stephen 那样）。我并不知道有任何规定禁止我为一种热门的主机配置寻求支持（W3Techs 之前已被引用，数据显示 Apache 的市场份额为 67%）。如果你不认可，大可以对我的帖子置之不理，但你却选择了挑衅并带偏话题。
你故意歪曲我的原话，只因我不愿盲从现状，接受过时的教程后就再也不回来——这也是几乎所有关于此配置的帖子都悬而未决的原因之一（即像你这类人的霸凌）。你真以为我在发帖前没有做足功课吗？我本已预料到会有这样的反应，但希望其他可能处于同样境地的人（比如 EricGT）能在那些自命不凡的“答案”将讨论彻底淹没之前，提供一些有价值的建议。
我在游戏开发领域耕耘了 16 年，却从未在短短五天内体验到如此荒谬的不专业和斤斤计较。这简直到了 Reddit 级别的幼稚程度，完全就是个笑话。
这也是个活生生的例子。简直令人难以置信。
我不明白为什么 SSL 配置会与代理后面的应用程序有关 
，只要 app.yml 中禁用了 SSL 模板即可？无论是 nginx、Apache、HAProxy 还是 Traefik，它们都有相同的片段/服务器块/虚拟主机概念，基本上就是开启 SSL，指定证书在主机上的位置，以及一些 SSL 参数，这里可能有些复杂？
我认为你寻找的解决方案并非与 Discourse 相关，而是与 Apache 相关。我相信任何开箱即用的、带有虚拟主机的 SSL Apache 配置都能与 Discourse 正常工作，就像它与其他反向代理配合一样，但我可能有点过于乐观了 
。
不过，我记得可能在加密套件方面遇到过问题，你要确保仔细复制/粘贴（该行非常长）Docker 容器中正在使用的加密套件。
关于这个滑坡谬误，我觉得这有点像偏离雪道滑雪，虽然很刺激，但非常不受山地救援队的欢迎。我承认，当你还在学习如何成为一名熟练的滑雪者时，如果掉进峡谷，情况会有所不同。
请，无论专业与否，都要对
好的，大家都需要从这个话题中休息一下。我们已经尽力提供帮助了。
此主题已在 13 天后自动开启。
