Windows muestra “Conectado, sin Internet”? Arréglalo sin restablecerlo todo

Playbook de diagnóstico rápido (primeros 3 minutos)

Este es el orden que uso cuando alguien me avisa “internet caído” y necesito la verdad rápido. Estamos cazando el cuello de botella: enlace, IP, ruta, DNS, política o la propia detección de Windows.

1) ¿La red está realmente caída o Windows solo se queja?

• Abrir un navegador a un sitio HTTPS conocido. Si carga, tu internet funciona; el estado de Windows puede estar equivocado (a menudo NCSI/proxy/VPN). Pasa a las comprobaciones de NCSI/proxy.
• Probar con un ping a una IP (por ejemplo una IP pública de DNS). Si la IP responde pero los nombres no, es DNS.

2) Confirma que tienes IP, gateway y rutas sensatas

• Revisa la configuración IP: ¿tienes una dirección distinta de APIPA (no 169.254.x.x), una puerta de enlace por defecto y servidores DNS?
• Revisa la tabla de rutas: ¿hay una ruta por defecto (0.0.0.0/0) hacia la interfaz correcta?

3) Decide qué capa está rota

• Sin IP / APIPA: problema de DHCP o L2.
• IP pero sin ruta por defecto: problema de gateway/ruta, frecuentemente métrica de VPN, ICS o confusión de adaptadores.
• IP + ruta pero falla DNS: servidor DNS inaccesible, DoH/NRPT/política, o interceptación por portal cautivo.
• Todo funciona excepto el estado de Windows: NCSI bloqueado/modificado por proxy, firewall o endurecimiento.

No “restablezcas todo” hasta que puedas decir cuál de estos está fallando. Si no, solo estás añadiendo entropía. La entropía siempre gana; tiene mejor financiación.

Qué significa realmente “Conectado, sin Internet”

Windows muestra “Conectado, sin Internet” cuando cree que tu ruta de red hacia Internet público está rota. Esa creencia se basa en parte en NCSI (Network Connectivity Status Indicator), un componente que realiza comprobaciones de conectividad.

Dos puntos clave que ahorran horas:

• El mensaje puede estar equivocado. Puedes tener internet funcionando mientras Windows afirma que no (común con proxies, VPNs, firewalls estrictos y cierto filtrado DNS).
• El mensaje puede ser correcto por la razón equivocada. Por ejemplo, tu red local funciona bien, pero el DNS está roto—Windows lo etiqueta como “sin Internet” y muchas apps actúan como si estuvieras desconectado.

Debajo del capó, a Windows le importan varias capas:

• Capa 1–2: estado del enlace (asociación Wi‑Fi, enlace Ethernet).
• Capa 3: dirección IP, subred, puerta de enlace por defecto y enrutamiento.
• Capas 4–7: accesibilidad DNS, acceso HTTP/HTTPS (incluida la detección de portales cautivos), comportamiento del proxy.
• Política y seguridad: reglas de firewall, kill switches de VPN, seguridad endpoint empresarial y afinamientos “útiles”.

Una cita para tener a mano cuando te tiente aplicar soluciones a lo loco: “La esperanza no es una estrategia.” — Gene Kranz

Broma #1: La red de Windows es como una reunión de comité—todos tienen una opinión y ninguno se habla entre sí.

Datos interesantes y contexto histórico (por qué sigue ocurriendo)

Estos son hechos cortos y concretos que hacen que el problema “conectado, sin Internet” sea menos místico y más predecible:

1. NCSI llegó con los cambios de red de la era Vista. Windows empezó a sondear activamente la conectividad a Internet en lugar de confiar solo en el estado del enlace.
2. “No Internet, secured” se refiere mayormente a la seguridad del Wi‑Fi, no de Internet. La etiqueta “secured” alude al cifrado del enlace Wi‑Fi (WPA2/WPA3), no a si la ruta de Internet es usable.
3. Los portales cautivos rompen el comportamiento normal a propósito. Muchas redes de hoteles/invitados interceptan DNS/HTTP hasta que aceptas términos; el HTTPS moderno complica aún más ese desorden.
4. APIPA (169.254.0.0/16) es el fallback de Windows cuando falla DHCP. Mantiene comunicación en enlace local pero normalmente significa sin gateway, sin Internet.
5. WPAD para descubrimiento automático de proxy ha sido un pilar corporativo—y un dolor recurrente. Un WPAD mal configurado puede romper la navegación mientras los pings siguen funcionando.
6. Los “kill switches” de VPN están diseñados para causar cortes. Su función es bloquear tráfico si el túnel cae, y a menudo parecen exactamente “sin Internet”.
7. Windows mantiene métricas por interfaz para preferencia de rutas. Una interfaz “más rápida” o la VPN puede robar la ruta por defecto aunque no deba.
8. El caché de DNS es tanto una característica de rendimiento como un amplificador de fallos. Respuestas malas pueden persistir hasta que expire el TTL o se vacíe la caché.
9. IPv6 es frecuentemente culpado, muchas veces incorrectamente. IPv6 roto en una red puede perjudicar, pero desactivarlo es una solución burda que puede romper configuraciones empresariales modernas.

