部署在Linux应用服务计划的Azure Web App连接SQL Server 2016报错求助

核心差异原因 #

Windows和Linux环境下的.NET应用在TLS/SSL握手环节依赖不同的底层实现：

• Windows平台使用系统自带的Schannel组件处理加密通信
• Linux平台则依赖OpenSSL库
  两者对TLS协议版本、加密套件（Cipher Suite）的支持范围和默认行为存在差异，这是导致仅Linux环境出现握手失败的核心原因。

具体排查方向 #

1. 核对TLS加密套件兼容性 #

• 查看本地SQL Server支持的加密套件：在SQL Server所在服务器执行PowerShell命令Get-TlsCipherSuite | Where-Object { $_.Protocol -eq 'Tls12' }，记录所有启用的套件
• 在Linux Azure Web App的Kudu控制台（https://<app-name>.scm.azurewebsites.net）执行openssl ciphers -v | grep TLSv1.2，对比两者的交集，确保SQL Server至少启用一个Linux OpenSSL支持的套件
• 如果没有交集，调整SQL Server的加密套件配置（通过组策略或注册表），添加Linux支持的套件

2. 强制指定TLS版本 #

在连接字符串中明确添加TlsVersion=Tls12参数，避免Linux端默认尝试SQL Server不支持的TLS版本（比如TLS 1.3）：

Server=<ip>;Database=<db>;User Id=<user>;Password=<pwd>;Encrypt=False;TrustServerCertificate=True;TlsVersion=Tls12

3. 检查OpenSSL版本与驱动兼容性 #

• 在Kudu控制台执行openssl version，确认OpenSSL版本（部分旧版Linux镜像可能自带较老的OpenSSL，对部分加密套件支持不足）
• 确保项目中使用的Microsoft.Data.SqlClient NuGet包版本在Windows和Linux环境一致，优先使用最新稳定版（跨平台兼容性更好）

4. 验证证书信任逻辑 #

• 即使设置了TrustServerCertificate=True，Linux的OpenSSL可能仍对证书链有额外校验：尝试将SQL Server的SSL证书导入到Linux应用的信任存储中（可通过Azure App Service的「自定义证书」功能上传，或在应用启动脚本中添加证书信任命令）
• 若SQL Server未配置SSL证书，确认Linux端驱动是否会因为无证书而触发握手失败（Windows的Schannel在无证书时的降级逻辑更宽松）

5. 抓包分析握手细节 #

在Linux Web App中启用网络抓包：

• 通过Kudu控制台安装tcpdump（apt-get install tcpdump），执行tcpdump -i any host <sql-server-ip> and port 1433 -w handshake.pcap
• 下载抓包文件后用Wireshark分析，查看握手过程中双方协商的TLS版本、加密套件，定位失败的具体环节（比如套件协商失败、证书验证失败）

内容的提问来源于stack exchange，提问作者BryceBy