我们使用 Azure Front Door 来服务我们的白标静态网站，这意味着我们需要我们的客户能够通过独特的子域(例如 cust1.domain.com 和 cust2.domain.com)。
我们通过 DNS 将 *.domain.com CNAME 到我们的 Front Door 实例，映射 *.domain.com 的路由并将其绑定(bind)到自定义 >*.domain.com 通配符证书(非托管，不受支持)。该路由指向一个源组，该组又指向一个“存储(静态网站)”源，类似于 prod-storage.z14.web.core.windows.net。
有时在 Safari 上，我们会收到如下所示的响应:
<h2>Our services aren't available right now</h2><p>We're working to restore all services as soon as possible. Please check back soon.</p>0a1LIYwAAAADIYjiE3LgzTLfw86bqHEd5Q0hHRURHRTE2MTAAYTk0OGVmNjEtMTk3NS00ZjA0LTkwMjgtOTgwY2I4YzllYzFl
在查看网络选项卡时，我们发现响应实际上是 421 Misdirected Request。我的假设是它与此更新有关:https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq#how-does-front-door-handle--domain-fronting--behavior--
设置此流程以避免 Front Door 出现此新问题的正确方法是什么？我们的案例有些独特，据我所知，没有记录。
我见过的解决方案包括关闭 HTTP/2、为每个域创建单独的证书以及使用不同的 IP - 这些解决方案都无效，也无法与我们的解决方案一起扩展，因为我们需要不受限制地动态创建新的子域(即，以编程方式将它们添加到 AFD 是不现实的)。
最佳答案
我最终通过联系 Microsoft 支持人员并要求他们关闭域前置阻止来解决此问题，根据我们的后续测试，这似乎已经完全解决了 Safari 上的问题。希望有更好的解决方案，但这目前对我们有用。
关于azure - 使用通配符路由时偶尔会收到来自 Azure Front Door 的 421 响应代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/75165055/