Tareas prácticas con comandos: qué ejecutar, qué significa, qué hacer después

Estas tareas están diseñadas para ejecutarse en una máquina Windows, pero las presento en un estilo de terminal para que puedas copiar los comandos exactamente. Cada tarea incluye: comando, ejemplo de salida, qué significa y la decisión siguiente.

Task 1: Check IP, gateway, and DNS in one shot

cr0x@server:~$ ipconfig /all
Windows IP Configuration

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection
   Physical Address. . . . . . . . . : 00-11-22-33-44-55
   DHCP Enabled. . . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.24.18.73(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 10.24.16.1
   DHCP Server . . . . . . . . . . . : 10.24.16.10
   DNS Servers . . . . . . . . . . . : 10.24.0.53
                                       10.24.0.54

Qué significa: Tienes una dirección IPv4 real, una puerta de enlace y servidores DNS. Si Internet sigue “caído”, el problema probablemente sea enrutamiento, accesibilidad DNS, proxy/VPN, firewall o NCSI.

Decisión: Si ves 169.254.x.x o no hay puerta de enlace por defecto, ve a soluciones de DHCP/L2. Si los servidores DNS están vacíos o son extraños (por ejemplo una IP estática antigua), corrígelo primero.

Task 2: Detect APIPA (DHCP failure) quickly

cr0x@server:~$ ipconfig
Windows IP Configuration

Ethernet adapter Ethernet:
   IPv4 Address. . . . . . . . . . . : 169.254.77.12
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :

Qué significa: DHCP no te entregó una dirección. Te estás autoasignando. Esto no es un “problema de Internet”; es un problema de “nunca me conecté a la red”.

Decisión: Revisa el cable/autenticación Wi‑Fi/VLAN y luego renueva DHCP. En entornos corporativos, sospecha 802.1X o el perfil del puerto del switch.

Task 3: Renew DHCP lease (without resetting the world)

cr0x@server:~$ ipconfig /release
Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

Qué significa: Windows piensa que la interfaz está desconectada (o el cable está desconectado, o el Wi‑Fi está apagado). Ese es tu primer modo de fallo: enlace.

Decisión: Arregla el enlace físico / la asociación Wi‑Fi antes de hacer algo elegante.

cr0x@server:~$ ipconfig /renew
Windows IP Configuration

Ethernet adapter Ethernet:
   Connection-specific DNS Suffix  . : corp.example
   IPv4 Address. . . . . . . . . . . : 10.24.18.73
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 10.24.16.1

Qué significa: DHCP tuvo éxito. Estás de vuelta en funcionamiento en L3.

Decisión: Si Internet sigue fallando, sigue a comprobaciones de enrutamiento/DNS/proxy.

Task 4: Ping the default gateway (is your local network alive?)

cr0x@server:~$ ping 10.24.16.1

Pinging 10.24.16.1 with 32 bytes of data:
Reply from 10.24.16.1: bytes=32 time=1ms TTL=64
Reply from 10.24.16.1: bytes=32 time=1ms TTL=64

Ping statistics for 10.24.16.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss)

Qué significa: Tu equipo puede alcanzar la puerta de enlace. L2/L3 en el segmento local se ve bien.

Decisión: Si el ping a la gateway falla, investiga aislamiento Wi‑Fi, mismatch de VLAN, puerto de switch malo o reglas locales de firewall que bloqueen ICMP (menos común en gateways, pero posible).

Task 5: Ping an external IP (bypass DNS)

cr0x@server:~$ ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=18ms TTL=56

Ping statistics for 1.1.1.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss)

Qué significa: El enrutamiento hacia Internet funciona al menos para ICMP. Si los sitios web fallan, probablemente sea DNS, proxy, interceptación TLS o firewall.

Decisión: Prueba inmediatamente la resolución DNS y la conectividad HTTPS a continuación.

Task 6: DNS resolution test (simple and decisive)

