Test-NetConnection: cómo probar puertos y conexiones con PowerShell, y los comandos de red que todo técnico debe conocer

Test-NetConnection es el cmdlet de PowerShell que responde la pregunta que más se repite en soporte técnico: ¿hay conexión entre este equipo y aquel servidor, y el servicio que busco está respondiendo? En una sola orden resuelve el nombre, intenta abrir el puerto TCP que se le pida, hace ping si hace falta y dice por qué interfaz y desde qué dirección salió la prueba: es la forma más directa de probar un puerto con PowerShell. Esta guía explica cómo usarlo, cómo leer lo que devuelve y por qué a veces tarda tanto, y reúne los comandos de red en PowerShell que un profesional de TI usa a diario, como Test-Connection y Resolve-DnsName, con escenarios listos para copiar.

Está escrita para dos lectores. Si no es de sistemas, le basta con la tabla de la primera sección y la de cómo leer el resultado: con ellas puede decirle a su proveedor dónde está el corte. Si es técnico, el resto del artículo le ahorra las trampas que medimos: avisos en inglés aunque Windows esté en español, un PingSucceeded en falso que no significa lo que parece y esperas de 42 segundos por puerto que se pueden evitar.

Todo lo que sigue se midió en un portátil con Windows 11 Pro, Windows PowerShell 5.1 y PowerShell 7.6.9, en una consola sin permisos de administrador. Las pruebas se hicieron contra el propio equipo, contra www.kharonte.com y contra 192.0.2.1, una dirección reservada para documentación que no responde nunca y sirve para medir un puerto filtrado sin molestar a nadie.

Test-NetConnection en un minuto

Lo que quiere saber	Orden
¿Tengo internet?	Test-NetConnection
¿Responde este equipo al ping?	Test-NetConnection www.kharonte.com
¿Está abierto el puerto 443 de este servidor?	Test-NetConnection www.kharonte.com -Port 443
Lo mismo, pero solo con verdadero o falso	Test-NetConnection www.kharonte.com -Port 443 -InformationLevel Quiet
¿Puedo conectarme por escritorio remoto?	Test-NetConnection SERVIDOR -CommonTCPPort RDP
¿Por dónde pasan los paquetes hasta el destino?	Test-NetConnection www.kharonte.com -TraceRoute
¿Por qué interfaz y con qué ruta sale el tráfico?	Test-NetConnection www.kharonte.com -DiagnoseRouting
La forma corta de escribirlo	tnc www.kharonte.com -Port 443

Qué es Test-NetConnection y para qué sirve

Test-NetConnection forma parte del módulo NetTCPIP de Windows, no de PowerShell. Por eso funciona igual en Windows PowerShell 5.1 y en PowerShell 7 sobre Windows, y no existe en PowerShell para Linux ni para macOS. Microsoft lo resume en su referencia oficial: admite prueba de ping, prueba TCP, rastreo de ruta y diagnóstico de selección de ruta.

En el trabajo diario se usa para cuatro cosas:

• Comprobar un servicio antes de culpar a la aplicación. Si el ERP, el correo o la carpeta compartida no abren, saber si el puerto responde separa un problema de red de uno del programa.
• Validar un cambio de firewall o de VPN. Después de abrir una regla, una prueba al puerto dice en un segundo si el cambio surtió efecto desde el lado del usuario.
• Documentar un incidente. El resultado incluye la dirección de origen, la interfaz y la dirección del destino, que es justo lo que pide un proveedor de internet o un fabricante.
• Automatizar revisiones. Con -InformationLevel Quiet devuelve un valor verdadero o falso que un script puede usar para decidir, registrar o avisar.

Por qué es mejor que ping y telnet

El ping solo dice que un equipo responde a ICMP, y muchos servidores y casi todos los servicios en la nube lo bloquean a propósito. Un equipo puede no responder al ping y tener su servicio perfectamente disponible, o al revés. Test-NetConnection prueba el puerto real del servicio, que es lo que de verdad importa.

Telnet servía para lo mismo, pero en el Windows 11 de las pruebas el cliente no estaba instalado: es una característica opcional de Windows, y activarla pide permisos de administrador. Test-NetConnection ya está instalado en cualquier Windows moderno y devuelve un objeto con propiedades, no texto suelto: se puede filtrar, guardar en un CSV o usar en un if.

