Diagnóstico de red en Windows Server: ping, tracert, pathping, Test-NetConnection e iperf3

Cuando un sitio web alojado en su servidor Windows va lento desde algunas ubicaciones, el Escritorio remoto se desconecta una y otra vez, o un juego o una aplicación muestra una latencia alta, la causa suele estar en algún punto de la ruta de red y no en el propio servidor. Windows incluye buenas herramientas de diagnóstico, y algunas herramientas gratuitas cubren lo que falta. Esta guía explica cómo usar ping, tracert, pathping, Test-NetConnection, WinMTR e iperf3, cómo interpretar los resultados sin sacar conclusiones erróneas y qué incluir cuando se ponga en contacto con soporte.

Paso 1: Conectividad básica y latencia con ping

# 50 pings to the server; watch the average time and the "Lost" count
ping -n 50 203.0.113.10

# Continuous ping (Ctrl+C to stop) while you reproduce the problem
ping -t 203.0.113.10

# IPv6 or a hostname
ping -6 -n 20 example.com

Unos tiempos estables con un 0 % de pérdida significan que la ruta está en buen estado en ese momento. Una pérdida de un pequeño porcentaje de paquetes o unos tiempos que saltan cientos de milisegundos indican congestión. Tenga en cuenta que algunos servidores y firewalls bloquean el ping, por lo que la falta de respuesta no siempre significa que el servidor esté caído; pruebe también un puerto como se indica en el paso 3.

Paso 2: Ver la ruta con tracert y pathping

# Hop-by-hop route without DNS lookups (faster)
tracert -d 203.0.113.10

# tracert + loss statistics for every hop (100 probes per hop, takes a few minutes)
pathping -n -q 100 203.0.113.10

Interprete los resultados con cuidado: muchos routers dan deliberadamente baja prioridad a las respuestas a los paquetes dirigidos a ellos mismos. La pérdida o la latencia alta en un salto intermedio que no continúa en los saltos siguientes ni en el destino final no es un problema. Solo la pérdida que empieza en un salto y se mantiene hasta el final indica dónde comienza el problema.

Paso 3: Probar un puerto concreto con Test-NetConnection

El ping demuestra que el servidor es accesible; una prueba de puerto demuestra que el servicio es accesible. Es la forma más rápida de distinguir un problema de red de un problema del firewall o de la aplicación.

# Is Remote Desktop / a website / SSH reachable?
Test-NetConnection 203.0.113.10 -Port 3389
Test-NetConnection example.com -Port 443 -InformationLevel Detailed

# Built-in traceroute
Test-NetConnection 203.0.113.10 -TraceRoute

# On the server: is the service actually listening?
Get-NetTCPConnection -State Listen | Where-Object LocalPort -in 80,443,3389 | Select-Object LocalAddress, LocalPort, OwningProcess

TcpTestSucceeded : True significa que el puerto está abierto de extremo a extremo. Si el ping funciona pero la prueba de puerto falla, revise el Firewall de Windows (consulte cómo abrir puertos en el Firewall de Windows) y si el servicio está en ejecución.

Paso 4: Monitoreo continuo de la ruta con WinMTR

MTR combina ping y traceroute y mide continuamente cada salto, por lo que es la mejor forma de capturar problemas intermitentes. En Windows, use WinMTR (gratuito y de código abierto): escriba la IP del servidor, haga clic en Start, déjelo funcionar al menos 2–3 minutos (idealmente mientras ocurre el problema) y use Copy text to clipboard para guardar el resultado. Interprételo igual que pathping: solo importa la pérdida que se mantiene hasta el último salto. Si dispone de una máquina Linux, consulte mtr, traceroute e iperf3 en Linux.

Paso 5: Medir el ancho de banda con iperf3

Las pruebas de latencia no muestran la velocidad de transferencia. iperf3 mide la velocidad real entre dos máquinas. Descargue la versión de iperf3 para Windows, descomprímala y, en el servidor, abra temporalmente el puerto en el firewall:

# On the server: allow the test port, then start the iperf3 server
New-NetFirewallRule -DisplayName "iperf3 test" -Direction Inbound -Protocol TCP -LocalPort 5201 -Action Allow
.\iperf3.exe -s

# On the client: upload test, then download test (-R), 4 parallel streams, 20 seconds
.\iperf3.exe -c 203.0.113.10 -P 4 -t 20
.\iperf3.exe -c 203.0.113.10 -P 4 -t 20 -R

# Afterwards, remove the temporary rule
Remove-NetFirewallRule -DisplayName "iperf3 test"

Un solo flujo a larga distancia suele ser más lento que la velocidad del puerto debido a la latencia; compare los resultados con -P 4 o -P 8 antes de concluir que el ancho de banda está limitado.

Paso 6: Comprobar DNS, rutas y MTU

# DNS: compare your resolver with a public one, and clear the local cache
Resolve-DnsName example.com
Resolve-DnsName example.com -Server 1.1.1.1
ipconfig /flushdns

# IP configuration and routing table on the server
ipconfig /all
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 10

# MTU: the largest packet that passes without fragmentation (1472 + 28 = 1500)
ping -f -l 1472 203.0.113.10
ping -f -l 1400 203.0.113.10

Si 1472 falla con "Packet needs to be fragmented but DF set" mientras que los tamaños menores funcionan, algún punto de la ruta usa una MTU menor; esto puede hacer que las páginas o las descargas se queden colgadas aunque las solicitudes pequeñas funcionen.

Paso 7: Qué enviar a soporte

Para que un problema de ruta se resuelva rápidamente, incluya en su ticket:

• La IP del servidor, su propia IP pública (obtenida en un sitio del tipo "cuál es mi IP"), y su ciudad y proveedor de Internet.
• Un resultado de WinMTR o pathping desde su lado hacia el servidor y, si es posible, otro desde el servidor hacia su IP.
• La hora en que ocurrió el problema (con la zona horaria) y si es constante o solo ocurre a ciertas horas.
• Para problemas de velocidad, los resultados de iperf3 en ambos sentidos.

Consulte también cómo enviar un ticket al soporte técnico de IMIDC.

Preguntas frecuentes

¿tracert muestra "Request timed out" en algunos saltos?

Esos routers simplemente no responden a las sondas de traceroute. Si los saltos siguientes y el destino responden con normalidad, la ruta está bien.

¿La velocidad es buena de madrugada, pero baja por la noche?

Es la congestión típica de los enlaces internacionales o de su proveedor de Internet en las horas de mayor tráfico. Haga pruebas en ambos momentos e inclúyalas en su ticket; una ruta con mejor rendimiento en esas horas (por ejemplo, una ruta premium hacia China) puede ser la solución.

¿El ping funciona, pero el Escritorio remoto no se conecta?

La ruta de red está bien; el puerto está bloqueado o el servicio no responde. Siga la solución de problemas de Escritorio remoto.

¿Sigue sin resolverlo después de seguir estos pasos? Abra un ticket de soporte y el equipo técnico de IMIDC, disponible 24/7, le ayudará. Incluya la IP del servidor, su IP pública y su ubicación, y los resultados de WinMTR, pathping o iperf3 para que podamos localizar el problema más rápido.