cr0x@server:~$ nslookup example.com
Server:  dns1.corp.example
Address:  10.24.0.53

Non-authoritative answer:
Name:    example.com
Addresses:  93.184.216.34

Qué significa: DNS responde y devuelve datos sensatos.

Decisión: Si DNS está bien pero la navegación falla, sospecha proxy/VPN/firewall o problemas de certificados. Si nslookup agota el tiempo, sospecha accesibilidad DNS o política.

cr0x@server:~$ nslookup example.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

DNS request timed out.
    timeout was 2 seconds.

Qué significa: Tu red puede bloquear DNS público (común en empresas y algunos ISPs), o no puedes alcanzar ese resolvedor por reglas de enrutamiento/VPN.

Decisión: No “arregles” poniendo DNS público en una red corporativa a menos que disfrutes tickets de soporte. En su lugar, restaura el acceso a los servidores DNS previstos.

Task 7: Check the route table for a default route

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        10.24.16.1     10.24.18.73     25
        10.24.16.0    255.255.252.0        On-link      10.24.18.73    281

Qué significa: Tienes una ruta por defecto vía tu gateway. Bien.

Decisión: Si la ruta 0.0.0.0 falta o apunta a una interfaz VPN inesperada, ahí tienes al culpable.

Task 8: Verify which interface Windows prefers (metrics matter)

cr0x@server:~$ netsh interface ipv4 show interfaces
Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  12          5        1400  connected     CorpVPN
  10         25        1500  connected     Ethernet

Qué significa: Gana la métrica más baja. Aquí, la VPN es preferida y puede estar robando la ruta por defecto.

Decisión: Si la VPN está caída/medio conectada o bloqueada, desconéctala o corrige la política de split tunneling. Si es intencional, detente aquí y escala con quien gestione la configuración de la VPN.

Task 9: Check WinHTTP proxy settings (the invisible kind)

cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:

    Proxy Server(s) : 127.0.0.1:8080
    Bypass List     : (none)

Qué significa: Los servicios del sistema (incluyendo algunos componentes Microsoft) pueden intentar acceder a Internet vía un proxy local que ya no exista.

Decisión: Si no configuraste esto explícitamente (o tu agente de seguridad quitó su proxy local), restablece el proxy WinHTTP a directa.

cr0x@server:~$ netsh winhttp reset proxy
Current WinHTTP proxy settings:

    Direct access (no proxy server).

Qué significa: HTTP a nivel sistema ahora sale directamente.

Decisión: Vuelve a probar NCSI y problemas de inicio de sesión de Microsoft. Si la política corporativa requiere un proxy, no “arregles” saltándotelo—obtén la configuración correcta.

Task 10: Check user-level proxy (Settings/Internet Options equivalent)

cr0x@server:~$ reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
    ProxyEnable    REG_DWORD    0x1

Qué significa: El proxy a nivel usuario está activado.

Decisión: Si no estás en una red que lo necesite, desactívalo. Si lo estás, confirma que el valor del servidor proxy y la lista de excepciones son correctos.

Task 11: Test HTTP reachability without a browser (proxy/captive portal clues)

cr0x@server:~$ powershell -NoProfile -Command "Invoke-WebRequest -UseBasicParsing -Uri http://www.msftconnecttest.com/connecttest.txt | Select-Object -ExpandProperty StatusCode"
200

Qué significa: Puedes alcanzar el endpoint HTTP que Windows suele usar para la detección de conectividad.

Decisión: Si esto devuelve 200 pero Windows sigue diciendo “sin Internet”, sospecha problemas en la sonda HTTPS, manipulación DNS o ajustes/política de NCSI.

cr0x@server:~$ powershell -NoProfile -Command "Invoke-WebRequest -UseBasicParsing -Uri http://www.msftconnecttest.com/connecttest.txt | Select-Object -ExpandProperty Content"
Microsoft Connect Test

Qué significa: El contenido de la respuesta es correcto. Los portales cautivos suelen devolver una página HTML de inicio de sesión en su lugar.

Decisión: Si obtienes HTML o redirecciones, estás detrás de un portal cautivo. Autentícate (o pregunta a tu equipo de red por qué una SSID “corporativa” tiene uno).

Task 12: Flush DNS cache (fix stale/bad answers)

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Qué significa: Se han borrado las entradas cacheadas del DNS.

Decisión: Si la resolución de nombres funciona de pronto, tu problema era caché obsoleta o un evento temporal de envenenamiento DNS (mala configuración o portal cautivo). Si no cambia nada, sigue investigando.

Task 13: Reset Winsock (targeted “TCP/IP plumbing” fix)

