你好 @Iceman
是的，我刚刚在数据库中为你进行了搜索，但找不到存储该设置的任何表或字段（它不在 site_settings 表中）
关于你的评论：
… 五个小时后封禁仍然存在
我对 Google 如何管理这些“封禁”没有特别的专业知识，但我怀疑在其算法触发封禁后，Google 可能需要更长的时间才能“解封”（几天甚至几周）。
不过，我也并不了解这个封禁“流程”是如何运作的，甚至不知道这个封禁流程的“Google 官方名称”是什么。
你知道吗？
Google 是否有支持页面讨论这个问题？你提到的这个封禁流程的确切名称是什么？
确实没有 Google 的支持页面详细解释其 DoS 防护拦截机制或任何相关系统的工作原理。
经过一番血汗与泪水后，我认为问题已经解决了。
不过，我并不是特别“自豪”于这个解决方案，但话说回来，这是谷歌，他们既不会回应也不会向你解释任何事，所以……结论如下：
首先，一个重要的教训：如果你在使用 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 代码努力改进）。
谢谢！
太棒了！
这是一个富有创意、行之有效、真正“跳出框框思考”的解决方案。
恭喜您以如此优雅和巧妙的方式解决了难题！
在采纳了相关建议后，我几天前为我们的 Discourse 论坛上的 AWS S3 存储桶配置了 CloudFront CDN。
随后，我在控制面板中添加了 S3 CDN 的 URL，并立即对超过 20 万篇帖子执行了重新烘焙（rebake）命令。
当时并未多想，以为一切正常，系统在接下来的 12 小时左右默默运行着。
我们的 Discourse 论坛嵌入了大量视频。作为一个无人机/UAV 社区，用户全天候发布和分享图片与视频，帖子中包含数万条 YouTube 视频链接。
现在回想起来……在添加 CDN URL 后，我可能只需要重新烘焙匹配 *.jpg 模式（或类似模式）的帖子即可：（捂脸）：（哭）。
无论如何，现在发生了什么呢？
YouTube 已经封锁了我们服务器的 IP 地址：（沉思）
我们再也无法对任何 YouTube 链接进行 onebox 嵌入，社区用户看到的提示是：
429 Too Many Requests
（在服务器本机上使用简单的 curl 或 wget 命令也会返回同样的错误）
显然，在重新烘焙过程中某个时刻我们被封锁了，因为原本能正常播放视频的一半帖子，现在都无法播放了：（大哭）
我假设这次封锁是永久性的，但正如大家所知，根本无法联系到 YouTube 的相关人员去请求解封。
万一这次封锁确实是永久性的，想请教一下 @Iceman：您能否分享一下如何在 DigitalOcean 获取第二个 IP 地址，并进行了哪些配置，以便将“出站”流量通过该新 IP 路由，而“入站”流量仍使用原有 IP？
另外想请教大家：是否有人知道这次封锁可能只是暂时的？（祈祷）或者，我还能做些什么来修复目前严重受损的 YouTube 帖子？
对于一个高度依赖媒体内容的社区来说，这对我们来说简直是一场灾难。
这不太可能是永久性的，它很可能会随着时间的推移而消失。
如果有人正在寻找同样的更改，可以使用 重映射 来代替重新生成，这几乎是瞬间完成的，而且不会向任何地方发送请求。
抱歉回复晚了。
关于 Digital Ocean，我帮不上忙，因为他们的 IPv6 支持不足，我已经弃用了。
我一直在为负责向 YouTube 发起出站请求的“交换机”添加更多 IP，并在这些 IP 之间轮换，以避免被封禁。但它们最终仍会被封禁，从而陷入死循环。如果你被封禁，且该 IP 继续发起请求，就会持续被封。你需要停止请求 1 到 8 小时，YouTube 才会“解封”。用户越多，他们发布的 YouTube 视频越多，情况就越糟糕。
多亏 Oneboxes 的最新更新，现在更容易发现问题了（因为可以在 Discourse 内部直接看到 429 错误，而无需因视频无法正确显示而去四处排查）。不过，根据我有限的理解，我在想是否还有更好的方式来处理 YouTube 嵌入。因为当视频播放时，请求似乎来自客户端 IP（我猜），但当视频显示时，请求却是由你的网站针对每个视频发起的。
感谢 @Iceman 
这信息真的很有用。
我在周五安装了一个 Onebox Assistant 插件，并将所有一一盒子（oneboxes）的请求都通过 embed.rocks 代理进行路由。
今天，我在服务器控制台上尝试随机 wget 一个 YouTube 视频。
果然，我们已经被解封了！
今天下午再次禁用了 Onebox Assistant，现在我们直接拉取内容，目前为止一切正常。
如果我没有这么做，我想你是对的，我们可能永远无法解封，因为人们会不断发布新视频，导致我们每隔一小时左右就会向 YouTube 发起请求 
再次感谢 
我使用了一个变体来温和地处理大量帖子。这是一个低风险且能大幅节省时间的建议，感谢 @riking！
附注：我使用以下命令来跟踪进度：
Post.where(baked_version: nil).count