一致的 SQL Server 网络连接问题

注意

在开始故障排除之前，我们建议查看先决条件并核对清单。

本文可帮助排查 SQL Server 中的网络连接错误。 这些错误每次都一致且可重复。 它们指向某些配置问题，例如 SQL Server 未启用 TCP 或阻止连接的防火墙。 故障排除侧重于远程 TCP 连接，因为它是大多数数据中心中最常见的连接类型，但许多技术也可以应用于命名管道。

典型的错误消息

最常见的错误消息包括：

• 通信链接失败。

• 常规网络错误。

• 指定的网络名称无法访问。

• SQL Server 不存在或访问被拒绝。 （也可能是身份验证错误）

• 建立到 SQL Server 的连接时出现与网络相关或特定于实例的错误。 找不到或无法访问服务器。 请验证实例名称是否正确，SQL Server 是否已配置为允许远程连接。

• 查找指定的服务器/实例时出错。

• 无法打开与 SQL Server Microsoft SQL Server 的连接，错误：53。 找不到网络路径。

• 无法建立连接，因为目标计算机主动拒绝连接。

将问题的范围缩小到重点区域

以下步骤有助于将故障排除范围缩小到重点区域：

• 客户端：应用程序、连接字符串、驱动程序（缺少传输层安全性（TLS）1.2）、SQL 别名（64/32 位）、主机文件和不正确的域名系统（DNS）后缀（全名连接;短名称失败）。
• SQL Server：数据库引擎、已启用的协议和防火墙。
• 网络：DNS 别名、网关、路由器和防火墙。

1.是否可以使用 SQL Server Management Studio （SSMS） 和 TCP 在本地连接到 SQL Server？

例如，使用以下格式的连接字符串，tcp:<ServerName>.<DomainName>.COM,1433例如tcp:sqlprod01.contoso.com,1433。

注意

tcp 在服务器名称之前添加的必须是小写。

如果是，则 SQL Server 运行良好。 此问题与 防火墙、 网络或 客户端相关。

否则，此问题与 SQL Server 服务相关。

2.是否可以使用 telnet 从客户端计算机连接到 SQL Server 端口？

例如，用于建立 与 SQL Server 实例的 telnet 连接的命令为 telnet <ServerName>.<DomainName>.COM 1433。

如果是，则此问题与 驱动程序/提供程序、安全/安全套接字层（SSL）、SQL 别名或 应用程序相关。

如果没有，则问题与步骤 1 正常工作时主机文件、网络或防火墙相关。

• 如果 telnet 作为命令不可用，请将其添加为 Windows 功能。 这不需要重新启动。

• 较新版本的 Windows 具有 Test-NetConnection PowerShell 命令。

  例如，使用命令 Test-NetConnection <ServerName>.<DomainName>.com -Port 1433 测试与 SQL Server 实例的网络连接。

3.如果步骤 2 正常工作，是否可以使用 UDL 文件连接到服务器？

如果是，则问题与应用程序相关，例如错误的连接字符串，或者应用程序使用的提供程序与通用数据链接（UDL）文件中使用的提供程序不同。

否则，此问题与 客户端相关。

4.其他客户端是否可以连接到 SQL Server？

如果是，则此问题与 防火墙、 网络、TLS 1.2 或 客户端相关。

否则，问题与 防火墙 或 服务器相关。

5.客户端是否可以连接到其他服务器？

如果是，则此问题与 防火墙、 网络、TLS 1.2 或 服务器相关。

否则，与防火墙、网络或 TLS 1.2 相关的问题。

SQL Server 服务

如果问题与 SQL Server 服务相关，请执行以下步骤：

1. 验证服务进程（sqlserver.exe）是否在任务管理器中运行。 （或者，如果安装了多个实例，请通过 SQL Server 配置管理器 或服务.msc 进行检查。

   如果它未运行，请尝试启动实例。 如果是镜像或群集配置，请确保位于主节点或活动节点上。 使用群集管理器进行故障转移或始终位于群集上，以确保资源处于联机状态。

2. 验证应用程序事件日志、群集日志还是 SQL Server ERRORLOG 文件指示可操作的致命错误。

3. 验证SQL Server 配置管理器和 SQL Server ERRORLOG 文件中是否启用了预期的协议（请参阅以下示例）。

   否则，请启用它们并重启 SQL Server。 如果允许远程连接，应始终启用 TCP。

   2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv6> 1433].
   2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv4> 1433].
   2013-11-20 09:42:03.94 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\KJ].
   2013-11-20 09:42:03.94 Server Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$KJ\sql\query].
   