Sintaxis: los cuatro modos de Test-NetConnection

Test-NetConnection tiene cuatro conjuntos de parámetros, y no se pueden mezclar. Lo comprobamos con Get-Command Test-NetConnection -Syntax en las dos versiones:

Modo	Parámetros propios	Qué hace
ICMP (por defecto)	-TraceRoute, -Hops	Ping y, si se pide, rastreo de ruta
Puerto común	-CommonTCPPort	Prueba TCP a un puerto por su nombre
Puerto	-Port	Prueba TCP a cualquier puerto
Diagnóstico de ruta	-DiagnoseRouting, -ConstrainSourceAddress, -ConstrainInterface	Qué ruta y qué dirección de origen elegiría Windows

Los cuatro aceptan -ComputerName, que es el primer parámetro y por eso puede omitirse su nombre, e -InformationLevel con Quiet o Detailed. Sin destino, la prueba va a internetbeacon.msedge.net, un servidor de Microsoft pensado para eso.

Test-NetConnection
Test-NetConnection www.kharonte.com
Test-NetConnection www.kharonte.com -Port 443
Test-NetConnection www.kharonte.com -CommonTCPPort HTTP
tnc www.kharonte.com -Port 443

Los cuatro puertos con nombre de Test-NetConnection

-CommonTCPPort acepta cuatro valores. El código del cmdlet, que viene en el propio Windows y se puede leer con (Get-Command Test-NetConnection).ScriptBlock, los traduce así:

Valor	Puerto	Servicio
HTTP	80	Web sin cifrar
RDP	3389	Escritorio remoto
SMB	445	Carpetas compartidas e impresoras de Windows
WINRM	5985	Administración remota de PowerShell por HTTP

Ojo con WINRM: prueba el 5985, no el 5986 de WinRM sobre HTTPS. Para HTTPS, el 443, o cualquier otro puerto, se usa -Port. El detalle de WinRM está en nuestra guía de PowerShell remoto.

Probar un puerto con PowerShell y Test-NetConnection

Es el uso más común. La orden devuelve el nombre, la dirección que se usó, el puerto, la interfaz, la dirección de origen y, al final, TcpTestSucceeded, que es lo único que responde la pregunta: True si el puerto aceptó la conexión y False si no.

Para un script, la salida completa estorba. Con -InformationLevel Quiet el cmdlet devuelve un System.Boolean y nada más. Con Detailed añade todas las direcciones que resolvió el nombre, la siguiente puerta de enlace y el contexto de aislamiento de red.

Test-NetConnection www.kharonte.com -Port 443 -InformationLevel Quiet
Test-NetConnection www.kharonte.com -Port 443 -InformationLevel Detailed

Cuando se guarda el resultado en una variable se pueden leer sus propiedades. El objeto es de tipo TestNetConnectionResult y trae más de las que muestra en pantalla, como ResolvedAddresses, InterfaceIndex, InterfaceDescription o NameResolutionSucceeded:

$r = Test-NetConnection www.kharonte.com -Port 443 -WarningAction SilentlyContinue
if ($r.TcpTestSucceeded) {
    "Puerto $($r.RemotePort) abierto en $($r.RemoteAddress), saliendo por $($r.InterfaceAlias)"
} else {
    "Sin conexión al puerto $($r.RemotePort) de $($r.ComputerName)"
}

-WarningAction SilentlyContinue oculta los avisos amarillos que Test-NetConnection escribe cuando algo falla. En un script conviene ocultarlos y decidir con la propiedad; en una prueba a mano, conviene leerlos.

Cómo leer el resultado de Test-NetConnection

Estas son las combinaciones que vimos en las pruebas, con lo que suelen significar:

Resultado	Qué significa	Qué revisar
TcpTestSucceeded: True	El servicio acepta conexiones en ese puerto	Si la aplicación sigue fallando, el problema está en la aplicación, el usuario o el certificado
TcpTestSucceeded: False y PingSucceeded: True	El equipo existe y responde, pero el puerto no	Que el servicio esté iniciado, el firewall del servidor y las reglas del firewall perimetral
TcpTestSucceeded: False y PingSucceeded: False	No se llega al equipo, o bloquea las dos cosas	VPN, ruta, que el equipo esté encendido; el ping puede estar bloqueado a propósito
Aviso Name resolution of … failed	El nombre no existe para el DNS que usa el equipo	El nombre, el DNS configurado y, en la oficina, el servidor DNS interno
PingSucceeded: False con TcpTestSucceeded: True	Nada: el ping no se hizo	No es un problema; se explica justo debajo

