为何Azure中部署的FCI SQL集群需指定端口才能连接？

嘿，这个问题我在帮客户部署Azure FCI时碰到过好多次了——这既不是SQL的默认设置锅，也不是集群的什么“固有机制”，核心原因是你的FCI虚拟网络名称（VNN）没正确注册默认端口的SPN，或者集群资源的端口配置没跟上。我给你拆解下原因和解决步骤：

当你用不带端口的方式连接SQL Server时，客户端默认会尝试用Kerberos认证，而Kerberos需要依赖**服务主体名称（SPN）**来定位服务。对于FCI来说，我们用的是虚拟网络名称（比如你的SQLCluster01）而非物理节点名称，这个虚拟名称的SPN如果没注册默认的1433端口，客户端就没法自动找到服务，只能靠指定端口强制用TCP连接。

另外还有一种可能：你的FCI集群资源里的SQL Server服务，没把默认端口设为1433，或者集群的网络名称资源没关联正确的端口配置。

1. 检查并注册VNN的SPN #

首先，用有域SPN注册权限的账号（比如域管理员）在域控制器上运行命令，查看当前SQL服务账号的SPN列表：

setspn -L <你的SQL服务域账号>

你需要确认输出里有没有这两个条目：

MSSQLSvc/SQLCluster01
MSSQLSvc/SQLCluster01:1433

如果没有，就手动注册：

setspn -A MSSQLSvc/SQLCluster01 <你的SQL服务域账号>
setspn -A MSSQLSvc/SQLCluster01:1433 <你的SQL服务域账号>

注意：这里的<你的SQL服务域账号>是运行SQL Server集群服务的那个域账号，SQLCluster01是你的FCI虚拟网络名称。

2. 验证集群资源的端口配置 #

打开故障转移集群管理器，找到你的FCI集群，展开角色选中SQL Server角色：

• 在右侧资源列表里找到SQL Server资源，右键选属性，切换到网络配置标签，确保TCP/IP协议的默认端口是1433且已启用。
• 再找到网络名称资源，检查它的DNS名称是否就是SQLCluster01，并且在DNS服务器上已经正确注册了A记录（可以用ping SQLCluster01测试解析是否正常）。

3. 验证客户端连接设置 #

在运维人员的客户端机器上：

• 打开SQL Server配置管理器，展开对应版本的SQL Server Native Client 配置，确认客户端协议里的TCP/IP已启用，且默认端口是1433。
• 可以用telnet SQLCluster01 1433测试端口连通性，确保没有防火墙或网络组策略拦截。

4. 重启集群SQL服务 #

做完以上配置后，在故障转移集群管理器里右键点击SQL Server角色，先停止再启动，让所有配置生效。

非集群的SQL Server实例用的是物理机器名称，安装时SQL Server会自动给物理机名称注册默认1433端口的SPN，不需要手动干预。但FCI的虚拟名称是集群创建的，有时候Azure环境里SQL服务账号的权限不足以自动注册SPN，就需要我们手动补做这一步。

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