我有一个由多个前端和后端应用程序以及多个数据库组成的项目；我正在构建部署管道。它应该使用 Azure 静态应用服务作为前端，使用 Azure 应用服务作为后端（.NET 6）和 Azure SQL 数据库。
到目前为止，一个 .NET6 后端应用程序已顺利连接到主数据库。另一个后端应用程序（Identity Server 6，部署在同一个 Linux App Service Plan 上）使用与工作应用程序相同的连接字符串和相同的配置（HTTP2、TLS 1.2 等），只是不想连接到数据库，并在启动时引发以下异常：
未处理的异常。Microsoft.Data.SqlClient.SqlException (0x80131904): 已成功与服务器建立连接，但在登录过程中发生错误。（提供程序：TCP 提供程序，错误：35 - 捕获到内部异常）
现在我当然已经阅读了有关该错误的 MS 文档，但是所有解决方案（例如 SQL Server 版本太旧而无法理解 TLS 版本）都不适用于 SaaS 产品，或者可能会因为在同一配置上运行的其他应用程序正在运行而被淘汰（例如 Linux 容器上的 .NET5 + 具有严格的密码集）。
我还尝试将双方都降级到最低 TLS，在连接字符串中将 TrustServerCertificate 设置为 True，甚至尝试将加密设置为 False（这在 Azure SQL 服务器上是不允许的，并且会以类似但更早的错误（登录前的错误）回答）。
由于应用程序具有相同的配置，并且 SQL Server 也相同，所以我猜问题只能出在应用程序本身上，但是所有相关功能难道不应该都来自 .NET6 框架吗？Microsoft.Data.SQLClient 是版本 4.1.0。
通过连接到 Azure SQL db 在本地部署应用程序确实有效。
我没主意了...你有什么想法？如果问题不在我预期的地方，那么什么假设可能是错误的？
答案1
经过两周的调试、与 4 位 Azure 支持人员的交谈以及招待两家公司的每一位云工程师，我们还是没有找到解决方案；应用程序在本地部署时可以运行，但一旦部署在 Azure Web 服务 Linux（= docker 容器）上，就无法连接到 SQL 数据库，无论是手动还是通过 CD 管道。
解决方法是在 Windows 应用服务上运行它，这样不会出现问题。基于 Windows 的容器更昂贵，应该没有必要。但我们还是这么做了。