La trampa de PingSucceeded

Al guardar el resultado de una prueba de puerto que funcionó, la propiedad PingSucceeded vale False. En nuestra prueba con www.kharonte.com salió así, aunque ese servidor responde al ping. La explicación está en el código del cmdlet: el ping solo se intenta si no se pidió un puerto o si el puerto falló. Cuando el puerto responde, el ping no se hace y la propiedad se queda en su valor inicial.

Un script que compruebe PingSucceeded después de una prueba de puerto correcta dará una falsa alarma. La regla es sencilla: con -Port o -CommonTCPPort, la propiedad que cuenta es TcpTestSucceeded.

Los avisos de Test-NetConnection salen en inglés

En un Windows 11 configurado en español, los avisos de Test-NetConnection salieron en inglés en las dos versiones de PowerShell: TCP connect to (192.0.2.1 : 445) failed, Ping to 192.0.2.1 failed with status: TimedOut y Name resolution of no-existe-kh-prueba.kharonte.com failed. Vienen escritos así en el código del cmdlet, no se traducen. Los mensajes de error de PowerShell, en cambio, sí salen en español. Conviene saberlo para buscar el mensaje exacto en la documentación o en el sistema de tickets.

Por qué Test-NetConnection tarda tanto

Es la queja más frecuente, y tiene causas concretas. Test-NetConnection no tiene un parámetro de tiempo de espera: cuando un puerto no responde, espera lo que decide Windows. Estas son las cifras que medimos, iguales en 5.1 y en 7:

Caso	Salida normal	Con -InformationLevel Quiet
Puerto abierto (www.kharonte.com, 443)	0,34 a 0,82 s	0,07 a 0,09 s
Puerto cerrado que rechaza la conexión (el propio equipo o la puerta de enlace)	7,2 a 7,6 s	2,0 s
Puerto filtrado, destino con una dirección (192.0.2.1, 445)	35,2 s	21,0 s
Puerto filtrado, nombre con dos direcciones (www.kharonte.com, 22)	43,5 s	42,5 s
Ping a un destino que no responde, sin puerto	14,0 a 14,3 s	(no aplica)

Las tres causas de la espera

De la tabla salen tres causas:

1. Un puerto filtrado espera unos 21 segundos. Es el tiempo que tarda Windows en dar por perdida una conexión TCP sin respuesta. Un puerto cerrado de verdad, que contesta con un rechazo, falla en unos 2 segundos.
2. Cuando el puerto falla, además hace ping. Por eso un puerto filtrado tarda 35 segundos con la salida normal y 21 con Quiet, que devuelve el resultado antes de llegar al ping.
3. Prueba el puerto en cada dirección del nombre, una tras otra. www.kharonte.com resuelve a dos direcciones IPv4, y la prueba al puerto 22 dejó dos avisos, uno por dirección, en 42,5 segundos. Con la dirección escrita a mano tardó 21,0. Un nombre con cuatro direcciones puede tardar más de un minuto y medio en fallar.

Cómo acortar la espera

La salida normal también es más lenta cuando todo va bien, porque al final consulta el DNS, el adaptador y la ruta para mostrar sus detalles. En las pruebas al propio equipo, por ejemplo, la salida normal tardó 6 segundos y Quiet, menos de una centésima.

La conclusión práctica: para revisar varios puertos o varios equipos, use -InformationLevel Quiet, pruebe una dirección cuando la conozca y, si la espera importa, use una de las alternativas con límite de tiempo del escenario 3.

Rastreo de ruta con Test-NetConnection

Con -TraceRoute, Test-NetConnection hace el equivalente de tracert y guarda los saltos en la propiedad TraceRoute. -Hops fija el máximo de saltos: la referencia de Microsoft no da valor por defecto, pero el código del cmdlet lo fija en 30. En nuestra prueba, seis saltos tardaron entre 4,3 y 4,7 segundos.

Test-NetConnection www.kharonte.com -TraceRoute -Hops 15
(Test-NetConnection www.kharonte.com -TraceRoute -Hops 15 -WarningAction SilentlyContinue).TraceRoute

