我们正在使用Azure前门服务于我们的白标签静态网站，这意味着我们需要我们的客户能够通过唯一的子域(例如，cust1.domain.com和cust2.domain.com)访问它。
我们通过DNS CNAME*.domain.com到我们的前门实例，映射*.domain.com的路由并将其绑定到自定义*.domain.com通配符证书(未管理，不支持)。路由指向一个源组，而源组又指向一个"存储(静态网站)"。来源类似prod-storage.z14.web.core.windows.net.
<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是不现实的)。
最后，我联系了微软支持部门，要求他们关闭域名前端块，根据我们的后续测试，这似乎已经完全解决了Safari上的问题。我希望有一个更好的解决方案，但这对我们现在有效。
有趣的是，AFD是一个反向代理，RFC 7540 9.1.2。状态代理不应该生成此响应。从去年11月起，微软禁止了域名前端，据推测，在去年4月，微软已经发出警告，让用户远离它。
从其他研究来看，Safari不能正确处理这个问题的原因是上面引用的相同的RFC部分说客户端"可以在不同的连接上尝试请求-无论请求方法是否幂等"。Safari似乎不会用正确的SNI重试此TLS连接，而其他浏览器会。
我好奇的是这在跟踪中看起来如何。对于正在工作的其他浏览器，Dev Tools是否显示返回这个421，然后立即尝试再次检索资源?
https://www.rfc-editor.org/rfc/rfc7540 section-9.1.2
我对我们的前端应用程序有同样的问题。我在Azure存储上托管它与Azure CDN自定义域。对于去年创建的实例，一切都正常工作，但是我们面临二月份创建的实例的问题。我尝试使用由Azure管理的专用基于SNI的证书，但它不起作用。我想联系微软支持的唯一办法就是关闭这个功能
经过一些实验，我们找到了这个问题的不同解决方案-显然在HTML头中添加<preconnect>标签可以使Safari与每个源建立新的HTTPS连接。
虽然这不是一个完美的解决方案，但您可以在特定域中添加预连接提示，如果它们不是太多的话