我来这里是希望能找到一个分步诊断指南，用于处理 Discourse 网站出现 502 Bad Gateway 错误的情况。似乎唯一的选项是：
./launcher rebuild app。这些是我们从一线技术支持或邮件机器人那里得到的回应。
我们还能做些什么来查看日志并确切了解环境为何崩溃？有了这些信息，我们或许就能学会如何防止将来出现此问题。
例如，是否可以编写一个 cron 进程来偶尔 ping Discourse，如果响应是 502 或类似的返回代码，则自动重建？
重建似乎是一种相当粗暴的解决问题的方法。它不是诊断。
我真的希望有人能为像我这样的菜鸟推荐一份我们可能错过的、关于“诊断 Discourse 问题”的流行文档。
谢谢！
从阅读这里的大量帖子来看，通常论坛管理员不是导致 502 错误的元凶，而是插件/核心错误。因此，您也无法采取太多措施来避免这些问题。
控制台日志总是有帮助的，它们很多时候都能查明有问题的插件。
我可以在此 VPS 上打开控制台，但文本窗口是有限的。
是否有可以在容器或操作系统中检查的特定日志？
主机操作系统或容器中是否已经有某种 ping 进程可以检测到进程何时停止运行？
与完全重建相比，在容器内简单地重启服务器是否是一种很好的方法？
顺便说一下，我正在运行最新的测试版/开发版，所以最近的更新很可能导致服务器宕机，正如我们过去所见。我现在不记得是否有安装任何非默认插件。
我有自由帮助诊断这个问题，而不会让我们的社区感到不满，尽管在几个月内我们需要迁移到更稳定的版本，只是为了让我们的用户感到舒适。所以，如果这是构建中的问题，我很乐意帮忙找到它。
谢谢！
我指的是浏览器日志，来自开发者工具或您浏览器上的相应工具。
我不这么认为，但您可以随时尝试。
磁盘已满吗？
这种情况经常发生吗？
请查看 /var/discourse/logs/rails/production.log
抱歉这么久才回来……
磁盘使用率低于 50%。
RAM 倾向于保持在 80-90 范围内，Swap 低于 40%。我猜问题出在这里。
日志位于 /var/discourse/shared/standalone/log/rails。
production.log 和相关的 gzipped 文件包含大量事务详细信息。我应该查找什么？
production_error.log 条目完全没有。
“经常”？不。但足够频繁，足以让人有点烦恼并在此发帖。
我查看了 syslog，没有发现任何内容——我不确定如果问题仅限于容器，那里是否会有任何内容，因为它应该是。
我是 Docker 新手，所以很抱歉我没有容器的信息，但很乐意按指示进行操作。
谢谢！
这没用。问题出在后端。它甚至没有得到服务器的响应（因此是“网关错误”）
你需要查看的是后端 Rails 日志。
尝试以下操作：
/var/discourse/shared/standalone/log/rails# tail -n 200 production.log 查看是否有明显的启动错误
在容器中（首先 ./launcher enter app）：
curl 0.0.0.0:3000 查看 Rails 服务器是否响应。
除此之外，移除所有插件，重建，然后逐个添加回来。
当 Rails 未返回响应时，会发生 502 错误，通常发生在系统启动或配置错误时。
您可以查看 nginx 日志。
我认为这里几乎所有关于 502 错误的帖子都是在 Discourse 升级后未能恢复正常的时候。升级失败了，或者管理员没有等待足够长的时间让服务启动。
您是说您的 Discourse 正在运行，您没有采取任何管理操作，但它却自发地开始返回 502 错误？
当这种情况发生时，它总是返回 502 直到重启，还是会间歇性地再次工作？