Un salto que aparece como 0.0.0.0 es un enrutador que no contestó a tiempo. Es normal en redes de proveedores que no responden a estas sondas, y no indica una avería si los saltos siguientes sí aparecen.

Qué ruta elige Windows: -DiagnoseRouting

-DiagnoseRouting no envía nada al destino: dice qué ruta y qué dirección de origen elegiría Windows para llegar a él. Es útil en equipos con varias conexiones, como un portátil con wifi, cable y una VPN, porque muestra si el tráfico hacia un servidor sale por el túnel o por internet. Funcionó sin permisos de administrador; solo -InformationLevel Detailed, que añade la explicación de por qué se eligió cada ruta, pide una consola elevada y lo avisa con '-InformationLevel Detailed' requires elevation (Run as administrator).

Test-NetConnection www.kharonte.com -DiagnoseRouting
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object InterfaceAlias, NextHop, RouteMetric, InterfaceMetric

-ConstrainInterface y -ConstrainSourceAddress solo existen en ese modo. Combinarlos con -Port da el error No se puede resolver el conjunto de parámetros usando los parámetros con nombre especificados. Test-NetConnection no permite elegir por qué interfaz sale una prueba de puerto.

Comandos de red en PowerShell que conviene conocer

Test-NetConnection es el punto de partida, pero un diagnóstico completo suele necesitar otros comandos de red en PowerShell. Estos son los que usamos en las pruebas, todos sin permisos de administrador:

Comando	Para qué sirve	Equivalente en CMD
Test-Connection	Ping con objetos; en PowerShell 7, también puertos y rastreo	ping
Resolve-DnsName	Consultar el DNS, por tipo de registro y servidor	nslookup
Get-NetIPConfiguration	Resumen de cada interfaz: IP, puerta de enlace y DNS	ipconfig
Get-NetAdapter	Adaptadores, estado, velocidad y MAC	getmac, netsh interface show interface
Get-NetIPAddress	Direcciones IP con su prefijo y su origen (manual o DHCP)	ipconfig /all
Get-NetRoute	Tabla de rutas	route print
Get-DnsClientServerAddress	Servidores DNS de cada interfaz	ipconfig /all
Get-NetTCPConnection	Conexiones TCP y puertos en escucha, con el proceso dueño	netstat -ano
Get-NetUDPEndpoint	Puertos UDP abiertos en el equipo	netstat -ano -p UDP
Get-NetConnectionProfile	Si cada red es pública, privada o de dominio	(no tiene)
Get-NetFirewallProfile	Estado del firewall de Windows por perfil	netsh advfirewall show allprofiles
Clear-DnsClientCache	Vaciar la caché DNS del equipo	ipconfig /flushdns
Restart-NetAdapter	Reiniciar un adaptador de red	(no tiene)

Si viene de la consola clásica, nuestra guía de comandos CMD tiene la tabla completa de equivalencias, y la de PowerShell explica cómo trabajar con los objetos que devuelven estos comandos.

Configuración del equipo en cuatro órdenes

Get-NetIPConfiguration
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name, InterfaceDescription, LinkSpeed, MacAddress
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength, PrefixOrigin
Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object ServerAddresses

En el portátil de las pruebas, Get-NetIPConfiguration mostró siete interfaces y tardó 3,4 segundos: la wifi, dos túneles de VPN, dos adaptadores virtuales de Hyper-V y dos desconectados con direcciones 169.254. Solo la wifi tenía puerta de enlace. En un equipo con virtualización o VPN, lo primero es identificar cuál es la interfaz que de verdad sale a la red; Get-NetRoute -DestinationPrefix 0.0.0.0/0 lo dice.

PrefixOrigin distingue una dirección asignada por DHCP (Dhcp) de una puesta a mano (Manual) o de una de enlace local (WellKnown). Una dirección 169.254.x.x en la interfaz principal significa que el equipo no recibió dirección del servidor DHCP.

Get-NetConnectionProfile merece un vistazo cuando algo funciona en la oficina y no en casa, o al revés: el firewall de Windows aplica reglas distintas a las redes públicas, privadas y de dominio.

Qué programa está usando un puerto

Get-NetTCPConnection muestra las conexiones del propio equipo, y su propiedad OwningProcess dice qué proceso es el dueño de cada una. Con un oyente de prueba en el puerto 50997, la orden devolvió el número de proceso de la propia consola de PowerShell.

