Cómo comprobar si un puerto está abierto en Windows

«No conecta» puede significar muchas cosas: que el servicio no está arrancado, que el firewall de Windows lo bloquea, que hay otro firewall por el camino o que el nombre ni siquiera resuelve. Comprobar si un puerto TCP está abierto separa de golpe dos mundos: si el puerto responde, el problema está en la aplicación o las credenciales; si no responde, está en la red o en el servicio.

Windows ofrece varias formas de hacerlo sin instalar nada. Aquí tienes las cuatro útiles, cuándo usar cada una y cómo interpretar el resultado sin confundir un puerto «cerrado» con uno «filtrado». Úsalas solo en equipos y redes que administras o para los que tienes permiso: probar puertos de sistemas ajenos puede considerarse un escaneo no autorizado.

Antes de empezar: dos preguntas distintas

«¿Está abierto el puerto?» puede querer decir dos cosas, y se comprueban de forma diferente:

• ¿Está escuchando este equipo en ese puerto? (el servicio local está en marcha). Se responde con netstat o Get-NetTCPConnection en el propio equipo.
• ¿Puedo llegar desde otro equipo a ese puerto? (el servicio es alcanzable por la red). Se responde con Test-NetConnection o telnet desde el equipo cliente.

Un servicio puede estar escuchando y aun así ser inalcanzable por el firewall. Por eso conviene hacer las dos comprobaciones cuando algo falla.

Método 1: Test-NetConnection (el recomendado)

El cmdlet Test-NetConnection viene en Windows 8.1 / Server 2012 R2 y posteriores. Con el parámetro -Port intenta abrir una conexión TCP al destino:

Test-NetConnection -ComputerName servidor01 -Port 443

La salida incluye los campos que importan:

ComputerName     : servidor01
RemoteAddress    : 192.0.2.20
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 192.0.2.101
TcpTestSucceeded : True

El campo clave es TcpTestSucceeded. True significa que se completó el establecimiento de la conexión TCP; False significa que no se pudo, y entonces PowerShell suele mostrar un aviso del tipo «TCP connect to (IP : puerto) failed». Si solo quieres un sí o un no para un script, añade -InformationLevel Quiet:

Test-NetConnection servidor01 -Port 3389 -InformationLevel Quiet

Para varios puertos de una vez:

135,445,3389 | ForEach-Object {
    [pscustomobject]@{
        Puerto  = $_
        Abierto = Test-NetConnection servidor01 -Port $_ -InformationLevel Quiet
    }
}

Algunas notas prácticas. Si el puerto está filtrado por un firewall que descarta paquetes en silencio, la prueba puede tardar varios segundos hasta darse por vencida; no es un cuelgue. El cmdlet comprueba TCP, no UDP, así que no sirve para saber si «está abierto» un servicio UDP como DNS en el puerto 53 (para ese caso usa nslookup, que explicamos en la guía de nslookup en Windows). Tienes más ejemplos del cmdlet, incluido el seguimiento de ruta, en la guía de Test-NetConnection.

Método 2: el cliente Telnet

Telnet no se instala por defecto en las versiones actuales de Windows, pero sigue siendo una forma rápida de saber si un puerto TCP acepta conexiones. Primero hay que habilitar la característica, desde un símbolo del sistema con permisos de administrador:

dism /online /Enable-Feature /FeatureName:TelnetClient

Luego se prueba con:

telnet servidor01 25

Si la pantalla se queda en blanco o aparece el saludo del servicio (por ejemplo, el banner de un servidor SMTP), el puerto está abierto. Si ves «No se pudo abrir la conexión al host», el puerto no es alcanzable. Sirve para comprobar, no para administrar nada por telnet: es un protocolo sin cifrado y no debe usarse para conectarte a servicios reales. Cuando termines, puedes volver a deshabilitar la característica con dism /online /Disable-Feature /FeatureName:TelnetClient.

Método 3: ver qué escucha tu propio equipo (netstat)

Si el servicio debería estar en este equipo, empieza por confirmar que realmente escucha:

netstat -ano | findstr :443

Busca una línea con estado LISTENING (o ESCUCHANDO en Windows en español). Fíjate en la dirección local de esa línea: 0.0.0.0:443 indica que escucha en todas las interfaces IPv4; 127.0.0.1:443 significa que solo acepta conexiones locales, así que desde otro equipo nunca responderá aunque el firewall esté abierto. La última columna es el identificador del proceso (PID). Para saber qué programa es:

Get-Process -Id 4120

Sustituye 4120 por el PID que te haya salido. Es la comprobación más útil cuando un puerto «está ocupado» por otro programa; tienes un caso parecido, con los puertos COM, en cómo eliminar o borrar puertos COM en uso.

Método 4: Get-NetTCPConnection

La versión en PowerShell de netstat devuelve objetos que puedes filtrar:

Get-NetTCPConnection -State Listen -LocalPort 443 |
    Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetTCPConnection -State Listen |
    Sort-Object LocalPort |
    Select-Object LocalAddress, LocalPort, OwningProcess

El segundo comando lista todos los puertos en escucha ordenados, útil para auditar qué servicios expone un servidor. Si un puerto aparece aquí pero no responde desde fuera, el siguiente sospechoso es el firewall.

Método 5: una función propia con tiempo de espera

Si necesitas probar muchos destinos y no quieres esperar el tiempo de espera por defecto de Test-NetConnection, puedes usar directamente la clase de .NET que hay detrás de la mayoría de estas herramientas. Esta función funciona en Windows PowerShell 5.1 y en PowerShell 7 y devuelve solo True o False:

