我们使用 Azure Front Door 为我们的白标静态网站提供服务，这意味着我们需要我们的客户能够通过独特的子域（例如cust1.domain.com和cust2.domain.com）访问它。
我们*.domain.com通过 DNS 对 Front Door 实例进行 CNAME，映射路由*.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-fronting - 行为 -
设置此流程以避免 Front Door 出现此新问题的正确方法是什么？据我所知，我们的案例有些独特，并且没有记录。
我见过的解决方案包括关闭 HTTP/2、为每个域创建单独的证书以及使用不同的 IP - 这些解决方案都无效，也不会随我们的解决方案扩展，因为我们需要不受限制地动态创建新的子域（即，以编程方式将它们添加到 AFD 是不现实的）。
wildcard-subdomain azure http-status-code-421 azure-front-door azure-static-website-hosting
我正在阅读规范并试图准确了解 421 何时可能返回。给出了一个例子，但我不完全理解它。
背景
该规范建立了两个允许连接重用的条件：
对于没有 TLS 的 TCP 连接，这取决于解析为相同 IP 地址的主机。
和
对于 https 资源，连接重用还取决于是否拥有对 URI 中的主机有效的证书。
如果连接中使用的证书有多个subjectAltName或其中任何一个subjectAltName是通配符，则该连接可以重新用于主机名位于 s 列表中subjectAltName或与任何通配符匹配的任何请求。
规范中的具体示例
在某些部署中，重复使用多个源的连接可能会导致请求被定向到错误的源服务器。例如，TLS 终止可能由使用 TLS 服务器名称指示 (SNI) [TLS-EXT] 扩展来选择源服务器的中间件执行。这意味着客户端有可能将机密信息发送到可能不是请求的预期目标的服务器，即使该服务器在其他方面具有权威性。
请解释一下我对这个例子的理解哪里错误：
使用具有域的请求建立到中间件的 https 连接x.com。中间盒的 IP 地址为 1.2.3.4，并x.com解析为该地址。使用 SNI，TLS 握手会x.com返回一个对该域有效的证书。此连接上的所有消息都从客户端发送到中间件或从中间件发送到客户端。从客户端到中间件的应用程序级消息由中间件转发到不同连接上的源。从源到中间盒的消息被转发到客户端。如果要重用连接，满足上面讨论的两个条件是不够的。具体来说，对于域为 的请求y.com：如果y.com解析为 1.2.3.4 并且中间件具有对 有效的证书y.com，则仍然可能存在问题。因为原始连接使用 TLS 握手x.com，并且握手仅在新连接开始时完成，所以无法建立 https 连接来获取y.com. 因此客户端错误地在同一连接上向 发送请求y.com。中间件拒绝请求，因为与连接关联的证书的有效期为x.com- not y.com …