Get-NetTCPConnection -LocalPort 445 -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, LocalPort, State, OwningProcess,
        @{ n = 'Proceso'; e = { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName } }
Get-NetTCPConnection -State Established | Group-Object RemoteAddress | Sort-Object Count -Descending | Select-Object -First 10 Count, Name

Si el puerto no está en uso, Get-NetTCPConnection no devuelve nada y escribe un error largo que empieza por No se encontraron objetos coincidentes MSFT_NetTCPConnection (en 7) o Consulta CIM para instancias de la clase… (en 5.1). Con -ErrorAction SilentlyContinue se evita.

Test-Connection: el ping de PowerShell, distinto en 5.1 y en 7

Test-Connection es el ping con objetos. Existe en las dos versiones, pero no es el mismo comando: PowerShell 7 lo reescribió y le dio funciones que en Windows PowerShell 5.1 no existen. Lo medimos con las dos:

Función	Windows PowerShell 5.1	PowerShell 7
Ping con -Count y -Quiet	Sí	Sí
Nombre del destino	-ComputerName	-TargetName, y -ComputerName sigue valiendo como alias
Probar un puerto TCP (-TcpPort)	No existe	Sí, devuelve verdadero o falso
Rastreo de ruta (-Traceroute)	No existe	Sí
Tiempo de espera (-TimeoutSeconds)	No existe	Sí, 5 segundos de fábrica
Ping continuo (-Repeat)	No existe	Sí, hasta pulsar Ctrl + C
Destino que no responde	Error Error debido a falta de recursos a los 3,6 s	Fila con estado TimedOut a los 5,0 s

En 5.1, -TcpPort da No se encuentra ningún parámetro que coincida con el nombre del parámetro 'TcpPort'. Es el error que aparece al copiar un ejemplo escrito para PowerShell 7 en la consola azul de siempre.

Test-Connection www.kharonte.com -Count 2
Test-Connection www.kharonte.com -Count 1 -Quiet

Probar un puerto con PowerShell 7 y Test-Connection

Solo en PowerShell 7:

Test-Connection www.kharonte.com -TcpPort 443
Test-Connection www.kharonte.com -TcpPort 22 -TimeoutSeconds 2
Test-Connection www.kharonte.com -TcpPort 443 -Detailed -Count 2

Lo más útil de esta versión es justo lo que le falta a Test-NetConnection: un límite de tiempo. Un puerto filtrado de www.kharonte.com tardó 5,03 segundos en darse por cerrado con el valor de fábrica y 2,01 con -TimeoutSeconds 2, frente a los 42,5 de Test-NetConnection. A cambio, Test-Connection -TcpPort solo devuelve verdadero o falso: no dice por qué interfaz salió ni qué dirección usó.

-Traceroute hace tres sondas por salto y es lento con enrutadores que no contestan: cuatro saltos tardaron 35 segundos. Si el destino está más lejos que -MaxHops, falla con No se puede completar traceroute al destino "www.kharonte.com": el número de saltos necesarios para alcanzar el host supera MaxHops (4).

Resolve-DnsName: consultar el DNS desde PowerShell

Resolve-DnsName es el reemplazo de nslookup y tiene dos ventajas: devuelve objetos y deja elegir el tipo de registro y el servidor que se consulta. La referencia de Resolve-DnsName lista todos sus parámetros; estos son los que más se usan:

Resolve-DnsName www.kharonte.com
Resolve-DnsName kharonte.com -Type MX
Resolve-DnsName kharonte.com -Type TXT -Server 1.1.1.1
Resolve-DnsName www.kharonte.com -DnsOnly -NoHostsFile

-Server pregunta a un servidor concreto en lugar de al configurado en el equipo, lo que sirve para comparar lo que ve la oficina con lo que ve internet. -DnsOnly ignora LLMNR y NetBIOS, y -NoHostsFile ignora el archivo hosts, dos fuentes que pueden hacer que un equipo resuelva distinto de los demás. Para entender los tipos de registro, nuestra guía del servidor DNS los explica uno por uno.

La trampa del nombre que no existe