cr0x@server:~$ netsh winsock show catalog
Catalog entry #0000000001
------------------------------------------------------------
Entry Type:  Provider
Description: MSAFD Tcpip [TCP/IP]
...output truncated...

Qué significa: Estás inspeccionando el catálogo Winsock (donde antiguamente LSPs enganchaban tráfico). El software de seguridad a veces atasca esto.

Decisión: Si sospechas que el stack de red está roto tras desinstalar una VPN/AV, haz un reset de Winsock. Espera un reinicio.

cr0x@server:~$ netsh winsock reset
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Qué significa: Winsock se ha restablecido a los valores por defecto.

Decisión: Reinicia y vuelve a probar. Si el agente endpoint corporativo depende de un componente tipo LSP, coordina con IT antes de hacer esto en máquinas gestionadas.

Task 14: Reset TCP/IP stack (still not “reset everything”)

cr0x@server:~$ netsh int ip reset
Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Restart the computer to complete this action.

Qué significa: Has restablecido parámetros clave de TCP/IP a valores por defecto.

Decisión: Es una buena solución en etapas finales para corrupción/malconfiguración. Si dependes de IPs estáticas o rutas personalizadas, documéntalas primero.

Task 15: Check whether a VPN created persistent routes

cr0x@server:~$ route print -4
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.10.0.1     10.10.0.55      1
         10.10.0.0    255.255.0.0         On-link       10.10.0.55    261

Qué significa: La ruta por defecto apunta a una gateway 10.10.0.1 (probablemente un adaptador virtual VPN). Si la VPN está desconectada pero la ruta permanece, tendrás “sin Internet” rápido.

Decisión: Desconecta/reconecta la VPN limpiamente, o elimina la ruta persistente si estás seguro de que está mal. En endpoints gestionados, escala; no luches contra tu cliente VPN con una pala.

Task 16: Check Windows Firewall profile and state

cr0x@server:~$ netsh advfirewall show allprofiles state

Domain Profile Settings:
State                                 ON

Private Profile Settings:
State                                 ON

Public Profile Settings:
State                                 ON

Qué significa: El firewall está activado (eso es normal). Esto por sí solo no explica “sin Internet”, pero las reglas sí pueden.

Decisión: Si un producto de seguridad cambió reglas recientemente, prueba deshabilitando temporalmente solo si está permitido. Preferible revisar reglas o logs de seguridad; deshabilitar a ciegas es como ganarte un incidente posterior.

Task 17: Check for name resolution policy / NRPT (common with VPN split DNS)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Format-Table -AutoSize"

Namespace          NameServers     DirectAccessDNS
---------          -----------     ---------------
.corp.example      {10.24.0.53}    False

Qué significa: Las consultas para ciertos namespaces están forzadas a servidores DNS específicos. Genial cuando es correcto; desastroso cuando la VPN no está realmente enroutando hacia esos servidores.

Decisión: Si NRPT apunta a DNS inaccesible, obtendrás “algunos sitios funcionan, otros no”. Arregla el enrutamiento de la VPN o actualiza la política; no elimines NRPT a menos que controles la política.

Task 18: Validate which DNS servers are actually in use per interface

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"

InterfaceAlias  ServerAddresses
--------------  ---------------
Ethernet        {10.24.0.53, 10.24.0.54}
CorpVPN         {10.99.0.10}

Qué significa: Diferentes adaptadores pueden tener distintos servidores DNS. Windows podría elegir el DNS “equivocado” para consultas generales dependiendo de métricas y políticas.

Decisión: Si el DNS de la VPN es inaccesible (túnel caído) pero preferido, experimentarás fallos de nombres. Corrige la métrica/preferencia o repara el túnel.

Portales cautivos y rarezas del Wi‑Fi corporativo

Los portales cautivos son los clásicos productores de “Conectado, sin Internet” porque se sitúan entre tú y la Internet y dicen: “Claro, puedes conectarte… después de que aceptes este checkbox redactado por un abogado.” Windows intenta detectar esto y mostrar una página de inicio de sesión, pero las redes modernas y las herramientas de seguridad pueden bloquear el mecanismo.

Cómo reconocer un portal cautivo (sin adivinar)

• El DNS funciona, pero HTTP devuelve contenido inesperado. Tu prueba de conexión devuelve HTML en lugar del texto plano esperado.
• Los sitios HTTPS fallan con avisos de certificado o nunca cargan. Los portales no pueden interceptar HTTPS moderno sin hacer cosas desagradables.
• Sólo algunas apps fallan. Aplicaciones que usan pinning TLS estricto rechazarán el tráfico interceptado.

