我正在尝试菊花链 CloudFront 发行版，并且由于我想在该线程中了解原因，我遇到了“不超过两个链式发行版”限制以及由此产生的 HTTP 403 响应。我听说过 CloudFront 链接及其限制在另一篇 SO 帖子中（它自己有一个相当重复的版本，不要像我一样感到困惑......）
这是我们的设置：由于我们的产品提供了一个白标解决方案，其中包含数千个客户域和相关证书，因此我们有很多云前端发行版（每个域至少一个，加上子域），这可以作为管理的一种解决方法所有证书。 （从长远来看，这个解决方案也可能会受到质疑，但这本身就是一项艰巨的任务）它们的起源指向应用程序的负载均衡器。
这就是我想要实现的目标：为了能够集中 CDN 相关任务的任何配置，我想让这些发行版指向另一个（新的、单个）发行版，而不是我们应用程序的负载均衡器，以便任何配置（原点更改） /caching/...) 可以在这个发行版上进行，而不是编写脚本来运行所有 1000 多个 CF 发行版。
问题： 正如链接的 SO 帖子中所指出的，CloudFront 只允许链接两个发行版。第三次将导致来自 CF 的 HTTP 403 响应。我的问题是，虽然我的解决方案只涉及两个实例的链接，但我确实得到了这种行为。
我的调试研究： 链接的 SO 帖子建议使用
curl -v domain.com我无法找出实际涉及的 CF 实例，因为 via 标头中引用的域似乎是易失性的/动态生成的并经过哈希处理。
我的问题： 您对如何进一步调试有什么建议吗？或者您能否进一步阐明 CF 发行版的工作原理，因为显然我对它们的概念是错误的：以我的 LB 为起点的两个 CF 发行版，您可以通过 CF 每个获得一跳，将它们链接在一起，您将获得三跳。我期望链接它们应该只进行两次跳跃的想法哪里错了？谢谢！
我想我找到了解决方案： 它与有关主机标头转发的链接 SO 帖子的相关性比我想象的更相关，因为在这种设置中很可能会失败。 我回答了这个问题，涉及使用 Lambda 函数的 X-Forward-Header，或者更假设地说，因为我没有检查第二个 CF 发行版中的备用域名。