function Test-Puerto {
    param(
        [string]$Destino,
        [int]$Puerto,
        [int]$TiempoMs = 2000
    )
    $cliente = [System.Net.Sockets.TcpClient]::new()
    try {
        $tarea  = $cliente.ConnectAsync($Destino, $Puerto)
        $abierto = $tarea.Wait($TiempoMs) -and $cliente.Connected
    } catch {
        $abierto = $false
    } finally {
        $cliente.Dispose()
    }
    $abierto
}

Test-Puerto -Destino servidor01 -Puerto 1433 -TiempoMs 1500

Con ella puedes recorrer una lista de servidores y obtener una tabla en segundos, algo muy útil antes de una migración o después de cambiar reglas de firewall. Reduce el tiempo de espera si la red es rápida y auméntalo para enlaces lentos o VPN, para no confundir latencia con bloqueo.

Cómo interpretar el resultado

Lo que ves	Qué suele significar	Siguiente paso
TcpTestSucceeded : True	El puerto acepta conexiones desde ese origen	Revisar la aplicación, el certificado o las credenciales
Fallo rápido (conexión rechazada)	El equipo responde, pero no hay nada escuchando en ese puerto	Arrancar el servicio; confirmar con netstat que escucha
Fallo lento (tiempo agotado)	Un firewall descarta los paquetes o la ruta no llega al destino	Revisar firewall del servidor, firewall perimetral y rutas
El nombre no resuelve	El problema es de DNS, no del puerto	Probar con la IP; revisar DNS
Escucha solo en 127.0.0.1	El servicio solo atiende en local	Cambiar la dirección de enlace del servicio

La diferencia entre «rechazado» y «tiempo agotado» es la pista más valiosa. Un rechazo rápido suele indicar que llegas al equipo; el tiempo agotado indica que algo en el camino se traga los paquetes. No es una regla absoluta, porque algunos firewalls responden con rechazo explícito, pero orienta bien el diagnóstico.

Si el puerto está escuchando pero no llegas desde fuera

Revisa el firewall de Windows en el propio servidor. Con PowerShell puedes ver qué reglas de entrada afectan a un puerto:

Get-NetFirewallPortFilter -Protocol TCP |
    Where-Object LocalPort -eq 3389 |
    Get-NetFirewallRule |
    Select-Object DisplayName, Enabled, Direction, Action, Profile

Comprueba que haya una regla de entrada habilitada con acción Allow y que el perfil (Dominio, Privado, Público) corresponda a la red en la que está el equipo. Si el servicio es el escritorio remoto, no basta con abrirlo: hay que hacerlo con cabeza, y en la guía de cómo proteger el Escritorio Remoto en Windows Server se explica cómo limitar quién puede conectar.

Casos concretos donde el puerto «parece cerrado»

Algunos fallos se repiten tanto que merece la pena conocerlos antes de tocar nada:

• Correo saliente por el puerto 25. Muchos proveedores de acceso a internet y de nube bloquean el tráfico saliente al puerto 25 para frenar el spam. Si Test-NetConnection smtp.ejemplo.com -Port 25 falla desde un servidor pero funciona desde otra red, el bloqueo está en el proveedor, no en tu equipo. Prueba con 587 (envío autenticado) si tu servicio de correo lo admite.
• SQL Server con instancias con nombre. La instancia predeterminada escucha en el 1433, pero las instancias con nombre suelen usar un puerto dinámico que informa el servicio SQL Server Browser por UDP 1434. Probar el 1433 contra una instancia con nombre dará «cerrado» aunque todo esté bien. Fija un puerto estático en la configuración de la instancia o consulta el que está usando.
• El nombre resuelve a varias direcciones. Si un nombre devuelve una IPv6 y una IPv4 y el servicio solo escucha en IPv4, la prueba puede fallar o tardar según el orden en que se intenten. Repite la comprobación con la IP concreta para descartarlo.
• Perfil de red equivocado. Una regla del firewall de Windows habilitada solo para el perfil «Dominio» no se aplica si el equipo cree estar en una red «Pública». El síntoma es que el puerto funciona un día y deja de hacerlo al cambiar de red.
• El servicio escucha, pero no en la interfaz que crees. Una aplicación enlazada a una IP concreta o a 127.0.0.1 no atenderá conexiones que lleguen por otra interfaz. Es lo primero que muestra netstat -ano.

Cuando necesites comprobar el mismo puerto desde Linux o macOS, el equivalente es nc -zv servidor01 443 (la opción -z no envía datos y -v muestra el resultado). Es la misma idea y los mismos criterios de interpretación.

Puertos habituales de referencia

Puerto	Servicio
22	SSH
25	SMTP (correo saliente entre servidores)
53	DNS (TCP y UDP)
80 / 443	HTTP / HTTPS
389 / 636	LDAP / LDAP sobre TLS
445	SMB (carpetas compartidas)
1433	Microsoft SQL Server (instancia predeterminada)
3306	MySQL / MariaDB
3389	Escritorio remoto (RDP)
5985 / 5986	WinRM (PowerShell remoto) HTTP / HTTPS

Resumen

• Para saber si puedes llegar a un puerto desde otro equipo: Test-NetConnection servidor -Port N y mira TcpTestSucceeded.
• Para saber si un servicio escucha en el propio equipo: netstat -ano o Get-NetTCPConnection -State Listen.
• Rechazo rápido: llegas al equipo pero no hay servicio. Tiempo agotado: algo filtra o no hay ruta.
• Un servicio que escucha solo en 127.0.0.1 nunca será alcanzable desde la red.
• Estas pruebas son para sistemas que administras o para los que tienes autorización.