Windows

Cómo comprobar puertos abiertos en Windows con PowerShell

2xSoftware

Cuando una aplicación no conecta, comprobar el puerto ayuda a separar tres problemas distintos: el servicio no está escuchando, el firewall bloquea el tráfico o la red no permite llegar al destino. En Windows puedes hacer ese diagnóstico sin instalar herramientas externas.

Qué debes comprobar antes

Anota el nombre o la IP del equipo de destino, el puerto y el protocolo. HTTP suele usar TCP, mientras que otras aplicaciones también pueden depender de UDP. Verifica además que tienes autorización para probar ese sistema: escanear equipos ajenos no es una práctica válida.

Probar un puerto TCP remoto con Test-NetConnection

Abre PowerShell y ejecuta:

Test-NetConnection servidor.ejemplo -Port 443

El dato principal es TcpTestSucceeded. Si devuelve True, Windows ha podido completar la conexión TCP. Si devuelve False, no demuestra por sí solo que el firewall sea culpable: el servicio puede estar detenido, el nombre puede resolver a una IP incorrecta o una regla de red puede descartar el tráfico.

Para ver más detalles:

Test-NetConnection servidor.ejemplo -Port 3389 -InformationLevel Detailed

Comprobar si el equipo local está escuchando

Para localizar conexiones y puertos TCP en escucha:

Get-NetTCPConnection -State Listen | Sort-Object LocalPort
Get-NetTCPConnection -LocalPort 443

El segundo comando permite comprobar un puerto concreto. Anota el valor de OwningProcess y relaciónalo con el proceso:

Get-Process -Id 1234

Sustituye 1234 por el identificador devuelto. Si no aparece ninguna escucha, revisa el servicio o la configuración de la aplicación antes de cambiar el firewall.

Revisar reglas del Firewall de Windows

Puedes buscar reglas activas relacionadas con un puerto:

Get-NetFirewallPortFilter |
  Where-Object LocalPort -eq 3389 |
  Get-NetFirewallRule

No desactives todo el firewall como solución permanente. Es preferible habilitar únicamente la regla necesaria, limitar los perfiles aplicables y restringir direcciones remotas cuando sea posible.

Qué hacer según el resultado

  • El puerto escucha localmente, pero falla en remoto: revisa firewall, router, VPN y segmentación.
  • No existe escucha local: inicia el servicio y confirma que usa la interfaz y el puerto esperados.
  • El nombre falla, pero la IP funciona: comprueba DNS con Resolve-DnsName.
  • Funciona dentro de la red, pero no desde Internet: revisa NAT y evita exponer servicios administrativos directamente.

Comandos alternativos

netstat -ano sigue siendo útil en versiones antiguas de Windows. Para HTTP o HTTPS, curl.exe -I https://servidor.ejemplo comprueba además que existe una respuesta de aplicación, no solo una conexión TCP.

Fuente y siguiente paso

Microsoft documenta Test-NetConnection y Get-NetTCPConnection. Si el problema afecta a Escritorio remoto, continúa con la guía de diagnóstico RDP programada en este mismo sitio.

Guías relacionadas