首先，我完全了解 Discourse 的推荐配置方案，但遗憾的是，目前这已超出我的控制范围。
接下来谈谈问题所在。我的客户曾定制开发了一个使用 Discourse 作为后端应用的 React 前端。我接手这个项目时，它已处于糟糕的状态，之前的开发人员曾试图将 ActionCable 强行整合进 Discourse。鉴于 Discourse 本身已使用 Message Bus 来实现实时功能，我认为我们应该尝试利用它。
在本地环境中，我们成功了。Message Bus“开箱即用”，我们不仅能够订阅所有默认的 Discourse Message Bus 频道，还能创建一些自定义频道。
问题出现在我们的远程环境中。我们部署在位于 ALB（应用负载均衡器）后方的 AWS EC2 实例上，并自行搭建环境。我本很希望能采用 Docker 方案，但客户在这个项目阶段没有预算投入时间进行变更 
。
主要症状是 Message Bus 严重滞后。实际上没有任何功能真正实现了实时性，但我们知道 Message Bus 的配置没问题，因为它在本地运行良好，所以问题一定出在其他地方。
我几乎使用的是 Discourse 默认的 Nginx 配置。起初我以为这是问题所在，因为 Message Bus 的 Nginx 配置缺失，但在添加该配置后，似乎并未解决我们遇到的这些问题。
查看 Chrome 的网络标签页后，问题显而易见：我们的 /poll 请求会等待 25 秒，然后仅用几毫秒下载内容。我知道情况应该恰恰相反，就像我在本地运行或在 meta 站点上运行时那样。
我知道这可能也是 AWS ALB 的问题，但我真的毫无头绪，不知从何入手。我在想 @sam 是否对问题所在有任何见解，或者能否为我指明正确的方向。
一如既往，任何帮助都将不胜感激！