Problemas coherentes de conectividad de red de SQL Server

2025-02-12

Nota:

Antes de empezar a solucionar problemas, se recomienda comprobar los requisitos previos y seguir la lista de comprobación.

Este artículo ayuda a solucionar errores de conectividad de red en SQL Server. Estos errores son coherentes y repetibles cada vez. Apuntan a algunos problemas de configuración, como SQL Server que no habilitan TCP o un firewall que bloquea la conexión. La solución de problemas se centra en las conexiones TCP remotas porque es el tipo de conexión más común en la mayoría de los centros de datos, pero muchas de las técnicas también se pueden aplicar a canalizaciones con nombre.

Mensajes de error típicos

Los mensajes de error más comunes son:

Error de vínculo de comunicación.
Error general de red.
El nombre de red especificado no es accesible.
SQL Server no existe ni se deniega el acceso. (Esto también puede ser un error de autenticación)
Error relacionado con la red o específico de la instancia mientras se establecía una conexión con el servidor SQL Server. No se encontró el servidor o no era accesible. Compruebe que el nombre de la instancia es correcto y que SQL Server está configurado para admitir conexiones remotas.
Error al localizar el servidor o la instancia especificados.
No se pudo abrir una conexión a SQL Server Microsoft SQL Server, Error:53. No se ha encontrado la ruta de acceso de la red.
No se pudo establecer ninguna conexión porque la máquina de destino la rechazó activamente.

Restringir el ámbito del problema a un área centrada

Los pasos siguientes ayudan a restringir la solución de problemas a un área centrada:

Cliente: aplicación, cadena de conexión, controlador (falta seguridad de la capa de transporte (TLS) 1.2), alias SQL (64/32 bits), archivo de hosts e sufijo incorrecto del sistema de nombres de dominio (DNS) (nombre completo se conecta; se produce un error en el nombre corto).
SQL Server: motor de base de datos, protocolos habilitados y firewall.
Red: alias DNS, puerta de enlace, enrutador y firewall.

1. ¿Puede conectarse a SQL Server localmente mediante SQL Server Management Studio (SSMS) y TCP?

Por ejemplo, use el cadena de conexión en este formato: tcp:<ServerName>.<DomainName>.COM,1433, como tcp:sqlprod01.contoso.com,1433.

Nota:

tcp se ha agregado antes de que el nombre del servidor tenga que estar en minúsculas.

Si es así, SQL Server funciona bien. El problema está relacionado con el firewall, la red o el cliente.

Si no es así, el problema está relacionado con el servicio SQL Server.

2. ¿Puede conectarse al puerto de SQL Server desde la máquina cliente mediante telnet?

Por ejemplo, el comando para establecer una conexión telnet a la instancia de SQL Server es telnet <ServerName>.<DomainName>.COM 1433.

Si es así, el problema está relacionado con controladores o proveedores, security/Secure Sockets Layer (SSL), alias SQL o aplicaciones.

Si no es así, el problema está relacionado con el archivo de hosts, la red o el firewall cuando funciona el paso 1 .

Si telnet no está disponible como comando, agréguelo como una característica de Windows. Esto no requiere un reinicio.
Las versiones más recientes de Windows tienen el comando Test-NetConnection de PowerShell.

Por ejemplo, use el comando Test-NetConnection <ServerName>.<DomainName>.com -Port 1433 para probar la conexión de red a una instancia de SQL Server.

3. ¿Puede conectarse al servidor mediante un archivo UDL si funciona el paso 2?

Si es así, el problema está relacionado con las aplicaciones, como una cadena de conexión incorrecta, o el proveedor utilizado por la aplicación si es diferente del proveedor usado en el archivo De vínculo de datos universal (UDL).

Si no es así, el problema está relacionado con los clientes.

4. ¿Pueden conectarse otros clientes a SQL Server?

Si es así, el problema está relacionado con el firewall, la red, TLS 1.2 o el cliente.

Si no es así, el problema está relacionado con el firewall o el servidor.

5. ¿El cliente puede conectarse a otros servidores?

Si es así, el problema está relacionado con el firewall, la red, TLS 1.2 o el servidor.

Si no es así, el problema relacionado con el firewall, la red o TLS 1.2.

Servicio de SQL Server

Si el problema está relacionado con el servicio SQL Server, siga estos pasos:

Valide que el proceso de servicio (sqlserver.exe) se ejecute en el Administrador de tareas. (O compruebe a través de Administrador de configuración de SQL Server o services.msc si tiene varias instancias instaladas).

Si no se está ejecutando, intente iniciar la instancia. Si se trata de una configuración reflejada o en clúster, asegúrese de que está en el nodo principal o activo. Use el administrador de clústeres para la conmutación por error o los clústeres always on para asegurarse de que los recursos están en línea.
Valide si el registro de eventos de la aplicación, los registros de clúster o el archivo ERRORLOG de SQL Server indican un error irrecuperable.

Valide que los protocolos esperados están habilitados en Administrador de configuración de SQL Server y en el archivo ERRORLOG de SQL Server (consulte el ejemplo siguiente).