4. 在 SSMS、UDL 或 ODBC 数据源管理员连接中，通过以以下格式指定服务器名称来绕过 SQL Server 浏览器。 tcp:<ServerName>.<DomainName>.com,1433

   注意

   使用完全限定的域名（FQDN）， tcp:创建连接的端口号是最可靠且可复原的方法。 tcp: 必须为小写。

   • 如果连接成功：

     • 验证 SQL Server Browser 是否正在运行。 如果 SQL Server 是侦听端口 1433 的默认实例，则无需运行。 可以删除端口号并使其仍然有效。
     • 如果删除 tcp: 前缀会导致其失败，则默认情况下可以通过命名管道进行连接。 可以使用服务器名称进行验证 np:hostname\<ServerName> 。
     • 如果使用 NetBIOS 名称失败，则可能具有替代 NetBIOS 名称的 SQL 别名或网络配置中不正确的 DNS 后缀。 此外，请检查 32 位别名。

   • 如果 SSMS 无法连接，请尝试使用 UDL 文件或通过 ODBC 数据源管理员进行连接。

     • 请尝试使用服务器的 IP 地址，而不是主机名。 如果服务器未群集且正在侦听“任何”，甚至可以尝试使用 127.0.0.1。
     • 请尝试不同的驱动程序。 较新的驱动程序支持 TLS 1.2 并提供更好的错误消息。
     • 尝试不同的协议： tcp:<ServerName>.<DomainName>.com,1433、 np:<ServerName>.<DomainName>.com\<InstanceName>或 lpc:<ServerName>.<DomainName>.com\<InstanceName>。 使用SQL Server 配置管理器进行更改。 然后，重启 SQL Server 并使用 ERORLOG 文件确认更改。
     • SQL Server （2014 或更早版本）是否已升级以支持 TLS 1.2？ 是否已升级客户端以支持 TLS 1.2？ 这些协议是否已启用？
     • 在所有 Windows 计算机上检查SQL Server 配置管理器或cliconfg.exe中的 SQL 别名。 检查 64 位和 32 位别名。
     • 检查 ERRORLOG 文件是否存在失败消息，例如数据库不可用或恢复。
     • NETSTAT检查输出以验证 SQL Server 是否拥有预期的端口。 例如，使用管理员权限从命令提示符运行 NETSTAT -abon > c:\temp\ports.txt 。

   • 如果 SQL Server 使用的是 1433 以外的端口：

     • 如果可以通过指定端口号而不是省略端口号进行连接，则这是 SQL Server Browser 问题。 这意味着 SQL Browser 服务无法为要连接到的 SQL Server 实例提供正确的端口号。 可能还需要重启 SQL Browser 服务以刷新其信息。

     • 如果即使指定端口号，也无法连接，并且仅在远程连接时发生，则这是防火墙问题。 应检查防火墙设置，并确保允许端口进行入站和出站连接。 可能还需要创建防火墙规则，以允许 SQL Server 应用程序或服务通过防火墙进行通信。

     • 如果使用 Always On，则连接到侦听器不使用 SQL Server Browser，因此必须在连接字符串中指定端口号。 如果不起作用，请尝试在其常规 SQL 端口上直接连接到主节点。 如果有效，问题与侦听器相关。

如果上述方法都不起作用，请重启 SQL Server 计算机。

最糟糕的情况是停止 SQL Server 服务、安装新实例或可能重新生成计算机，然后重新附加数据库或从备份还原。 如果使用透明数据加密（TDE），例如 SSISDB 数据库，请确保在执行此步骤之前保存加密密钥。 它作为一个选项提供，因为重新生成有时可能比对棘手问题进行根本原因分析更快。 对于群集安装，影响可能更少，因为可以在备用节点上运行时重新生成节点。

防火墙

通常，防火墙的默认行为是阻止 SQL Server 和 SQL Server 浏览器端口。 如果是，远程连接会失败，而本地连接成功。 使用 Test-NetConnection. 它在所有受支持的 Windows 版本上都可用。

Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433

