Cuando un usuario dice “no tengo Internet”, “va lento” o “no me abre la intranet”, la clave no es probar cosas al azar: es seguir un método. En Windows, el símbolo del sistema (la windows command line) te permite comprobar en minutos si el problema está en tu equipo, en la red local, en el DNS, en el router, en el proxy o en el servidor.

Esta guía está pensada para Soporte TI y SysAdmin Junior: menos listado de comandos y más explicación. Aprenderás a diagnosticar incidencias típicas con una secuencia clara, con ejemplos y con interpretación de resultados. Y sí: usaremos comandos cmd redes, pero solo los necesarios.

Por qué el símbolo del sistema sigue siendo imprescindible

Aunque existan herramientas gráficas, en soporte real necesitas tres cosas: rapidez, claridad y trazabilidad.

• Rapidez: puedes probar hipótesis en segundos.

• Claridad: los resultados te dicen “qué falla” y “dónde”.

• Trazabilidad: puedes guardar la salida y adjuntarla en un ticket.

La windows command line no es “solo para frikis”: es un método de diagnóstico. Y cuanto antes lo interiorices, menos tiempo perderás.

Cómo usar esta guía: el método en 7 pasos

Piensa en una red como una cadena:

Tu PC → adaptador → IP/gateway → router/switch → salida a Internet → DNS → servicio (web, RDP, etc.)

Si algo falla, se rompe un eslabón. Esta guía te ayuda a encontrar cuál, sin suposiciones.

Paso 1: Identifica el síntoma exacto (antes de tocar nada)

Primero define qué ocurre, porque “no funciona Internet” puede significar cosas distintas:

1. No carga nada (ni intranet ni webs).

2. Carga por IP, pero no por nombre (“si pongo la IP funciona”).

3. Solo falla un servicio (RDP, una web interna, una VPN).

4. Va lento o se corta (intermitencias).

5. Solo falla por Wi-Fi (por cable va bien).

En tickets, escribe la frase como:
“Falla X, en Y, desde Z, con evidencia A.”
Ejemplo: “No abre intranet desde portátil por Wi-Fi, desde las 10:20, ping al gateway con pérdidas.”

Paso 2: Comprueba si tu PC tiene IP válida, gateway y DNS

Aquí no “diagnosticas”, aquí confirmas que tu configuración tiene sentido.
El objetivo es responder:

• ¿Tengo IP?

• ¿Tengo puerta de enlace (gateway)?

• ¿Qué DNS estoy usando?

• ¿Estoy en Wi-Fi o Ethernet?

Comando recomendado:

• ipconfig /all

Ejemplo típico de situación mala

• IP: 169.254.x.x

• Gateway: vacío
  Interpretación: el equipo no consiguió IP por DHCP. No sigas con Internet: primero resuelve DHCP o conexión física/Wi-Fi.

Ejemplo típico de situación dudosa

• IP bien (p. ej., 192.168.1.50)

• Gateway bien (192.168.1.1)

• DNS raro (uno que no es el corporativo)
  Interpretación: puede ser problema de DNS o configuración no estándar.

Decisión del paso 2:

• Si falta IP o gateway → el problema es local (adaptador, DHCP, cable, Wi-Fi).

• Si IP/gateway/DNS parecen coherentes → pasa al paso 3.

Paso 3: Verifica conectividad local (¿llego al gateway?)

Esto diferencia un fallo “en mi red local” de un fallo “hacia fuera”.

Comando recomendado:

• ping a la puerta de enlace

Qué significa cada resultado

• Responde rápido (1–5 ms por cable, variable por Wi-Fi): bien.

• Responde pero con picos altos (100–500 ms): mala señal o saturación.

• Hay pérdidas (por ejemplo 10–30%): muy mala conexión; revisa Wi-Fi, cable, switch, interferencias.

• No responde: puede ser bloqueo ICMP, pero si además “nada funciona”, suele ser caída local.

Ejemplo real (Wi-Fi saturado):
El usuario dice “se corta”. El ping al gateway da:

• tiempos normales y de repente 800 ms, luego “tiempo de espera agotado”.
  Interpretación: el enlace Wi-Fi está fallando, aunque Internet “a ratos” parezca funcionar.

Paso 4: Separa “Internet” de “DNS”: prueba salida por IP

Aquí haces una prueba clave: ¿sales a Internet aunque el nombre no resuelva?

Comando recomendado:

• ping a una IP pública conocida

Interpretación rápida

• Si por IP funciona, pero por nombre no → casi seguro es DNS.

• Si por IP no funciona → el problema es de salida (router, firewall, ISP, ruta).

Ejemplo típico de DNS roto:

• ping a IP pública: OK

• abrir “intranet.empresa.local”: falla
  Conclusión: revisa DNS, sufijo DNS, VPN, o resolución interna.

Paso 5: Diagnóstico de DNS (cuando “no encuentra el host”)

Si algo no resuelve nombres, no te quedes con la duda: valida DNS.

Comando recomendado:

• nslookup

Qué buscas

• ¿Qué servidor DNS está respondiendo?

• ¿Resuelve el nombre correctamente?

• ¿Resuelve a una IP esperada?

Ejemplo 1: DNS corporativo caído

• nslookup tarda mucho y acaba en error
  Conclusión: el DNS configurado no responde. Solución: revisar servidor, red interna, o configurar DNS alternativo según política.