Si no es así, habilite y reinicie SQL Server. TCP siempre debe estar habilitado si se permiten conexiones remotas.

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].

En una conexión de administrador de orígenes de datos DE SSMS, UDL o ODBC, omita SQL Server Browser especificando el nombre del servidor con el formato : tcp:<ServerName>.<DomainName>.com,1433.

Nota:

El uso del nombre de dominio completo (FQDN), tcp:y el número de puerto para crear una conexión es el método más confiable y resistente. tcp: debe estar en minúsculas.
- Si la conexión se realiza correctamente:
  - Valide que SQL Server Browser se está ejecutando. Si SQL Server es una instancia predeterminada que escucha en el puerto 1433, no tiene que ejecutarse. Puede quitar el número de puerto y hacer que siga funcionando.
  - Si quitar el tcp: prefijo hace que se produzca un error, es posible que se conecte a través de canalizaciones con nombre de forma predeterminada. Puede validar mediante np:hostname\<ServerName> como nombre del servidor.
  - Si se produce un error en el uso del nombre NetBIOS, es posible que tenga un alias SQL que invalide el nombre netBIOS o un sufijo DNS incorrecto en la configuración de red. Además, compruebe los alias de 32 bits.
- Si SSMS no se puede conectar, intente conectarse con un archivo UDL o a través del administrador del origen de datos ODBC.
  - Pruebe a usar la dirección IP del servidor en lugar del nombre de host. Incluso puede intentar usar 127.0.0.1 si el servidor no está agrupado y está escuchando en "any".
  - Pruebe diferentes controladores. Los controladores más recientes admiten TLS 1.2 y proporcionan mejores mensajes de error.
  - Pruebe distintos protocolos: tcp:<ServerName>.<DomainName>.com,1433, np:<ServerName>.<DomainName>.com\<InstanceName>o lpc:<ServerName>.<DomainName>.com\<InstanceName>. Use el Administrador de configuración de SQL Server para realizar cambios. A continuación, reinicie SQL Server y use el archivo ERORLOG para confirmar los cambios.
  - ¿Se ha actualizado SQL Server (2014 o versiones anteriores) para admitir TLS 1.2? ¿Se ha actualizado el cliente para admitir TLS 1.2? ¿Están habilitados estos protocolos?
  - Busque un alias SQL en Administrador de configuración de SQL Server o cliconfg.exe en todas las máquinas Windows. Compruebe alias de 64 y 32 bits.
  - Compruebe el archivo ERRORLOG para ver los mensajes de error, como la base de datos que no está disponible o en recuperación.
  - Compruebe la NETSTAT salida para validar si SQL Server posee el puerto esperado. Por ejemplo, ejecute NETSTAT -abon > c:\temp\ports.txt desde un símbolo del sistema con permisos de administrador.
- Si SQL Server usa un puerto distinto de 1433:
  - Si puede conectarse especificando el número de puerto, pero no cuando se omite el número de puerto, se trata de un problema de SQL Server Browser. Significa que el servicio SQL Browser no puede proporcionar el número de puerto correcto para la instancia de SQL Server a la que desea conectarse. Es posible que también tenga que reiniciar el servicio SQL Browser para actualizar su información.
  - Si no se puede conectar aunque especifique el número de puerto y esto solo se produce cuando se conecta de forma remota, se trata de un problema de firewall. Debe comprobar la configuración del firewall y asegurarse de que el puerto está permitido para las conexiones entrantes y salientes. También puede que tenga que crear una regla de firewall para permitir que la aplicación o el servicio de SQL Server se comuniquen a través del firewall.
  - Si usa AlwaysOn, la conexión al agente de escucha no usa SQL Server Browser, por lo que debe especificar el número de puerto en el cadena de conexión. Si esto no funciona, intente conectarse directamente al nodo principal en su puerto SQL normal. Si funciona, el problema está relacionado con el agente de escucha.

Si ninguno de los métodos anteriores funciona, reinicie el equipo con SQL Server.

El peor escenario es detener el servicio SQL Server, instalar una nueva instancia o volver a generar la máquina y, a continuación, volver a adjuntar la base de datos o restaurarla desde la copia de seguridad. Si usa el cifrado de datos transparente (TDE), como la base de datos de SSISDB , asegúrese de que las claves de cifrado se guardan antes de realizar este paso. Se ofrece como opción, ya que la regeneración a veces puede ser más rápida que un análisis de causa principal de problemas intractables. En el caso de las instalaciones en clúster, el impacto puede ser menor, ya que puede volver a generar un nodo mientras se ejecuta en el nodo alternativo.

Firewall

En general, el comportamiento predeterminado del firewall es bloquear los puertos de SQL Server y SQL Server Browser. Si es así, se produce un error en las conexiones remotas, mientras que las locales se realizan correctamente. Pruóbelo mediante Test-NetConnection. Está disponible en todas las versiones compatibles de Windows.

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

