使用通配符路由时偶尔会收到来自 Azure Front Door 的 421 响应代码

Question

我们使用 Azure Front Door 来服务我们的白标静态网站，这意味着我们需要我们的客户能够通过独特的子域（例如，

cust1.domain.com

和

cust2.domain.com

）访问它。

我们通过 DNS 将

*.domain.com

CNAME 到我们的 Front Door 实例，映射

*.domain.com

的路由并将其绑定到自定义

*.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-前置--行为--

设置此流程以避免 Front Door 出现此新问题的正确方法是什么？据我所知，我们的案例有些独特，并且没有记录。

我见过的解决方案包括关闭 HTTP/2、为每个域创建单独的证书以及使用不同的 IP，这些解决方案都无效，也不会随着我们的解决方案进行扩展，因为我们需要不受限制地动态创建新的子域（即，以编程方式将它们添加到 AFD 是不现实的）。

Answer 1

我最终通过联系 Microsoft 支持并要求他们关闭域前置阻止来解决此问题，根据我们的后续测试，这似乎已经完全解决了 Safari 上的问题。希望有更好的解决方案，但这目前对我们有用。

Answer 2

有趣的是，AFD 是反向代理，而 RFC 7540 9.1.2。状态代理不应生成此响应。 MS 自 11 月起禁止域名前置，据我所知，自去年 4 月起，微软就已发出警告，让用户远离它。

从其他研究来看，Safari 无法正确处理此问题的原因是上面引用的同一 RFC 部分表示客户端“可以通过不同的连接尝试该请求 - 无论请求方法是否幂等。 ” Safari 似乎不会使用正确的 SNI 重试此 TLS 连接，而其他浏览器则会。

我很好奇的是这看起来是怎样的。 对于其他正在运行的浏览器，开发工具是否显示返回 421，然后立即尝试再次检索资源？

https://www.rfc-editor.org/rfc/rfc7540#section-9.1.2

Answer 3

我的前端应用程序也有同样的问题。我将其托管在 Azure 存储上，并使用用于自定义域的 Azure CDN。对于去年创建的实例，一切正常，但我们面临着二月份创建的实例的问题。 我尝试使用由 Azure 管理的基于 SNI 的专用证书，但没有成功。 我认为联系 Microsoft 支持的唯一解决方案就是关闭该功能

Answer 4

经过一些实验，我们找到了解决此问题的不同解决方案 - 显然在 HTML 标头中添加

<preconnect>

标签使 Safari 与每个源建立新的 HTTPS 连接。

虽然这不是一个完美的解决方案，但您可以向特定域添加预连接提示（如果域数量不是太多）

Answer 5

今天的情况是 MS 拒绝了禁用域前置块“功能”的请求。在我们的案例中，这个问题主要影响 Safari 用户（但不仅仅是）。幸运的是，使用 CDN 托管证书添加自定义域解决了我们的问题。

我们现在的配置是：

• 网站：app.ourdomain.com（CF中的一条记录）
• CDN：cdn.ourdomain.com（CF 中的 CNAME 记录指向 Azure CDN (.azureedge.net)）