请确保检查 ERRORLOG 文件中侦听的端口 SQL Server。 可能需要通过将它添加为 Windows 功能来启用 telnet 它。 这不需要重新启动。 SQL Server 还必须侦听 TCP。 PortQry 可以从Microsoft下载站点下载。 如果使用 SQL Server 浏览器，请确保在防火墙和 SQL Server TCP 端口中打开 UDP 端口 1434。

网络

客户端或应用程序服务器可以连接到其他计算机上的 SQL Server。 特定网络或子网上的多个客户端在连接到子网外部或另一个特定子网中的服务器时遇到问题。 网络防火墙可能会阻止特定客户端连接到特定的 SQL Server。 例如，客户端可以连接到其他 SQL Server，其他客户端可以连接到问题 SQL Server。

VPN

如果问题仅在虚拟专用网络（VPN）上发生，而不是在将笔记本电脑引入内部时发生，则 VPN 供应商需要解决此问题。 可以获取客户端和服务器网络跟踪，这有助于显示 VPN 导致的问题类型。 例如，丢弃的数据包是最有可能的数据包。 VPN 还可以更改客户端和服务器之间的内部路由，将其公开给阻止连接的另一个网络设备。 在中间设备上收集网络跟踪有助于通过细分网络来隔离问题。 tracert 命令可能会显示路由。

客户端

如果问题与客户端相关，你可能会看到以下指示器：

• 其他客户端通常可以连接到服务器。

• 任何应用程序都无法从此计算机进行连接。

• 无法使用 UDL 或 ODBC 数据源管理员进行连接。

  这可能是由出站防火墙规则或不正确的默认 DNS 后缀引起的。 尝试使用完全限定的服务器名称进行测试，例如：

  Test-NetConnection <ServerName> -Port 1433   
  Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
  

  这可能是 TLS 问题。 例如，服务器使用 TLS 1.2，并且尚未升级客户端驱动程序。

  可能有主机文件条目、SQL 别名或 DNS 别名将连接定向到另一台服务器。 使用 ping 和 telnet。 如果它们正常工作，但驱动程序失败，则怀疑 SQL 别名或 TLS 问题。

驱动程序

如果问题与驱动程序相关，请尝试不同的驱动程序。

• 如果某些驱动程序工作和其他驱动程序失败，请怀疑存在 TLS 问题。 下载最新的驱动程序，例如 Microsoft OLE DB Driver for SQL Server 或 ODBC Driver 17 for SQL Server，然后尝试。

• 如果使用 .NET，请确保使用的是最新版本的框架。 如果仍然失败，它应提供更好的错误消息。 还可以下载独立于 SQL Server 的最新版本的 SQL Server Management Studio ，并将其安装在任何客户端上。 这使用 SqlClient .NET 类。

用户

如果问题与用户相关，请让其他用户登录到此计算机。

• 如果连接成功，请参阅失败用户的不同内容。 例如，Windows 用户配置文件已损坏，或者用户可能属于其他组织单位（OU）或域。

• 如果有来自多个域的用户，请尝试使用与服务器相同的域中的用户。 通常，用户问题会导致身份验证错误，并具有不同的故障排除工作流。

• 如果不是身份验证问题，进程监视器日志可能有助于识别影响连接的本地权限问题。 例如，用户具有数据源名称（DSN）或某种注册表重定向到其他驱动程序、本地权限限制或可能解释连接失败的内容。

应用程序

如果仅特定应用程序失败并且 UDL 文件成功，则可能是驱动程序问题，或者应用程序连接字符串不正确。 让应用程序开发团队或第三方供应商检查连接字符串。 可以使用进程资源管理器 www.sysinternals.com 查看客户不确定时正在使用的驱动程序。

要捕获的跟踪工具

捕获客户端和服务器网络跟踪。 同时在客户端和服务器上运行 SQL 跟踪。

使用 NCAP 驱动程序安装 WireShark ，以跟踪客户端和服务器在同一台计算机上时。

你的组织可能有自己的网络基础结构团队，你可以与之互动，并且可能具有执行捕获的首选跟踪工具。 只要它以与 网络监视器（NetMon.exe） 或 WireShark 兼容的格式保存，它们就可以使用任何工具。 PCAP 格式是最受欢迎的。

针对网络跟踪运行 SQL 网络分析器（SQLNA） 和 SQL 网络分析器 UI（SQLNAUI）， 以获取易于阅读的报告。

详细信息

• 一致身份验证问题的原因
• 跟踪驱动程序操作

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。