我很希望能得到一些建议，同时也有一些关于如何更好处理此事的想法。
可能发生了什么
一种理论是，我们的服务器可能被 YouTube 识别为在批量抓取音乐视频，从而受到限制或被封锁。
我们只是英国一个不起眼的小论坛，流量微薄，但有几个帖子（实际上是一个因篇幅过大而拆分为两个的帖子），分别包含 1 万和 2 千条音乐视频帖子。这是一个音乐接龙：下一位发帖人只需发布一首与前帖相关（有时是某种间接关联）的歌曲。
当然，我们还有其他包含 YouTube 链接的帖子，但这一条尤其密集（约 100%）全是音乐内容。
本周末进行了一次重新生成（rebake）后，我推测 YouTube 可能注意到 Onebox 器试图抓取大量音乐视频的头部信息，其算法因此将我们列入了“黑名单”。
随后我重新尝试生成帖子，这恐怕进一步证实了 YouTube 的怀疑：从该 IP 地址发出的所有请求似乎都只是为了下载音乐视频。
可能与 Digital Ocean 有关
因此，我在 Google 上搜索 YouTube 的 429 错误，忽略所有 YouTube API 相关结果后，最终指向了一组听起来类似的问题，这些问题的共同点是：由于使用虚拟服务器，其 IP 地址被灰名单化/黑名单化/封禁，其中特别提到了 Digital Ocean。
有观点认为，YouTube 可能会“封禁”一系列 IP 地址，导致其他合法服务器也遭受牵连。
以下是其中一个问题及潜在解决方案：
https://support.google.com/youtube/thread/21697789?hl=en
还有另一位在 medium.com 上工作的 embed.ly API 开发人员提出的另一个案例：
https://support.google.com/youtube/thread/21939228?hl=en
第一个帖子中提出的建议是在 droplet 上禁用 IPv6。
有人知道这听起来是否合理，或者是否会引起其他问题吗？
我目前尚未执行此操作，以便收集可能有助于解决问题的其他数据。
应该发生什么？
首先，我理解大家的反应可能是：我的情况属于边缘案例，无需做出任何更改。
我能理解这一点。但如果 @marcozambi 和我在相对较短的时间内发现了相同的问题，那就表明其他人也可能遇到类似情况。也许 YouTube 最近对嵌入内容的监管变得更加严格了？
我想提醒大家，目前我的论坛完全处于停滞状态。我有数万个链接未能成功生成 Onebox，但我不知道它们具体在哪里。唯一能想到的办法是全面重新生成，但这几乎肯定会招致 YouTube 更多的负面关注。
至少，当 Onebox 遇到速率限制错误时，不能静默失败。它必须引起管理员的注意，并在可能的情况下暂停触发速率限制问题的进程。
让论坛所有者注意到此问题的选项
我认为这并不容易，一点都不容易。
我认为 Onebox 扮演着几种截然不同的角色：
a) 在用户撰写帖子时实时构建 Onebox；
b) 在后台无头模式下响应旧帖子的重新生成（通常包含已知链接）；
c) 在迁移/重新生成期间处理大量后台作业帖子。
如果速率限制错误发生在场景 a) 中，作者会注意到 Onebox 未展开，可能会向论坛管理员投诉，从而引起注意。也许也可以在撰写过程中捕获该单一错误，并向管理员推送错误或消息？
在场景 b) 中，失败可能发生在帖子后台处理过程中，因此需要重试；如果重试次数已达上限，则应标记为失败并通知论坛管理员。
在场景 c) 中，需要知晓大量失败同时发生的整体背景。目前，我认为没有对帖子重新生成过程的全局控制，因此无法将 Onebox 返回的 10,000 个 429 错误识别为一个更大的问题，而不是向管理员发送 10,000 条独立消息。
实际上，此类故障意味着所有针对 YouTube（可能还有其他提供商）视频展开的 Onebox 调用都必须暂停，直到我们不再受速率限制。
其他方法
限制出站请求
我想“预防胜于治疗”的原则可能意味着可以在 Discourse 请求前设置速率限制器，这样 Discourse 就可以根据某些配置设置来暂缓请求。
但这会给重新生成和迁移带来极大麻烦。
Onebox Assistant
也许我们都需要与缓存和代理嵌入内容的机构建立商业合作关系，例如 @merefield 在其 Onebox Assistant 插件中使用的服务？
将“机器人”加入白名单
我们能否找到一种方法将 Discourse 的“机器人”加入 YouTube 白名单？这可能过于开放，容易遭到滥用。
YouTube API
就像 Onebox 对 Twitter 所做的那样，如果 YouTube API 的速率限制更高，我们是否可以使用它？