Qué hacer

• Usa una URL HTTP simple (sí, a propósito) solo para activar el portal y autenticarte. Después vuelve a HTTPS como persona civilizada.
• Desactiva la VPN temporalmente si el portal necesita que tu tráfico no vaya por el túnel. Muchas VPNs bloquean los flujos de portal cautivo por diseño.
• No pongas DNS públicos hardcodeados para “arreglar” un portal. Algunos portales dependen de la interceptación DNS; solo lo harás más raro.

VPNs, proxies y funciones “de seguridad” que te dejan cojo

Muchos casos de “sin Internet” no son cortes. Son política. Política aplicada a medias, obsoleta o configurada para una red en la que ya no estás.

Modos de fallo de VPN que parecen “sin Internet”

• Secuestro de ruta por defecto: la VPN se convierte en la ruta preferida pero el túnel no pasa tráfico realmente.
• Desajuste de DNS en split tunnel: las consultas DNS van al DNS de la VPN, pero la VPN no enruta hacia él (o el servidor DNS te bloquea).
• Kill switch activado: el cliente VPN bloquea todo el tráfico cuando se desconecta. No es un bug; es una característica con filo.
• Política NRPT obsoleta: búsquedas por sufijo de dominio forzadas a servidores inalcanzables, rompiendo apps internas y a veces el inicio de sesión de Windows.

Modos de fallo de proxy que parecen “sin Internet”

• WinHTTP proxy dejado atrás tras desinstalar una herramienta de seguridad, de modo que los servicios del sistema no alcanzan la web.
• Proxy de usuario activado con un PAC malo o un hostname de proxy muerto.
• Configuración de autodetección (WPAD) descubre un proxy en una red y luego lo sigue intentando en otra donde no existe.

Broma #2: Un servidor proxy es como ese compañero que insiste en estar en copia—hasta que se va de vacaciones y tu correo deja de funcionar.

Controladores, ahorro de energía y la violencia silenciosa de la “optimización”

Si estás en un portátil, hay una probabilidad no nula de que Windows esté haciendo “gestión de energía” a tu adaptador de red. Los proveedores también envían controladores que se comportan perfectamente en laboratorio y de forma extraña en el mundo real, especialmente tras ciclos de suspensión/reanudación.

Patrones de fallo que gritan “controlador/energía”

• Internet muere después de salir de suspensión, pero un reinicio lo arregla.
• Ethernet aparece conectado, pero no fluye tráfico hasta que desactivas/activas el adaptador.
• Wi‑Fi se conecta y luego cae a “sin Internet” mientras la señal es fuerte.

Qué hacer (y qué evitar)

• Prefiere volver a un controlador conocido y bueno si el problema empezó tras una actualización. Nuevo no siempre es mejor; a veces solo es más nuevo.
• Evita desactivar IPv6 como solución inicial. Puede enmascarar el síntoma y romper servicios empresariales, comportamiento moderno de DNS y la resolución futura de problemas.
• Revisa la configuración de energía del adaptador si el problema está relacionado con suspensión. Si tu imagen corporativa impone esto por política, arréglalo de forma central.

Tres microhistorias corporativas desde el terreno

1) El incidente causado por una suposición errónea: “Si DHCP funciona, Internet funciona”

Una compañía mediana tenía una queja recurrente: cada pocos días, un piso aleatorio reportaba “Conectado, sin Internet.” El script de helpdesk era predecible: reiniciar el punto de acceso, pedir a los usuarios que reinicien y seguir. “Funcionaba”, lo que es otra forma de decir que nadie aprendió nada.

Cuando SRE fue llamado, la primera suposición que cuestionaron fue la clásica: DHCP exitoso implica red usable. Los usuarios tenían direcciones, gateways y DNS. Los pings al gateway funcionaban. Los pings a IPs externas funcionaban. DNS también respondía. Aun así los navegadores fallaban.

La pieza faltante: el proxy corporativo era obligatorio para el egress web, y el proxy dependía de un archivo PAC servido desde un host interno. Ese nombre resolvía vía DNS, pero el puerto del proxy estaba intermitentemente bloqueado por una política firewall mal aplicada en una ACL de un switch de distribución. Así que la red “funcionaba” y la Internet “funcionaba”, pero la web no—y Windows lo interpretó como “sin Internet.”

La solución no fue un rediseño grandioso. Fue aburrida: alinear las ACLs entre switches, monitorizar la alcanzabilidad del puerto del proxy y enseñar al soporte a probar alcanzabilidad del proxy en vez de solo ping. La suposición errónea convirtió un bug de política sencillo en meses de “apagones fantasma”.

