无法通过专用终结点连接Azure Function与Azure SQL的排查求助

数据老陈

2026-5-8

我来帮你一步步排查这个问题，先从你提到的子网委派疑问开始，再逐个分析连接失败的可能原因：

一、先解释「子网委派给服务器场」的含义

你遇到的子网无法创建VM的情况是正常的，子网委派是Azure的一种资源隔离机制：它指定这个子网只能被特定的Azure服务（这里是App Service的服务器场）独占使用，目的是让服务能在子网内部署专属的网络组件（比如负载均衡器、专用网络接口），确保服务的网络逻辑独立且符合Azure的服务架构要求。一旦子网被委派给某个服务，就无法再用于部署VM、虚拟机规模集这类不兼容的资源，这是设计预期的行为。

二、排查专用链接连接失败的核心问题

从你的报错信息来看，问题主要集中在DNS解析、身份验证或网络路由环节，按优先级排查如下：

1. 确认专用DNS区域的配置与VNet关联

专用链接的核心依赖是专用DNS区域来让VNet内的服务解析到SQL Server的专用IP，你需要检查：

是否为SQL Server创建了对应的专用DNS区域（通常名称是 privatelink.database.windows.net）
这个DNS区域是否已经关联到你的TESTVNET：如果没有关联，VNet集成的Function会走公网DNS解析，自然拿不到10.1.1.4这个专用IP，导致要么访问公网被拒绝，要么手动指定IP时触发身份验证问题。

2. 验证Function的DNS解析结果

你可以在Function中添加一段测试代码，直接验证SQL Server FQDN的解析结果（以Node.js为例，因为你用了Sequelize）：

const dns = require('dns');
module.exports = async function (context, req) {
    dns.resolve4('你的SQL服务器FQDN.database.windows.net', (err, addresses) => {
        if (err) context.log.error(err);
        context.log('解析到的IP地址:', addresses);
        context.res = { body: `解析结果: ${addresses.join(', ')}` };
    });
};

如果解析结果不是10.1.1.4，说明DNS配置有问题，需要重新检查专用DNS区域的VNet关联。

3. 不要手动指定专用IP连接SQL Server

你尝试用10.1.1.4直接连接时报登录失败，很大概率是因为SQL Server的身份验证依赖FQDN：

SQL Server的SSL证书是绑定到它的公网FQDN的，直接用IP连接会触发证书验证失败，进而导致登录被拒绝
正确的做法是使用SQL Server的原始FQDN（比如xxx.database.windows.net），让专用DNS自动解析到专用IP

4. 检查SQL Server的登录权限配置

即使网络通了，登录失败也可能是权限问题：

如果用SQL身份验证，确认你的登录名允许从SUBNET2（10.1.2.0/24）的IP范围连接，或者登录名的权限设置为允许所有位置（测试阶段可以先放开，再收紧）
如果用Azure AD身份验证，确认Function的托管标识（若启用）已经被授予SQL Server的访问权限，且连接字符串正确配置了AD身份验证参数

5. 确认VNet集成的路由与NSG规则

你已经设置了WEBSITE_VNET_ROUTE_ALL=1，这个配置是对的，但要确认Function用的是区域VNet集成（不是网关集成），网关集成可能会有额外的路由限制
检查NSG的出站规则：默认的AllowVnetOutBound规则应该允许SUBNET2到SUBNET1的流量，但可以临时添加一条优先级更高的规则，明确允许10.1.2.0/24到10.1.1.4:1433的流量，测试是否能连通

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