Al preguntar por un nombre inexistente dentro de kharonte.com, cuyo DNS sirve Cloudflare, Resolve-DnsName no dio error: devolvió un solo registro, de tipo SOA y en la sección Authority, y $? quedó en verdadero. Con un dominio inexistente en .com, en cambio, sí dio el error El nombre DNS no existe. La diferencia depende de cómo responda el servidor, y un script no puede dar por hecho cuál le tocará.

Un if (Resolve-DnsName …) diría que el nombre existe. La forma segura es quedarse solo con las respuestas del tipo pedido en la sección Answer:

$respuesta = Resolve-DnsName nombre-que-no-existe.kharonte.com -Type A -ErrorAction SilentlyContinue
$ip = $respuesta | Where-Object { $_.Section -eq 'Answer' -and $_.Type -eq 'A' }
if ($ip) { "Resuelve a $($ip.IPAddress -join ', ')" } else { 'El nombre no tiene registro A' }

Con un servidor que no responde, -QuickTimeout no fue tan rápido como su nombre sugiere: preguntar a 192.0.2.1 tardó 7,0 segundos en fallar con Se devolvió esta operación porque se agotó el tiempo de espera.

Escenarios de ejemplo con Test-NetConnection

Los bloques usan www.kharonte.com y el propio equipo para que se puedan probar tal cual. En su caso, cambie el nombre por el de su servidor. Pruebe solo equipos de su organización o que tenga permiso para revisar.

Escenario 1: «el sistema no abre», en tres comprobaciones

Antes de escalar un caso, conviene saber en qué capa está el corte: el nombre, el puerto o la aplicación. Este bloque lo deja en una sola tabla que se puede pegar en el ticket:

$equipo = 'www.kharonte.com'
$dns = Resolve-DnsName $equipo -Type A -ErrorAction SilentlyContinue | Where-Object Section -eq 'Answer'
$tcp = Test-NetConnection $equipo -Port 443 -WarningAction SilentlyContinue
[pscustomobject]@{
    Nombre      = if ($dns) { 'resuelve' } else { 'NO resuelve' }
    Direcciones = $dns.IPAddress -join ', '
    Puerto443   = $tcp.TcpTestSucceeded
    Interfaz    = $tcp.InterfaceAlias
    Origen      = $tcp.SourceAddress.IPAddress
}

Si el nombre no resuelve, el problema es de DNS. Cuando resuelve pero el puerto falla, es de red, firewall o servicio. Y con las dos cosas funcionando, el problema está en la aplicación, en la cuenta del usuario o en el certificado, y la red queda descartada.

Escenario 2: comprobar el escritorio remoto antes de conectarse

Cuando una conexión de escritorio remoto falla, el mensaje de Windows no dice si el servidor está apagado, si la VPN no subió o si el firewall corta. Este bloque prueba el puerto 3389 y solo abre la conexión si responde:

$servidor = 'localhost'
if (Test-NetConnection $servidor -CommonTCPPort RDP -InformationLevel Quiet -WarningAction SilentlyContinue) {
    mstsc /v:$servidor
} else {
    "El puerto 3389 de $servidor no responde: revise la VPN, el firewall o si el escritorio remoto está activado."
}

Escenario 3: revisar varios puertos de un servidor sin esperar minutos

Probamos los puertos 22, 80, 443, 3389 y 8443 de www.kharonte.com, dos de ellos filtrados, con tres métodos. Los resultados coincidieron; los tiempos, no:

Método	Tiempo	Versión
Test-NetConnection en un bucle	87,5 s	5.1 y 7
Test-NetConnection con ForEach-Object -Parallel	48,2 s	Solo 7
Test-Connection -TcpPort con -TimeoutSeconds 1	2,3 s	Solo 7
Cliente TCP de .NET con un segundo de límite	2,2 s	5.1 y 7

La función siguiente funciona en las dos versiones y pone el límite que Test-NetConnection no tiene. Se pega una vez en la consola y luego se usa como cualquier comando:

function Test-Puerto {
    param([string]$Equipo, [int[]]$Puerto, [int]$Milisegundos = 1000)
    foreach ($p in $Puerto) {
        $cliente = [System.Net.Sockets.TcpClient]::new()
        try {
            $abierto = $cliente.ConnectAsync($Equipo, $p).Wait($Milisegundos) -and $cliente.Connected
        } catch {
            $abierto = $false
        } finally {
            $cliente.Dispose()
        }
        [pscustomobject]@{ Equipo = $Equipo; Puerto = $p; Abierto = $abierto }
    }
}
Test-Puerto -Equipo www.kharonte.com -Puerto 22, 80, 443, 3389, 8443