2) La optimización que se volvió contra ellos: “Forcemos DNS público para consultas más rápidas”

Un equipo de TI se cansó de quejas por latencia de DNS interno. Alguien propuso una optimización simple: aplicar un GPO que ponga en los clientes servidores DNS públicos conocidos “por rendimiento.” Se desplegó sin mucho ruido, porque ¿quién necesita gestión de cambios para DNS, verdad?

En un día, laptops Windows empezaron a reportar “Conectado, sin Internet” en la oficina—mientras algunos sitios cargaban y las apps internas no. El patrón fue caótico: los recién llegados estaban bien, los veteranos no, y los usuarios VPN lo sufrieron más.

La realidad: el firewall empresarial bloqueaba DNS saliente hacia Internet por política. Los clientes forzados a DNS públicos no podían resolver nada salvo que estuvieran en una red permisiva. Mientras tanto, zonas internas que solo existían en el DNS corporativo dejaron de resolverse por completo, rompiendo flujos de inicio de sesión, descubrimiento de impresoras y portales internos. La detección de conectividad de Windows también falló porque la resolución de nombres y la accesibilidad HTTP eran inconsistentes.

El rollback fue doloroso porque tuvo que hacerse rápido y “solo volver a ponerlo” chocó con usuarios en roaming y configuraciones en caché. La conclusión fue clara: no optimices una dependencia evadiendo el sistema diseñado para proveerla. Arregla el rendimiento y la resiliencia del DNS interno—cachea, escala, monitoriza—sin convertir a los clientes en pequeños resolutores renegados.

3) La práctica aburrida pero correcta que salvó el día: líneas base conocidas y dos pruebas

Una organización global tenía una práctica pequeña pero disciplinada de redes: cada oficina tenía una configuración de endpoint “conocida y buena” documentada para Ethernet y Wi‑Fi, más dos pruebas estándar: (1) ping a la puerta de enlace por defecto, (2) resolver y obtener un archivo de prueba de conectividad vía HTTP. No eran glamorosas. Eran consistentes.

Una mañana, un sitio reportó “Conectado, sin Internet” en varios equipos. La gente empezó a culpar al ISP, luego a las actualizaciones de Windows, luego a la máquina de café (injusto). El ingeniero de guardia pidió las dos pruebas. El ping a la gateway pasó. La obtención HTTP devolvió una página HTML en lugar del texto esperado.

Eso lo redujo inmediatamente: portal cautivo o interceptación. La oficina no usaba portal cautivo. Resultó que una nueva política de un appliance de seguridad se había empujado durante la noche, redirigiendo agentes de usuario desconocidos a una página de autenticación. La sonda NCSI de Windows ahora era tratada como “desconocida” y fue redirigida, así que Windows declaró sin Internet. Algunos navegadores funcionaban porque solicitaban autenticación de forma distinta; algunas apps fallaban porque esperaban respuestas HTTP limpias.

La solución fue una regla allow simple para los endpoints de comprobación de conectividad y una excepción de política para clientes gestionados. No se resolvió por genialidad. Se resolvió porque existía una línea base y dos pruebas que separaron “red caída” de “detección rota” en minutos.

Errores comunes: síntoma → causa raíz → solución

Estos son los reincidentes. Léelos como una guía de campo.

1) “Conectado, sin Internet” pero los sitios web cargan bien

• Síntoma: El navegador funciona; el icono de Windows indica sin Internet; algunas apps de Microsoft se quejan.
• Causa raíz: Sondas NCSI bloqueadas/redirigidas por proxy, firewall, filtrado DNS o fallo en la detección de portal cautivo.
• Solución: Prueba el archivo de conectividad vía PowerShell. Revisa el proxy WinHTTP. En entornos corporativos, solicita allowlist para endpoints NCSI y la configuración correcta del proxy.

2) Dirección IP es 169.254.x.x

• Síntoma: La conexión local aparece como conectada; sin Internet; a veces “Red no identificada”.
• Causa raíz: Falla DHCP (sin respuesta, bloqueado, VLAN equivocada, fallo 802.1X).
• Solución: Renueva DHCP; revisa el enlace; prueba otro puerto/SSID; en corporativo, valida el perfil del puerto del switch y los logs de autenticación.

3) El ping a 1.1.1.1 funciona, pero DNS falla

