经过一番血汗与泪水后，我认为问题已经解决了。
不过，我并不是特别“自豪”于这个解决方案，但话说回来，这是谷歌，他们既不会回应也不会向你解释任何事，所以……结论如下：
-
首先，一个重要的教训：如果你在使用 Discourse，请不要在 DigitalOcean 上启用 IPv6，因为他们的 IPv6 地址段被 YouTube 屏蔽了。
-
在修复了 IPv6 问题之后，由于流量不断增加，无论更换了多少次主机（这真是一段旅程），随后发生的情况是：由于网站上发布的 YouTube 视频数量庞大，以及 Discourse 加载这些视频的方式，YouTube 开始对我的 Discourse 实例进行 IP 封锁。
-
要检查是否被封锁，你可以将你的服务器作为代理连接到一台带有浏览器的机器，或者直接使用 curl 请求，并查找以下信息：“抱歉，造成不便。我们检测到您的网络发送了大量请求。”（这里有一个相关主题供参考）
-
感谢 @riking、@neounix 和 @Overgrow 的帮助，我执行了一系列命令（你可以在上文看到），试图停止、限制或调整 YouTube 嵌入内容的重绘频率。对于大多数站点来说，这已经足够了，但我们还经历了在尝试了几家主机后迁移的额外麻烦，因此所有之前的帖子都需要重新渲染。事实上，最初将频率限制为每小时一次 勉强 解决了问题。但我猜我的社区 就是特别喜欢分享视频，所以这个方法并没有持续太久。
-
显然，YouTube 方面并没有提供任何反馈或帮助，除了他们的论坛上有几个关于该错误的帖子，所有评论都只是说“是啊，我也有这个问题”，但没有任何解决方案。
-
鉴于这种情况，回想起那种“肯定还有别的办法！”的广告逻辑，我选择了一种“兰博式”的方法：购买另一个 IP 地址，然后添加一个 cron 任务，每小时切换一次出站 IP 地址。问题解决了。
可以预见，如果网站继续增长，而人们 持续分享他们对 YouTube 的热爱，我可能需要购买第三个 IP。但无论如何，在我找到一种在 K8S 或其他环境中正确实现“分布式 Discourse”的方法之前，这已经是最理想的方案了。
我知道，这并不是最优雅的解决方案。
再次感谢大家的所有帮助（尤其是耐心，因为我知道我在 Rails/Sidekiq/RubyConsole 组合方面非常 n00b，但我正在通过阅读 Discourse 代码努力改进）。
谢谢！