Ejemplo 2: split-DNS / VPN

• Sin VPN no resuelve “intranet.local”

• Con VPN sí resuelve
  Conclusión: el DNS interno se sirve por VPN. El problema no es “Internet”, es la ruta/servicio de VPN.

Acción común (cuando hay caché vieja):

• ipconfig /flushdns
  Sirve cuando hubo cambios recientes de IP en servidores y el PC se quedó con resolución antigua.

Paso 6: Encuentra “dónde se rompe” la ruta hacia el destino

Si hay salida pero el destino no responde, necesitas saber si el bloqueo es local, en el router o en un salto intermedio.

Comandos recomendados:

• tracert (para ver saltos)

• pathping (si sospechas pérdida)

Cómo leer un tracert sin volverte loco

• Los primeros saltos son tu red: gateway y proveedor.

• Si se queda “colgado” siempre en el mismo salto, ahí hay pista.

• Los asteriscos no siempre significan caída; a veces solo indican que ese router no responde a ICMP.

Ejemplo útil:

• Ping al gateway OK.

• Ping a IP pública OK.

• tracert al servidor remoto se corta a mitad.
  Conclusión: no es tu PC. Probable problema de ruta, firewall, o red del destino.

Paso 7: Cuando falla “solo un servicio” (web, RDP, app), piensa en puertos

Muchas incidencias no son “Internet”, son puertos o reglas.

Ejemplos:

• Web interna (HTTPS 443) no abre, pero ping responde.

• RDP (3389) no conecta, pero el servidor responde a ping.

• Aplicación específica falla, otras van bien.

Aquí la pregunta es:
¿El puerto está accesible desde este equipo? y ¿el servidor tiene el puerto escuchando?

Comando recomendado en cliente (si está disponible):

• telnet host puerto (prueba TCP simple)

En el servidor (si tienes acceso):

• netstat -ano para ver si el puerto está LISTENING

• tasklist para identificar el proceso por PID

Ejemplo real: “RDP no va”

• Ping al servidor: OK

• Telnet al 3389: falla
  Conclusión: puerto bloqueado por firewall, servicio caído, o regla de red.

Casos típicos y cómo resolverlos siguiendo la guía

Caso A: “No tengo Internet”

1. ipconfig /all: ¿tienes IP y gateway?

2. ping gateway: ¿llegas al router?

3. ping IP pública: ¿sales por IP?

4. nslookup: ¿DNS responde?

Resultado típico:

• No hay gateway → DHCP o adaptador.

• Gateway OK pero no sale por IP → router/ISP/ruta.

• Sale por IP pero no por nombre → DNS.

Caso B: “Solo falla la intranet”

1. Comprueba si la intranet es por nombre interno.

2. nslookup intranet: ¿resuelve?

3. Si con VPN funciona y sin VPN no: depende del DNS/ruta de VPN.

4. Si resuelve pero no abre: es servicio/puerto (443/80) o proxy.

Caso C: “Va lento o se corta”

1. ping gateway con varias muestras (para ver pérdida).

2. Si es Wi-Fi, revisa estado de la interfaz.

3. Si hay pérdidas al gateway → problema local (Wi-Fi/cable/switch).

4. Si al gateway perfecto pero hacia fuera mal → ruta/ISP/saturación externa.

Caso D: “Solo falla por Wi-Fi”

1. Compara con cable (si posible).

2. Si por cable bien: no pierdas tiempo con DNS/servidores; céntrate en Wi-Fi.

3. Señal baja, roaming, interferencias, canal saturado: causas típicas.

Errores frecuentes (y cómo evitarlos)

• Confundir DNS con “Internet caído”.

• Reiniciar cosas sin pruebas (pierdes evidencia y tiempo).

• Hacer 10 pruebas sin orden; el orden importa.

• Quedarte en “ping no responde” sin pensar en ICMP bloqueado.

• No documentar: en soporte, la evidencia es parte del trabajo.

Checklist final para tickets (copiable)

• Síntoma exacto:

• IP/Gateway/DNS (ipconfig /all):

• Ping gateway:

• Ping IP pública:

• DNS (nslookup):

• Ruta (tracert/pathping) si aplica:

• Servicio/puerto si aplica (telnet/netstat):

• Conclusión probable:

• Acción tomada / siguiente paso:

Conclusión

Si sigues este método, dejas de “probar cosas” y empiezas a diagnosticar. El símbolo del sistema y la windows command line te dan lo que más necesitas en soporte: resultados claros, rápidos y repetibles. Con esta guía podrás resolver la mayoría de incidencias comunes de conectividad y, cuando no puedas, sabrás exactamente qué evidencia aportar al siguiente nivel.

Referencias

• Microsoft Learn. ping. Recuperado de https://learn.microsoft.com/es-es/windows-server/administration/windows-commands/ping
• Microsoft Learn. ipconfig. Recuperado de https://learn.microsoft.com/es-es/windows-server/administration/windows-commands/ipconfig
• Microsoft Learn. netstat. Recuperado de https://learn.microsoft.com/es-es/windows-server/administration/windows-commands/netstat

Protege tu empresa con nuestros monitorización y detección de amenazas. Consulta los requisitos de cumplimiento de la directiva NIS2 aplicables a tu organización. Las organizaciones sanitarias son objetivo creciente de este tipo de ataques. Refuerza la ciberseguridad para el sector sanitario de tu organización.