Con PowerShell 7 basta con Test-Connection:

foreach ($p in 22, 80, 443, 3389, 8443) {
    [pscustomobject]@{ Puerto = $p; Abierto = Test-Connection www.kharonte.com -TcpPort $p -TimeoutSeconds 1 }
}

Un límite de un segundo sirve en la misma red o hacia un servicio rápido. Hacia un servidor lejano o por una VPN lenta, suba el límite a dos o tres segundos para no dar por cerrado un puerto que solo tardó en responder.

Escenario 4: una revisión de puertos con Test-NetConnection que queda guardada

Para revisar cada mañana los servicios críticos, o para dejar constancia antes y después de un cambio, este bloque prueba una lista de equipos y puertos y guarda el resultado en un CSV en el escritorio. Usa -InformationLevel Quiet para no pagar el ping de cada fallo:

$destinos = @(
    @{ Equipo = 'www.kharonte.com'; Puerto = 443 }
    @{ Equipo = 'www.kharonte.com'; Puerto = 3389 }
    @{ Equipo = 'localhost'; Puerto = 445 }
)
$resultado = foreach ($d in $destinos) {
    [pscustomobject]@{
        Fecha   = Get-Date -Format 'yyyy-MM-dd HH:mm'
        Equipo  = $d.Equipo
        Puerto  = $d.Puerto
        Abierto = Test-NetConnection $d.Equipo -Port $d.Puerto -InformationLevel Quiet -WarningAction SilentlyContinue
    }
}
$resultado | Format-Table
$archivo = Join-Path ([Environment]::GetFolderPath('Desktop')) 'puertos.csv'
$resultado | Export-Csv -Path $archivo -NoTypeInformation -Encoding UTF8 -Delimiter ';'

[Environment]::GetFolderPath('Desktop') encuentra el escritorio aunque esté dentro de OneDrive, y el punto y coma es el separador que espera Excel con la configuración regional de Colombia. Con esta lista, la revisión tardó 42,2 segundos en las dos versiones: el puerto 3389 está filtrado y Test-NetConnection lo prueba en las dos direcciones del nombre. Si la lista es larga, use la función del escenario 3.

Escenario 5: comparar el DNS de la oficina con un DNS público

Cuando un sitio abre en unos equipos y en otros no, o abre desde el celular y no desde la oficina, la causa suele ser que dos servidores DNS dan respuestas distintas. Este bloque pregunta a los servidores configurados en el equipo y a dos públicos:

$nombre = 'www.kharonte.com'
$servidores = @((Get-DnsClientServerAddress -AddressFamily IPv4).ServerAddresses) + '1.1.1.1', '8.8.8.8' | Select-Object -Unique
foreach ($s in $servidores) {
    $r = Resolve-DnsName $nombre -Type A -Server $s -DnsOnly -QuickTimeout -ErrorAction SilentlyContinue | Where-Object Section -eq 'Answer'
    [pscustomobject]@{ Servidor = $s; Respuesta = ($r.IPAddress | Sort-Object) -join ', ' }
}

Si las respuestas no coinciden y el registro cambió hace poco, suele ser la caché de un servidor. Si un servidor no devuelve nada, ese servidor es el problema.

Escenario 6: revisar los registros de correo de un dominio

Para un problema de correo, lo primero es ver a dónde apunta el dominio y qué servidores autoriza a enviar en su nombre:

Resolve-DnsName kharonte.com -Type MX | Where-Object Section -eq 'Answer' | Select-Object NameExchange, Preference
(Resolve-DnsName kharonte.com -Type TXT | Where-Object { $_.Strings -like 'v=spf1*' }).Strings

El registro MX de kharonte.com apunta a Microsoft 365 (mail.protection.outlook.com), y el TXT que empieza por v=spf1 lista los servicios autorizados a enviar correo.

Lo que Test-NetConnection no hace