• Síntoma: La conectividad IP existe; nslookup agota el tiempo.
• Causa raíz: Servidor DNS inalcanzable, DNS saliente bloqueado, servidor DNS mal configurado, DNS de VPN seleccionado con túnel caído.
• Solución: Revisa ipconfig /all y Get-DnsClientServerAddress. Corrige el DNS a lo que la red espera; arregla enrutamiento/métricas de la VPN.

4) Solo fallan sitios internos, Internet público funciona

• Síntoma: Google carga; portal interno no; a veces hay VPN involucrada.
• Causa raíz: Split DNS/NRPT mal configurado, o DNS interno solo accesible vía VPN.
• Solución: Conéctate a la VPN correctamente; verifica políticas NRPT y accesibilidad DNS; no “arregles” usando DNS público.

5) Internet muere después de suspensión/hibernación

• Síntoma: Funciona tras reinicio; falla tras despertar; desactivar/activar adaptador ayuda.
• Causa raíz: Bug de controlador o gestión de energía del adaptador, a veces agravado por estado del cliente VPN.
• Solución: Actualiza o retrocede el controlador; desactiva ahorro de energía agresivo para el adaptador; asegura que el cliente VPN maneje la reanudación.

6) “Sin Internet” aparece solo cuando está instalada una VPN (incluso desconectada)

• Síntoma: Quitar la VPN “lo arregla”; de lo contrario el enrutamiento es extraño.
• Causa raíz: Rutas persistentes, drivers filtro o kill switch aún activo.
• Solución: Inspecciona la tabla de rutas y métricas de interfaz; repara o reinstala el cliente VPN limpiamente; escala si la política del kill switch está aplicada.

7) Ethernet dice conectado, pero no hay tráfico

• Síntoma: Luces de enlace encendidas; ping al gateway falla; DHCP puede o no funcionar.
• Causa raíz: VLAN equivocada en el puerto del switch, seguridad de puerto, fallo 802.1X o problemas de negociación del controlador.
• Solución: Prueba otro puerto/cable; en corporativo, valida la autenticación del puerto de switch y la asignación de VLAN; considera forzar velocidad/duplex solo como último recurso.

8) Arreglarlo deshabilitando IPv6 “funciona” pero vuelve a aparecer

• Síntoma: Desactivar IPv6 da alivio temporal.
• Causa raíz: Enrutamiento/DNS IPv6 roto en la red, o RA mal configurado. Deshabilitar IPv6 solo fuerza IPv4 y oculta el problema real.
• Solución: Corrige la configuración IPv6 de la red (router advertisements, manejo de AAAA, firewall). En un endpoint, prefiere corregir DNS/gateway en lugar de desactivar una pila de protocolos.

Listas de verificación / plan paso a paso (sin destruirlo todo)

Este es el plan que le daría a un administrador competente o a un power user testarudo. Escala con cuidado.

Checklist A: Verifica lo básico (2–5 minutos)

1. Confirma que estás conectado al SSID o puerto Ethernet correcto (no a una VLAN de invitados).
2. Ejecuta ipconfig /all. Anota: dirección IPv4, puerta de enlace por defecto, servidores DNS.
3. Pinga la puerta de enlace por defecto.
4. Pinga una IP pública (ejemplo: 1.1.1.1).
5. Ejecuta nslookup example.com.

Punto de decisión:

• Si DHCP falla (APIPA), para y arregla DHCP/L2/802.1X.
• Si la IP funciona pero DNS falla, arregla DNS o la selección DNS de la VPN.
• Si DNS funciona pero la web falla, revisa proxy/VPN/firewall/portal cautivo.

Checklist B: Atrapa a los culpables habituales (5–10 minutos)

1. Revisa el proxy WinHTTP: netsh winhttp show proxy. Restablece si está mal.
2. Revisa el proxy de usuario mediante el registro (o Configuración): confirma que ProxyEnable tenga sentido.
3. Revisa métricas de interfaz: netsh interface ipv4 show interfaces.
4. Inspecciona la tabla de rutas: route print buscando sorpresas en la ruta por defecto.
5. Prueba la sonda de conectividad de Windows vía PowerShell Invoke-WebRequest al archivo de prueba de conexión.

Checklist C: Repara el stack (10–20 minutos, daño controlado)

1. Vacía DNS: ipconfig /flushdns.
2. Libera/renueva: ipconfig /release luego ipconfig /renew.
3. Restablece Winsock: netsh winsock reset (reinicio).
4. Restablece la pila IP: netsh int ip reset (reinicio).

Punto de decisión: Si esto no ayuda, el problema probablemente sea externo (política de red, backend de VPN, proxy, firewall, portal cautivo, bug de controlador). No sigas randomizando tu endpoint.