Asegúrese de comprobar en qué puerto está escuchando SQL Server en el archivo ERRORLOG . Es posible que tenga que habilitarlo telnet agregándolo como una característica de Windows. Esto no requiere un reinicio. SQL Server también debe escuchar en TCP. PortQry se puede descargar desde el sitio de descarga de Microsoft. Si usa SQL Server Browser, asegúrese de que el puerto UDP 1434 está abierto en el firewall y en el puerto TCP de SQL Server.

Red

El cliente o el servidor de aplicaciones pueden conectarse a SQL Server en otra máquina. Quizás varios clientes de una red o subred determinada tengan problemas para conectarse a un servidor fuera de la subred o en otra subred específica. Un firewall de red podría impedir que un cliente específico se conecte a un servidor SQL Server específico. Por ejemplo, el cliente puede conectarse a otros servidores SQL Server y otros clientes pueden conectarse al problema con SQL Server.

VPN

Si el problema solo se produce en una red privada virtual (VPN) y no cuando el portátil se incluye internamente, el proveedor de VPN debe resolver el problema. Puede obtener un seguimiento de red de cliente y servidor, lo que puede ayudar a mostrar el tipo de problemas que está causando la VPN. Por ejemplo, los paquetes descartados son los más probables. La VPN también puede cambiar el enrutamiento interno entre el cliente y el servidor, exponiendolo a otro dispositivo de red que bloquea la conexión. La recopilación de seguimientos de red en dispositivos intermedios ayuda a aislar el problema mediante la subdividir la red. El comando tracert puede revelar el enrutamiento.

Cliente

Si el problema está relacionado con los clientes, es posible que vea los siguientes indicadores:

Otros clientes pueden conectarse al servidor normalmente.
No se puede conectar ninguna aplicación desde esta máquina.
No se puede conectar con un administrador de orígenes de datos UDL o ODBC.

Esto puede deberse a una regla de firewall de salida o a sufijos DNS predeterminados incorrectos. Pruebe a probar con el nombre completo del servidor, por ejemplo:
```
Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
```
Puede tratarse de un problema de TLS. Por ejemplo, el servidor usa TLS 1.2 y los controladores de cliente no se han actualizado para él.

Puede haber una entrada de archivo de hosts, un alias SQL o un alias DNS que dirija la conexión a otro servidor. Use ping y telnet. Si funcionan, pero se produce un error en el controlador, sospecha de un problema de TLS o alias SQL.

Controlador

Si el problema está relacionado con los controladores, pruebe con controladores diferentes.

Si algunos controladores funcionan y otros producen un error, sospecho un problema de TLS. Descargue el controlador más reciente, como Microsoft OLE DB Driver for SQL Server o ODBC Driver 17 for SQL Server, e inténtelo.
Si usa .NET, asegúrese de que usa la versión más reciente del marco. Si sigue fallando, debe proporcionar un mensaje de error mejor. También puede descargar la versión más reciente de SQL Server Management Studio independiente de SQL Server e instalarla en cualquier cliente. Esto usa la SqlClient .NET clase .

Usuario

Si el problema está relacionado con los usuarios, haga que otro usuario inicie sesión en esta máquina.

Si la conexión se realiza correctamente, consulte lo que es diferente sobre el usuario con errores. Por ejemplo, el perfil de usuario de Windows está dañado o quizás los usuarios pertenecen a otra unidad organizativa (OU) o dominio.
Si hay usuarios de varios dominios, intente usar un usuario del mismo dominio que el servidor. Normalmente, los problemas de usuario producen errores de autenticación y tienen un flujo de trabajo de solución de problemas diferente.
Si no es un problema de autenticación, un registro del Monitor de procesos puede ayudar a identificar problemas de permisos locales que afectan a la conectividad. Por ejemplo, el usuario tiene un nombre de origen de datos (DSN) o algún tipo de redirección del Registro a otro controlador, una restricción de permisos local o algo que pueda explicar el error de conectividad.

Aplicación

Si solo se produce un error en una aplicación determinada y un archivo UDL se realiza correctamente, puede ser un problema de controlador o la aplicación tiene un cadena de conexión incorrecto. Haga que el equipo de desarrollo de aplicaciones o el proveedor de terceros comprueben el cadena de conexión. Puede usar el Explorador de procesos desde www.sysinternals.com para ver qué controlador se está usando si el cliente no está seguro.

Herramientas de seguimiento para capturar

Capture un seguimiento de red de cliente y servidor. Ejecute el seguimiento de SQL en el cliente y en el servidor al mismo tiempo.

Instale WireShark con el controlador NCAP para realizar el seguimiento cuando el cliente y el servidor estén en la misma máquina.

Es posible que su organización tenga su propio equipo de infraestructura de red con el que pueda interactuar y que tenga una herramienta de seguimiento preferida para realizar la captura. Pueden usar cualquier herramienta siempre que se guarde en un formato compatible con Network Monitor (NetMon.exe) o WireShark. El formato PCAP es el más popular.

Ejecute el Analizador de red de SQL (SQLNA) y la interfaz de usuario del Analizador de red de SQL (SQLNAUI) en el seguimiento de red para obtener un informe fácil de leer.

Más información

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.

Compartir a través de