• No prueba UDP. Test-NetConnection 1.1.1.1 -Port 53 -Udp da No se encuentra ningún parámetro que coincida con el nombre del parámetro 'Udp'. Una prueba de UDP genérica no existe, porque un puerto UDP no confirma nada si no recibe una petición que entienda. Para el DNS, Resolve-DnsName -Server hace una consulta real al puerto 53; para otros servicios UDP hay que usar el cliente del propio servicio.
• No tiene tiempo de espera. Ya se vio: hasta 21 segundos por dirección. Use Test-Connection -TimeoutSeconds en PowerShell 7 o la función del escenario 3.
• No elige la interfaz de salida de una prueba de puerto. -ConstrainInterface solo vale con -DiagnoseRouting.
• No funciona fuera de Windows. En Linux y macOS, PowerShell 7 tiene Test-Connection -TcpPort, pero no Test-NetConnection.
• No reemplaza una prueba de la aplicación. Que el puerto 443 acepte la conexión no garantiza que el sitio funcione: el certificado, el inicio de sesión o la propia aplicación pueden fallar con la red en perfecto estado.

Recomendaciones

1. Pruebe el puerto del servicio, no el ping. Es lo que confirma que el servicio está disponible para el usuario.
2. En scripts, use -InformationLevel Quiet y decida con TcpTestSucceeded. Es más rápido y evita la trampa de PingSucceeded.
3. Si conoce la dirección IP, úsela. Ahorra la espera en cada dirección del nombre y aísla el DNS como causa.
4. Para muchos puertos o equipos, ponga un límite de tiempo. Test-Connection -TcpPort -TimeoutSeconds en 7, o la función del escenario 3 en cualquier versión.
5. Haga la prueba desde el mismo lugar que el usuario. Desde su red, su VPN y su equipo. Una prueba desde el servidor no dice nada del camino que recorre el usuario.
6. Lea los avisos cuando pruebe a mano. Dicen en qué dirección falló cada intento y si el ping se agotó.
7. Guarde el resultado en el ticket. La dirección de origen, la interfaz y la hora valen más que un «no funciona».
8. Escriba para las dos versiones o diga cuál exige. Un ejemplo con -TcpPort falla en la consola de Windows PowerShell 5.1.

Errores comunes y qué significan

Mensaje	Causa	Qué hacer
TCP connect to (dirección : puerto) failed	El puerto no aceptó la conexión en esa dirección	Revisar el servicio y los firewalls; si hay un aviso por dirección, todas fallaron
Ping to dirección failed with status: TimedOut	No hubo respuesta al ping	Puede estar bloqueado a propósito: pruebe el puerto del servicio
Name resolution of nombre failed	El DNS del equipo no encuentra el nombre	Revisar el nombre y el DNS con Resolve-DnsName
'-InformationLevel Detailed' requires elevation (Run as administrator).	-DiagnoseRouting con Detailed sin permisos	Abrir PowerShell como administrador o quitar Detailed
No se encuentra ningún parámetro que coincida con el nombre del parámetro 'Udp'.	Test-NetConnection no prueba UDP	Usar el cliente del servicio o Resolve-DnsName -Server para el DNS
No se puede resolver el conjunto de parámetros usando los parámetros con nombre especificados.	Parámetros de dos modos mezclados, como -Port con -ConstrainInterface	Usar un solo modo por orden
No se encuentra ningún parámetro que coincida con el nombre del parámetro 'TcpPort'.	Test-Connection -TcpPort en Windows PowerShell 5.1	Usar PowerShell 7 o Test-NetConnection
Error de prueba de conexión con el equipo … Error debido a falta de recursos	Ping sin respuesta en Test-Connection de 5.1	Mismo diagnóstico que un ping agotado
El nombre DNS no existe	Resolve-DnsName con un dominio inexistente	Revisar el nombre; recuerde que otros servidores responden con un SOA sin error

Cuando el problema de red no es de un solo equipo

Test-NetConnection y los comandos de red en PowerShell resuelven la mayoría de las dudas de conectividad en minutos, siempre que alguien sepa qué probar y desde dónde. Cuando los cortes se repiten, afectan a varias personas o aparecen después de cada cambio, el problema suele estar en el diseño de la red: reglas de firewall que nadie documentó, VPN que se caen o segmentos mal separados.

En KHARONTE hacemos la administración de redes de oficinas, con firewall perimetral, VLAN, VPN y wifi, y nuestra mesa de ayuda TI atiende estos casos con soporte técnico remoto, que es donde estas pruebas ahorran más tiempo. Si busca servicios administrados de TI para que su equipo deje de perder mañanas con la conexión, revise nuestros servicios de TI para empresas.