Checklist D: Sanidad de controladores y energía (varía)

1. Si el problema empezó tras una actualización de controlador, vuelve al controlador anterior.
2. Si está relacionado con suspensión, ajusta la configuración de energía del adaptador.
3. Si usas un dongle Ethernet USB/dock, prueba otro puerto o conexión directa; los docks pueden comportarse como pequeños routers con sentimientos.

Preguntas frecuentes (FAQ)

1) ¿Por qué Windows dice “Sin Internet” cuando puedo navegar?

Porque Windows ejecuta un mecanismo de detección de conectividad (NCSI) que puede estar bloqueado o redirigido. La navegación puede funcionar vía DNS cacheado, comportamiento diferente del proxy o apps que usan rutas distintas.

2) ¿Cuál es la forma más rápida de saber si es DNS?

Pinga una IP pública (prueba de enrutamiento), luego ejecuta nslookup example.com (prueba DNS). IP funciona + DNS falla = problema de DNS o accesibilidad DNS.

3) ¿Es “Restablecer red” una buena solución?

A veces. Pero es destructivo: elimina redes guardadas, adaptadores/perfiles VPN, DNS/rutas personalizados y puede romper autenticación empresarial. Usa restablecimientos dirigidos (winsock, int ip) primero.

4) ¿Debería desactivar IPv6?

No como primer paso. IPv6 roto en una red puede causar problemas reales, pero desactivar IPv6 en el cliente suele ocultar la mala configuración subyacente y puede romper funciones corporativas y modernas de Windows.

5) ¿Por qué el problema ocurre solo en Wi‑Fi corporativo y no en casa?

Las redes corporativas suelen aplicar proxies, bloquear DNS público, requerir 802.1X y aplicar comprobaciones de postura del endpoint. Una red doméstica es básicamente una anarquía amigable en comparación.

6) ¿Por qué fallan apps Microsoft (Store, OneDrive, Teams) mientras el navegador funciona?

Los componentes del sistema a menudo usan configuraciones de proxy WinHTTP y rutas TLS/proxy diferentes a las del navegador. Un ajuste WinHTTP incorrecto puede romperlos mientras Chrome/Edge continúa con sus propias configuraciones.

7) Estoy en una VPN. ¿Por qué pierdo internet cuando la VPN cae?

Eso suele ser un kill switch o política de enrutamiento: cuando el túnel muere, el cliente bloquea el tráfico para evitar fugas. La solución es ajustar la política de la VPN, no “arreglar” Windows.

8) ¿Cómo sé si un portal cautivo es el problema?

Obtén un archivo HTTP conocido y revisa el contenido. Si recibes una página HTML de inicio de sesión o redirecciones en lugar del texto esperado, estás detrás de un portal.

9) ¿Por qué reiniciar a veces “lo arregla”?

Reiniciar borra estados transitorios: rutas atascadas, servicios VPN colgados, estado de driver después de suspensión y caché DNS. No cura; es un reinicio de estado que puede ocultar la causa real.

10) ¿Cuándo debo escalar a IT/red en lugar de seguir intentando?

Si tienes una IP válida, puedes alcanzar tu gateway, pero la política de proxy/VPN o comportamiento de firewall parece ser el bloqueador—especialmente en dispositivos gestionados. Trastear en el endpoint no solucionará una política central.

Conclusión: próximos pasos que no arruinarán tu día

“Conectado, sin Internet” es o (a) realmente no puedes alcanzar Internet, o (b) Windows no puede demostrar que sí puedes. La solución es dejar de tratarlo como una maldición mística del SO y empezar a tratarlo como un sistema por capas.

Haz esto a continuación, en orden:

1. Ejecuta ipconfig /all y confirma: IP real, puerta de enlace por defecto, servidores DNS.
2. Pinga la gateway, luego pinga una IP pública, luego ejecuta nslookup sobre un dominio.
3. Si el comportamiento web/app es inconsistente, revisa proxies (WinHTTP + proxy de usuario) y la conducta de rutas/métricas de la VPN.
4. Si sospechas corrupción del stack, usa netsh winsock reset y netsh int ip reset—y reinicia—antes de “restablecer red”.
5. Si es corporativo y la evidencia apunta a política (bloqueos de proxy, restricciones DNS, kill switch de VPN), escala con datos: salidas de comandos y la capa exacta que falla.

El objetivo no es que el icono esté feliz. El objetivo es restaurar conectividad fiable sin borrar la mitad de tu configuración y rezar porque el universo apruebe.