Web App通过VNet连接SQL Server报错，请求排查配置遗漏

以下是针对你遇到的套接字访问权限错误的具体配置排查项：

• 检查SQL Server专用终结点状态与DNS解析

  • 确认SQL Server的专用终结点处于已批准状态，无未审批/拒绝状态
  • 在Web App的Kudu控制台执行nslookup <SQL专用终结点FQDN>，验证是否返回subnet2内的专用IP地址，若解析失败或返回公共IP，说明DNS配置存在问题
  • 确保SQL Server的公共网络访问设置为「禁用」或「仅允许专用终结点」，避免DNS解析出现混淆

• 验证子网NSG规则配置

  • 检查subnet1的出站NSG规则：需明确允许到subnet2的TCP 1433端口（或自定义SQL端口）的流量，排查是否存在高优先级的拒绝规则拦截了该流量
  • 检查subnet2的入站NSG规则：需允许来自subnet1的TCP 1433端口流量，专用终结点的入站访问依赖此规则
  • 注意：NSG规则的拒绝优先级高于允许，需确保没有全局拒绝出站/入站的规则覆盖了专用访问的允许规则

• 确认Web App VNet集成的有效性

  • 检查Web App使用的是区域VNet集成（而非网关集成），网关集成可能存在路由限制导致无法访问专用终结点
  • 验证Web App的VNet集成已正确关联到vnet1/subnet1，无配置断开或异常状态
  • 由于多个Web App共享同一子网，检查subnet1的IP地址是否已耗尽：每个Web App的VNet集成会占用子网内的IP资源，IP耗尽会导致网络连接异常

• 检查SQL Server连接策略与配置

  • 确认连接字符串使用的是SQL Server的专用终结点FQDN（格式为<sql-server-name>.privatelink.database.windows.net），而非公共FQDN
  • 验证SQL Server实例已启用TCP/IP协议，且监听端口与连接字符串中的端口一致
  • 若之前启用了「允许Azure服务和资源访问此服务器」选项，现在需确认该选项是否与专用终结点配置冲突（建议仅保留专用终结点访问时关闭此选项）

• 排查用户定义路由表(UDR)

  • 检查subnet1关联的UDR：确保没有路由规则将到SQL专用IP的流量导向VPN网关、防火墙等外部设备，应保留VNet内的直接路由
  • 检查subnet2关联的UDR：确保允许来自subnet1的流量直接到达专用终结点，无强制路由拦截

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