是不是因为内存不足（RAM），导致 OOM Killer 终止了一些随机进程（例如 sshd），从而造成你被断开连接并引发问题？
如果 OOM Killer 正在运行，在 dmesg 输出、/var/log/messages 或 journalctl 输出中应该会有相关记录。
可能是内存问题。你有交换空间吗？
您是否尝试过调整“保持活动”设置，例如这样？
@pfaffman 我没有任何特别指定——使用了所有 Droplet 的默认设置，依赖 DigitalOcean 团队确保其行为合理。
首先，我将尝试按照 @omarfilip 在上文中建议的那样设置 keep-alive，然后我会检查交换空间的情况，接着是 @pfaffman 提出的使用 DigitalOcean 原生控制台的建议（如果 keep-alive 设置允许我继续使用 PuTTY 控制台，我会使用它，因为它比 DigitalOcean 的等效控制台用户友好得多）。
有这么多友好的人帮助我，我想重申我尝试将 Ghost 和 Discourse 整合在一起的原因：在我看来，这是撰写技术文档并为这些文档的讨论提供最佳支持的理想工具。我的计划是使用几个有趣的 PaaS IAM 提供商来解决身份和账户管理（IAM）问题；这一主题尚未得到充分记录（至少根据我自己多年使用此类服务的经验，我是这样认为的）。
为了“测试”我的 Ghost/Discourse 整合工具，我决定详细描述创建和测试该工具的全过程。因此，所有帮助我的人应该知道，这项努力旨在帮助 Discourse、Ghost 和 Digital Ocean 社区。
如果您使用的是 DigitalOcean 的一键安装，而非 Discourse 官方标准安装，那么很可能未配置交换空间（swap）。因此，在重建时，除非您的内存大于 2GB，否则很容易耗尽内存。
您可以尝试执行以下命令：
cd /var/discourse
./discourse-setup
如果需要，该命令会自动为您创建交换空间。
如果您希望获得 DigitalOcean 一键安装的帮助，并“依赖 DigitalOcean 团队确保合理的行为”，那么您也应该依赖他们来为您提供支持。
不过，既然我已经在回复，还有一个更简单的方法来确认问题是否出在 PuTTY 上（这可以避免在 PuTTY 参数上徒劳地花费大量时间），那就是尝试使用控制台。如果您尚未运行过 discourse-setup，那么我相当确定问题出在交换空间不足上。
@pfaffman 我严格按照 Discourse 官方安装流程进行了操作，其中包括了该官方安装文档中引用的 PuTTY。
您可能由此推断我是通过 Digital Ocean 的一键安装方式部署的，并认为我应该依赖 Digital Ocean 的支持：
如果您需要 Digital Ocean 一键安装方面的帮助，并希望“依靠 Digital Ocean 团队确保合理的行为”，那么您就应该依赖他们来为您提供支持。
我提及“一键安装”是源于最近收到的一封来自 Discourse 的邮件：
太好了，Discourse 的新版本已发布！
您的版本：2.7.0.beta1
新版本：2.7.0.beta2
- 使用我们便捷的 一键浏览器升级 进行升级
因此，目前的情况是：
- 我由衷感谢您提供的帮助，Jay
。我知道您以协助 Discourse 用户为生。尽管我看起来不像潜在客户，您仍花时间帮我摆脱困境。 - 一旦我了解到无论怎样调整保活设置，PuTTY 都会出现异常，我便从基于 SSH 的认证切换为“用户 ID/密码”组合，登录到 Droplet 主机，并成功执行了
./launcher rebuild app命令，顺利完成了 2.7.0.beta2 版本的升级，整个过程轻松顺利。
非常感谢所有提供解决方案部分的各位。
哦！是我的错！非常抱歉！
那么您确实有 swap 分区，我之前的猜测全错了。这太遗憾了，因为本来可以很容易解决的。
在我错误地指责您之后，这真是个好消息！
而且得知 PuTTY 这么糟糕也让人难以接受。我不明白为什么它仍然是 Windows 上推荐的 SSH 客户端。
我想现在 Linux 子系统（WSL）中已经内置了一些客户端，但我经常使用的 Windows 版本是 Windows 98。
很高兴您已经解决了这个问题！
所有现代操作系统都自带 SSH 客户端，无需第三方客户端。即使在 Windows Terminal 中，我也只需输入 SSH 即可。只要您的 Windows 已更新，它就应该能正常工作。
天哪，真的吗？我上次（自以为）查看时，它似乎需要一些看起来很难的安装步骤。
而且它可以使用普通的 SSH 密钥，而不是那种 PEM 格式的麻烦东西吗？
这篇长篇故事有一个圆满的结局，可以说是一场虚惊。我学到了很多关于 Discourse 的知识，因此打算长期留在这里。以下是这个圆满结局的具体描述：
-
我从 Beta1 升级到 Beta2 时遇到的问题表现为 PuTTY 控制台超时。我将其解读为 Discourse 升级任务发生了严重崩溃，并花费了大量时间学习 Discourse 的“内部机制”——这是一条我本不必踏入却非常乐意探索的兔子洞。
-
我的问题解决方案极其简单（一旦你知道该“往哪里推”）——简单如 1、2、3 如下：
（事实是，我一开始设置的“保持连接”间隔过长，让我误以为 PuTTY 是非常糟糕的软件，并花费了大量时间从基于 SSH 的 droplet 访问切换到需要用于 Digital Ocean 自身控制台的 [ID, 密码] 认证方式（这确实很糟糕）。注意，这次实验完全为 PuTTY 工具正名。 -
@Falco 打开了我们的“集体视野”，指出只需使用 Windows 10 内置的 OpenSSH（感谢 Scott Hanselman）。
既然我已经向 @codinghorror 承诺要撰写一份史上最佳文档，向全世界介绍 Discourse，以此感谢他（及其团队）帮助我理解 Discourse，那么 @pfaffman 让我将 @Falco 的这个建议作为我文档的第一部分。
我建议使用 tmux，这样即使你的客户端超时，你也能重新连接到正在运行的重建会话。
@md-misko 感谢你的提示：
tmux 的妙处在于它允许你同时打开多个窗格，每个窗格都运行独立的 shell，但共用同一个 SSH 连接。不仅如此，你还可以同时打开多个“窗口”，有点像浏览器标签页，每个标签页里还能包含更多窗格。
嗨 @sunjam，看来这个问题可以通过新版 gem omniauth-vkontakte 1.7.0 来解决。
我已向该插件的维护者提交了拉取请求。作为临时解决方案，您可以将 app.yml 中的 GitHub 链接切换为：
- git clone https://github.com/rapekas/discourse-vk-auth
然后重新构建。