.NET 5应用连接Azure SQL DB失败：WSL/容器环境异常排查

1. WSL环境被Azure SQL防火墙拦截的原因 #

• WSL2默认采用NAT网络模式，绝大多数场景下公网出口IP和Windows宿主一致，出现拦截可先分别在WSL终端和Windows CMD执行curl ifconfig.me确认出口IP是否相同，若不同通常是以下情况导致：
  • 宿主开启了VPN、代理类工具，WSL的路由规则未和宿主同步，流量走了独立的出口链路
  • WSL网络配置异常，触发了Windows的虚拟网卡出站规则拦截
• 即便IP相同也可能出现连接失败，常见根因：
  • WSL默认优先走IPv6协议栈，你当前的网络环境不支持IPv6访问Azure SQL服务，导致连接超时，可在WSL内执行telnet [你的SQL服务器地址].database.windows.net 1433验证端口连通性
  • WSL内置DNS解析异常，解析SQL服务器域名得到了错误的IP地址

你可以通过修改WSL的/etc/resolv.conf指定公共DNS（如8.8.8.8）、或者在连接字符串的服务器地址后加,1433显式指定端口、或者在WSL配置文件中禁用IPv6解决这类问题。

2. 容器化部署App Service连接失败的原因 #

你提到的源码部署正常、容器部署失败的场景，基本可以排除Azure SQL防火墙配置的问题，根因大多出在容器本身的配置上：

• 基础镜像缺少可信根证书：你的连接字符串中配置了Encrypt=True、TrustServerCertificate=False，需要客户端验证Azure SQL的SSL证书，如果使用的精简镜像（比如Alpine版.NET runtime镜像）默认没有预装ca-certificates包，会导致SSL握手失败，错误会被伪装成网络连接超时的报错
• 容器网络配置异常：如果容器部署时开启了VNet集成，而VNet的NSG规则、路由表没有放行到Azure SQL的1433端口出站流量，或者没有配置Azure SQL的服务端点/私有端点，流量就无法到达数据库，而源码部署未关联VNet时走默认公网出口就可以正常访问
• 连接字符串注入错误：容器部署时通常通过环境变量传递连接字符串，如果密码中包含;、@、$这类特殊字符，很容易在容器启动时出现转义错误，导致实际生效的连接字符串不完整，触发连接失败
• 容器DNS解析异常：App Service的容器运行环境偶尔会出现内部DNS无法正确解析Azure服务域名的问题，可在容器启动脚本中增加域名解析测试逻辑定位问题

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