La red funciona pero Windows dice «Sin conexión a Internet» — Acotar NCSI, DNS, proxy y VPN en Windows

Los sitios web se abren. Los mensajes de chat llegan. Y aun así solo la pantalla de Windows dice «Sin conexión a Internet».

Es lógico pensar: «estoy usando la red ahora mismo, ¿por qué dice que no hay?». Hay una razón. Windows tiene su propia comprobación de conectividad, y su resultado es independiente del resultado del tráfico que envía la aplicación que usted está usando ahora mismo. Sus sitios habituales pueden ser accesibles mientras solo el destino contra el que Windows comprueba no lo es.¹

Así que, antes de borrar la configuración wifi o restablecer toda la red, separe la pregunta: ¿solo la pantalla está equivocada, o también falla el tráfico que quiere usar?

Este artículo explica primero el mecanismo tras el desajuste y pasa después a las situaciones habituales, a cómo leerlo por síntoma y a los pasos concretos de investigación. Si quiere el mecanismo, lea hasta el capítulo 3 incluido; si está investigando, lea los capítulos 4 y 5; quienes desarrollan aplicaciones para Windows deberían leer además el capítulo 6. Está centrado en Windows 11 y cubre también las diferencias con Windows 10, y los ejemplos usan Windows PowerShell 5.1 y curl.exe.

1. Windows no mira solo el sitio que usted está viendo ahora

Imagine que abre su sitio habitual en un PC de empresa. Si el navegador puede hablar con ese sitio, la página aparece. Al margen de eso, Windows va a buscar un pequeño archivo que se usa para la comprobación de conectividad.

Ahora bien, ¿y si la red de la empresa estuviera configurada para permitir el tráfico hacia los sitios que la gente usa normalmente pero no el tráfico hacia el destino de la comprobación de conectividad? El tráfico del navegador tiene éxito mientras el tráfico de comprobación de Windows falla. Incluso en el mismo PC, si aquello contra lo que se comprueba es distinto, los resultados pueden discrepar.¹

flowchart TB
    accTitle: Un ejemplo en el que el sitio web funciona y solo falla la comprobación de conectividad
    accDescr: Un ejemplo hipotético en el que el navegador del mismo PC alcanza el sitio habitual mientras la petición de comprobación de NCSI no alcanza un destino de comprobación distinto. No es un diagrama que fije el estado final de NCSI a partir de una sola petición.
    pc["El mismo PC"] --> browser["Tráfico del navegador"]
    pc --> probe["Tráfico de comprobación de conectividad de Windows"]
    browser --> site["Sitio web habitual<br/>la página se abre"]
    probe --> blocked["Destino de la comprobación de conectividad<br/>solo este tráfico falla"]

Figura 1: Un ejemplo hipotético para entender el mecanismo. El tráfico cotidiano y la comprobación de conectividad van a interlocutores distintos.

El componente responsable de este veredicto de conectividad es NCSI (Network Connectivity Status Indicator). Decide si hay conexión a Internet o solo conectividad local, y suministra la información que usan la indicación de estado de red y las aplicaciones. No está vigilando si un sitio web o un sistema de negocio concreto está en marcha.¹

Fíjese en si vuelve el contenido de la comprobación, no en si volvió algo

Desde Windows 10 versión 1607, el destino estándar de comprobación HTTP es la siguiente URL. El cuerpo esperado es Microsoft Connect Test. En los PC que gestionan las empresas, el destino de comprobación a veces se cambia.²

http://www.msftconnecttest.com/connecttest.txt

Si va a buscar este archivo y vuelve una pantalla de acceso de un hotel o una página de bloqueo corporativa, entonces algo llegó del destino, pero no es el resultado de comprobación esperado. Incluso cuando el estado HTTP es 200, el cuerpo no tiene por qué ser el mismo.³

flowchart TB
    accTitle: Qué comprueba el sondeo HTTP
    accDescr: Para la petición al destino de comprobación, fíjese en si vuelven la respuesta y el cuerpo esperados.
    start["Petición HTTP al destino de comprobación"] --> response{"¿Se recibió una respuesta?"}
    response -->|"No"| failed["Investigar la transferencia incompleta o el fallo"]
    response -->|"Sí"| content{"¿Son la respuesta y el cuerpo esperados?"}
    content -->|"Sí"| success["Indicio a favor de un veredicto de conectado"]
    content -->|"No"| changed["Investigar autenticación, bloqueo o contenido alterado"]

Figura 2: Mantenga separado «recibir una respuesta del destino de comprobación» de «recuperar el contenido esperado».

Tenga en cuenta que NCSI no se basa solo en este tráfico de comprobación. El método en el que comprueba por iniciativa propia se llama sondeo activo, y aquel en el que juzga a partir de información como los paquetes recibidos, sondeo pasivo; usa ambos. Así que una petición HTTP fallida en el diagrama no equivale a que el estado final de conectividad acabe en «sin Internet».¹

Lo visto hasta aquí es que conectarse al wifi, poder usar un sitio concreto y que Windows emita un veredicto de «Internet» son cada uno una comprobación distinta. Estar conectado al wifi no dice nada sobre la ruta hacia el exterior ni sobre la autenticación de uso, y alcanzar un sitio no garantiza que otro destino u otra aplicación vayan a funcionar.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (5 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Tres situaciones habituales en las que la pantalla y el tráfico discrepan

En la oficina, el navegador y la comprobación de conectividad pueden tomar rutas distintas

Concretemos algo más el ejemplo de empresa del principio. En las redes corporativas hay configuraciones en las que no se sale directamente al exterior, sino que se pasa por un relé llamado proxy. El mecanismo que elige ese relé según la URL a la que se accede y criterios similares es el archivo PAC. A veces se usa también la detección automática.⁴

En esta configuración puede seleccionarse un proxy adecuado para los sitios que la gente usa normalmente mientras solo el destino de la comprobación de conectividad queda fuera de las reglas. También son candidatos a investigar los casos en que la detección de proxy no termina a tiempo o en que solo está bloqueado el tráfico HTTP hacia el destino de comprobación.¹

flowchart TB
    accTitle: Comprobar por separado la ruta del navegador y la de NCSI
    accDescr: El éxito del tráfico del navegador no garantiza el de NCSI, que usa un destino distinto y una selección de proxy distinta.
    pc["El mismo PC"] --> browser["Petición del navegador"]
    pc --> ncsi["Petición de comprobación de NCSI"]
    browser --> bpath["Proxy y autenticación de esa petición"]
    ncsi --> npath["Proxy y autenticación de la petición de comprobación"]
    bpath --> site["Sitio web que se usó"]
    npath --> probe["Destino de la comprobación de conectividad"]

Figura 3: Estar en el mismo PC no implica necesariamente la misma ruta. Compruebe destino, proxy y autenticación en cada petición.

Así que vaya más allá de si el navegador tuvo éxito y averigüe qué proxy se seleccionó para la petición de NCSI y bajo qué cuenta o condiciones de autenticación se comunicó. Lo mismo vale para la comprobación manual con curl que se usa más adelante. No tratar las tres como tráfico en condiciones idénticas es el punto de partida para acotar el problema.

En un hotel, tras unirse al wifi puede quedar pendiente un inicio de sesión

En el wifi de hoteles y lugares similares, una vez establecido el enlace de radio puede pedírsele aceptar unas condiciones de uso o iniciar sesión. Esa pasarela de autenticación es un portal cautivo. Si la petición de comprobación se redirige a la página de autenticación, o se devuelve una pantalla de acceso, eso no se convierte en la respuesta de comprobación normal. Que Windows abra un navegador para pedirle que inicie sesión también guarda relación con este mecanismo.³

flowchart TB
    accTitle: La diferencia entre unirse al wifi y la autenticación en el portal
    accDescr: Aun después de que la conexión inalámbrica tenga éxito, el tráfico hacia el exterior puede seguir restringido hasta que se complete la autenticación del lado de la red.
    wifi["Conectado al wifi"] --> portal{"¿Está completa la autenticación de uso?"}
    portal -->|"No completa"| signin["Autenticarse desde la página oficial"]
    portal -->|"Completa"| test["Volver a comprobar el tráfico real y el veredicto"]
    signin --> test

Figura 4: Terminar la conexión al wifi no significa haber terminado la autenticación para usar esa red.

Como hay casos en los que solo es consultable la página informativa del establecimiento, no concluya de una página que se abre que todo el tráfico saliente esté permitido. Autentíquese siguiendo las instrucciones oficiales del lugar y compruebe después el tráfico real y la pantalla de Windows. No introduzca datos de cuenta ni de tarjeta en una pantalla de acceso sospechosa.

Con una VPN cambia «de qué conexión vino el resultado»

Antes y después de una conexión VPN, la ruta del tráfico y las condiciones de uso del DNS pueden cambiar. Que los ajustes no estén en su sitio justo después de conectar, o que el tráfico de comprobación tome una ruta no prevista, son también candidatos a un fallo de NCSI.²

En ese caso, no vea el PC como un único estado de conectado o no conectado: separe la LAN física o el wifi de la VPN. Por ejemplo, si el diseño sitúa el lado físico en LocalNetwork mientras usted sale a Internet por el lado VPN, una línea sobre el lado físico no basta para declarar que algo está mal. Lea los perfiles de conexión del capítulo 4 junto con la ruta que realmente se usó.⁵⁶

flowchart TB
    accTitle: Separar la ruta de conexión y la familia IP
    accDescr: Separe la LAN física de la VPN e IPv4 de IPv6, y asocie a cada veredicto la ruta que usó el tráfico.
    pc["Enumerar las conexiones"] --> physical["LAN física y wifi"]
    pc --> vpn["Adaptador VPN"]
    physical --> p["Veredictos IPv4 e IPv6"]
    vpn --> v["Veredictos IPv4 e IPv6"]
    p --> route["Correlacionar con la ruta real del tráfico"]
    v --> route

Figura 5: Mantenga distintas conexión física y VPN, e IPv4 e IPv6, mientras compara con la ruta real del tráfico.

Lo mismo vale para IPv4 e IPv6. NCSI ejecuta los sondeos activos de ambos en paralelo, y el éxito de cualquiera de los dos basta para concluir que hay conexión a Internet. Que uno de ellos no sea «Internet» no significa por sí solo que todo el PC esté sin conexión. Cuál de los dos usó una aplicación concreta se observa por separado para ese tráfico.¹

Si quiere comparar desconectando la VPN, hágalo en una máquina de pruebas aprobada por su organización o durante una ventana de cambios aprobada. No desconecte sin permiso una VPN siempre activa solo para investigar.

3. La primera separación es «¿solo la pantalla, o también el tráfico?»

Una vez que conoce las causas candidatas, aplíquelas a sus propios síntomas. Confirme primero si el tráfico nuevo funciona ahora mismo, por ejemplo abriendo una página nueva en un sitio que tenga permitido usar. Una pantalla que lleva abierta desde antes no le dice nada del estado actual de la conexión.

En lugar de «la red funciona», sea lo bastante concreto para escribir «a esta hora, en esta aplicación, hacia este destino, esta operación tuvo éxito». Eso acota qué investigar.

No es una tabla que identifique la causa; es una tabla para elegir dónde comprobar a continuación. Aunque el origen fuera una anomalía de la pantalla, si la aplicación de negocio que quiere usar está fallando, registre también ese resultado de tráfico por separado.

A partir de aquí vienen los pasos de investigación. Proceda en este orden: capturar el estado, leer los ajustes del destino de comprobación, comparar con tráfico manual y confirmar después con los propios registros de NCSI. No cambie sin permiso la configuración corporativa de proxy, VPN o seguridad; empiece con una inspección de solo lectura y unas pocas comprobaciones de tráfico.

4. Antes de cambiar ajustes, determine dónde falló

4.1 Registrar la hora del suceso y el estado de la conexión

Registre primero la hora del suceso, la compilación del sistema, cómo está conectado, si hay una VPN en uso y qué aplicación falla. La versión del sistema puede verla con winver. Muestre después los perfiles de conexión en PowerShell.⁵

Get-Date -Format o
Get-NetConnectionProfile |
    Select-Object Name, InterfaceAlias, InterfaceIndex,
        NetworkCategory, IPv4Connectivity, IPv6Connectivity |
    Format-Table -AutoSize

Lo que hay que leer es el nombre de la conexión, InterfaceAlias e InterfaceIndex, y IPv4Connectivity e IPv6Connectivity. Cuando hay varias filas, léalas sin perder de vista a qué conexión pertenece cada resultado. La idea es comparar resultados de la misma hora y la misma conexión con las pruebas manuales y los registros que siguen.

Los valores Public / Private / DomainAuthenticated de NetworkCategory son una clasificación distinta del veredicto de conectividad a Internet. Cambiar de Public a Private no es un paso de reparación general para «Sin conexión a Internet». La salida puede contener cosas como nombres de redes internas, así que enmascare cualquier información identificativa innecesaria antes de entregarla a un tercero.⁵

4.2 Leer qué destino está configurado este PC para comprobar

Antes de probar el destino de comprobación estándar, confirme si este PC usa los mismos ajustes. El código siguiente solo muestra valores; no modifica el Registro. Lee los destinos de comprobación del lado IPv4 y del lado IPv6 y el cuerpo esperado, junto con las directivas que controlan cosas como la prueba activa.¹⁷

$internetKey = 'HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet'
Get-ItemProperty -LiteralPath $internetKey |
    Select-Object EnableActiveProbing, ActiveWebProbeHost,
        ActiveWebProbePath, ActiveWebProbeContent,
        ActiveWebProbeHostV6, ActiveWebProbePathV6,
        ActiveWebProbeContentV6 |
    Format-List

$policyKey = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator'
if (Test-Path -LiteralPath $policyKey) {
    Get-ItemProperty -LiteralPath $policyKey |
        Select-Object NoActiveProbe, DisablePassivePolling |
        Format-List
} else {
    'No hay ninguna directiva de NCSI en esta ruta del Registro.'
}

ActiveWebProbeHost y ActiveWebProbePath son el destino de comprobación, y ActiveWebProbeContent es el cuerpo esperado. Registre también los valores con V6 en el nombre. Si hay configurado un destino de comprobación propio, alinee las pruebas manuales de abajo con ese ajuste y con su directiva de gestión.

Una salida que diga que no hay clave de directiva significa que no hay ajustes en esa ruta. No es prueba de que no exista ninguna configuración de gestión, incluida la que llega por MDM. No adivine ni cree una clave que no ha encontrado; confírmelo con su administrador.

Para los proxies, revise las pantallas de configuración de Windows y las directivas de gestión. Para los ajustes de WinHTTP, netsh winhttp show advproxy en entornos que lo admiten, o netsh winhttp show proxy en entornos más antiguos, le da material de comparación. Lo que ahí averigua, no obstante, es la configuración. La ruta que NCSI seleccionó realmente mediante PAC o detección automática hay que correlacionarla con los registros de tráfico que se describen después.⁸⁴

4.3 Separar si el nombre se resuelve de si TCP conecta

A partir de aquí vienen pruebas manuales de comparación contra el destino de comprobación estándar. Lo que quiere saber es si el nombre del destino no puede resolverse o si las cosas se detienen en la conexión posterior. Compruebe primero por separado la resolución de nombres y la conexión TCP.

Resolve-DnsName -Name 'www.msftconnecttest.com' -Type A -DnsOnly
Test-NetConnection -ComputerName 'www.msftconnecttest.com' -Port 80 -InformationLevel Detailed

El -Type A de Resolve-DnsName indica que se busque la dirección IPv4. Observe al principio con sus ajustes de DNS habituales. Cambiar de golpe a un servidor DNS público altera también la resolución de nombres internos y su directiva de gestión, lo que hace más difícil seguir el problema original.⁹

Lo que Test-NetConnection -Port 80 le indica es la conexión TCP al destino dado. No comprueba el cuerpo HTTP ni la autenticación del proxy. En un entorno donde las conexiones directas están prohibidas y solo se permite el tráfico a través de un proxy HTTP, que esta prueba TCP falle puede ser normal. Guarde también InterfaceAlias y SourceAddress y confirme de qué ruta vino el resultado.⁶

flowchart TB
    accTitle: Las preguntas que responden las pruebas manuales
    accDescr: La resolución de nombres, la conexión TCP y la respuesta HTTP cubren ámbitos distintos, así que no trate el éxito de una como garantía para la capa siguiente.
    name["Resolver el nombre por DNS"] --> tcp["Comprobar la conexión TCP al destino"]
    tcp --> http["Comprobar la respuesta HTTP y el cuerpo"]
    http --> own["Comparar con los propios registros de NCSI"]
    tcp -.-> proxy["Una ruta distinta en la que un proxy es obligatorio"]

Figura 6: La resolución de nombres, la conexión TCP y la respuesta HTTP confirman cada una algo distinto, en ese orden.

4.4 Con HTTP, mire el cuerpo, no solo el estado

Mire después si vuelve el cuerpo de comprobación descrito en el capítulo 1. En una máquina donde curl.exe esté disponible, ejecute lo siguiente unas pocas veces. Escriba el .exe para que no se confunda con el alias de PowerShell.

curl.exe -q --connect-timeout 5 --max-time 15 --include 'http://www.msftconnecttest.com/connecttest.txt'

--include es la opción que muestra las cabeceras junto con el cuerpo. Se fijan tiempos de espera para la conexión y para la operación en conjunto y, como no se da -L, no sigue automáticamente una redirección, de modo que puede ver la primera respuesta. El -q inicial indica a curl que no lea su archivo de configuración predeterminado, pero no borra las variables de entorno relacionadas con proxies.¹⁰

Sigue un ejemplo mínimo del contenido esperado. Es a modo de explicación; no es un registro medido para este artículo. En la práctica hay también otras cabeceras.²

HTTP/1.1 200 OK
...

Microsoft Connect Test

Lo importante aquí es que la prueba manual no sustituye a NCSI; es material de comparación. curl no es una prueba que herede los ajustes PAC de Windows ni el estado de autenticación del navegador del mismo modo. Un resultado de «el navegador tuvo éxito, curl falló» no acredita por sí solo que NCSI funcione mal.

Confirme con su administrador cómo deben usarse los proxies y no escriba credenciales directamente en su historial de comandos. Y aunque esta comprobación HTTP tenga éxito, no garantiza que vayan a tenerlo HTTPS y la autenticación de una API de negocio.

4.5 Por último, busque los registros del fallo real de NCSI

Una vez que las pruebas manuales han hecho aflorar candidatos, compruebe el comportamiento propio de NCSI. La vía de entrada es el Visor de eventos, en Registros de aplicaciones y servicios → Microsoft → Windows → NCSI. Revise el registro Operativo alrededor de la hora del suceso.¹¹

En lugar de una sola línea de error, siga leyendo: en qué interfaz empezó y si se completó, cuál fue el motivo del fallo y cómo cambió después el estado de conectividad. Correlacione a la misma hora y en la misma ruta que las pruebas manuales, y combine si hace falta con una captura de paquetes aprobada.¹¹

flowchart TB
    accTitle: El orden en que leer los registros de NCSI
    accDescr: Conecte el inicio, la finalización, el motivo del fallo y el cambio de estado por hora e interfaz.
    start["En qué ruta empezó"] --> finish["Si se completó"]
    finish --> reason["Código de resultado y motivo del fallo"]
    reason --> state["El estado de conectividad posterior"]
    state --> correlate["Correlacionar con registros de tráfico de la misma hora"]

Figura 7: Conectar el inicio hasta el cambio de estado facilita rastrear qué diferían la prueba manual y NCSI.

Si el código de resultado es un error de WinHTTP, busque su significado en la tabla de WinHTTP. Por ejemplo, 12007 significa que el nombre no pudo resolverse, y 12002 es un tiempo de espera agotado. Lo que averigua, no obstante, es una pista sobre la fase que falló; eso solo no establece que un servidor DNS haya caído ni que la línea esté cortada.¹²

Si el detalle no basta, un administrador habilita el registro Analítico desde «Ver registros analíticos y de depuración». Es un cambio en los ajustes de diagnóstico, así que anote la hora en que lo habilitó, reproduzca el problema y restaure el estado original tras la recogida. Habilitarlo no permite recuperar eventos detallados anteriores a la habilitación.¹¹

Además, volver a conectar el wifi o deshabilitar un adaptador para reproducir el problema puede cortar conexiones de administración como RDP. No lo haga sin avisar en una máquina de producción o en una máquina que esté manejando en remoto. Los registros de tráfico pueden contener nombres de host, direcciones IP e información relacionada con la autenticación, así que restrinja dónde se guardan y con quién se comparten.

En el ejemplo de empresa del principio, aquí es donde correlaciona el 403 del HTTP manual, el registro de NCSI de la misma hora y los registros de denegación del proxy que su administrador puede consultar. Si solo se estaba denegando el destino de comprobación, corrija esa regla y repita la prueba. Si solo la prueba manual tomó otra ruta, revise las condiciones de comparación. No decida a partir del número 403 por sí solo que se trata de «un error de NCSI» o de «un problema de nuestro proxy»; elija la acción siguiente según los registros. Es un ejemplo de acotación hipotético, no el resultado de un trabajo real.

5. No intente reparar solo la pantalla con soluciones antiguas

No confunda el tráfico DNS de Windows 11 con el antiguo sondeo DNS

Textos más antiguos destacan un sondeo DNS a dns.msftncsi.com. Las preguntas frecuentes oficiales de NCSI, sin embargo, explican que el sondeo activo a partir de Windows 11 usa HTTP. Aunque en un registro de Windows 11 aparezca tráfico DNS, puede tratarse de la resolución de nombres del destino HTTP.²

flowchart TB
    accTitle: Distinguir la función del tráfico DNS
    accDescr: Lea la resolución de nombres del destino HTTP de Windows 11 y el antiguo sondeo DNS como cosas distintas.
    dns["Hay tráfico DNS en el registro"] --> purpose{"¿Para qué es el tráfico?"}
    purpose --> http["Resolución de nombres del destino HTTP"]
    purpose --> legacy["El antiguo sondeo DNS"]
    http --> win11["Puede hacer falta también en Windows 11"]
    legacy --> version["Comprobar la versión del sistema y los registros reales"]

Figura 8: El tráfico DNS que busca el destino HTTP y el sondeo DNS en sí son cosas distintas.

Así que la explicación antigua de que «toda consulta DNS separada de HTTP tiene que tener éxito» no puede convertirse en una regla común a todas las versiones de Windows. Lea la versión del sistema que está investigando junto con los registros reales.

Otro punto que confunde es el nombre de la ubicación de los ajustes. En Windows 11, el componente que ejecuta NCSI ha pasado del NLA tradicional al lado del Administrador de listas de redes, pero ajustes como el destino de comprobación siguen usando la ruta del Registro que incluye NlaSvc del capítulo 4. No decida qué servicio lo ejecuta solo porque la ruta diga NlaSvc.¹

Detener la comprobación no repara el tráfico que no estaba pasando

Poner EnableActiveProbing a 0, o prohibir la prueba activa por directiva, son ajustes que restringen la comprobación de conectividad. No son operaciones que reparen un fallo de DNS ni una ruta de proxy. Mantenga separado adoptarlo como directiva de gestión para una red aislada de cambiarlo para hacer desaparecer un aviso. Microsoft tampoco recomienda deshabilitar el sondeo activo como solución a los problemas de NCSI.⁷¹

Por la misma razón, devolver una respuesta de éxito falsa, apagar el cortafuegos en bloque o deshabilitar IPv6 sin fundamento no son primeros pasos. Que la pantalla cambie y que el tráfico que quiere usar mejore son dos cosas distintas.

flowchart TB
    accTitle: No juzgue una reparación solo por la pantalla
    accDescr: Tras un cambio de configuración, confirme no solo el cambio en la pantalla, sino también el punto de fallo y la mejora del tráfico que necesita.
    change["Un cambio con fundamento"] --> probe["Volver a comprobar el tráfico de comprobación de conectividad"]
    change --> app["Volver a comprobar el tráfico que necesita"]
    probe --> judge["Juzgar la mejora a partir de ambos resultados"]
    app --> judge

Figura 9: Incluso tras un cambio con fundamento, confirme tanto el tráfico de comprobación como el tráfico que quiere usar.

Al corregir las reglas de permiso corporativas tampoco termine registrando de forma estática las direcciones IP de un artículo antiguo. La infraestructura de entrega que hay detrás del destino público de comprobación de NCSI puede cambiar, y Microsoft desaconseja las reglas de permiso que dependen de direcciones IP concretas. Elabore con su administrador reglas que se correspondan con el destino de comprobación, el servicio y la ruta reales.²

6. Para desarrolladores: no decida «no comunicar» solo por NCSI

Todo lo anterior atañe también al diseño de aplicaciones para Windows. Si el sistema operativo dice «Sin conexión a Internet» y usted marca por ello la aplicación como sin conexión sin intentar ni una sola vez la petición que necesita, puede estar deteniendo tráfico que en realidad funcionaría. A la inversa, también es un error pensar que una API de negocio tiene por fuerza que funcionar porque el sistema diga «Internet».

INetworkListManager::get_IsConnectedToInternet, que recupera el veredicto de conectividad de todo el sistema, es una API que devuelve el estado de conectividad a Internet de la máquina local. No garantiza que una API o un recurso compartido concreto esté funcionando, que la autenticación tenga éxito ni que usted tenga permiso para usarlo.¹³

En términos de diseño puede resumirse así: use el estado de conectividad del sistema como pista para la presentación y la reconexión, y gestione aparte el éxito o el fallo del tráfico que necesita. El objetivo es poder sostener dos hechos a la vez: «el veredicto de Windows es LocalNetwork, y la API de negocio era alcanzable».

flowchart TB
    accTitle: Gestionar por separado el veredicto del sistema y el resultado del tráfico de negocio
    accDescr: Use la información de conectividad del sistema como pista, y dé al tráfico que necesita su propio tratamiento independiente de éxito y fallo.
    status["Estado de conectividad del sistema"] --> hint["Pista para la presentación y la reconexión"]
    request["La petición que necesita"] --> outcome{"El resultado real"}
    outcome --> ok["Tratar como éxito"]
    outcome --> error["Registrar el motivo del fallo"]
    error --> retry["Reintentar tras confirmar que es seguro"]

Figura 10: Use el veredicto del sistema como pista y dé al tráfico de negocio su propio tratamiento de éxito y fallo.

Tampoco reduzca el registro a la única palabra «sin conexión»; anote la fase del fallo que haya podido observar, como DNS, la conexión, TLS, la autenticación o la respuesta HTTP. Dé a las peticiones tiempos de espera y cancelación para que la interfaz no se quede esperando.

Reintentar tras un tiempo de espera agotado, no obstante, tiene una advertencia aparte. Una operación de modificación como realizar un pedido o una transferencia puede haberse ejecutado ya en el otro extremo aunque la respuesta no llegara a tiempo. No decida «se agotó el tiempo, así que no se ejecutó» y reenvíe; haga que la cuestión de si se permite un reintento, el mecanismo que impide duplicados y la consulta del resultado formen parte de la especificación de la aplicación. No es un problema que NCSI vaya a resolverle.

7. Resumen: lea la pantalla y el tráfico como hechos distintos

«La red funciona pero Windows dice Sin conexión a Internet» no es necesariamente una contradicción. Conectarse al wifi, comunicarse con el interlocutor que se quiere alcanzar y el propio veredicto de NCSI de Windows comprueban cada uno algo distinto.

Separe primero si solo discrepa la pantalla o si también falla el tráfico que necesita. Al investigar, use los ajustes del destino de comprobación y las pruebas manuales como material de comparación, y confirme el comportamiento real en los propios registros de NCSI. Y tras un cambio, mire más allá del icono para ver si han mejorado el tráfico de comprobación y el tráfico que necesita.

De «debería estar conectado» a «qué tráfico falló, y dónde». Pensar en ese orden permite acotar dónde mirar antes de ponerse a cambiar ajustes al azar.

Artículos relacionados

• El cortafuegos de Windows y las aplicaciones de negocio
• El almacén de certificados de Windows en la práctica

Enlaces de referencia

Comprobado el 11 de septiembre de 2026. Para las diferencias entre versiones del sistema operativo prevalecen las preguntas frecuentes oficiales específicas de NCSI, y los procedimientos de la documentación antigua orientada a clientes no se tratan como especificación fija de Windows 11. Compruebe también los nombres mostrados de los registros y los comandos disponibles frente a su compilación real y su configuración de gestión.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Por qué Windows muestra «Sin conexión a Internet» si estoy conectado al wifi?

Porque conectarse al wifi, comunicarse con el servicio que se quiere usar y el veredicto de conectividad al que Windows llega mediante NCSI son tres cosas distintas. La pantalla puede discrepar no solo cuando la línea está caída, sino también por problemas de DNS, proxy, VPN o portal cautivo que afectan al tráfico de comprobación. Empiece por determinar qué puede comunicarse realmente.

Si un sitio se abre en el navegador, ¿puedo concluir que NCSI también está bien?

No. El destino, el proxy que se selecciona, el estado de autenticación, IPv4 frente a IPv6 y la hora de la petición pueden ser todos distintos. Trate el acceso manual como material de comparación y confírmelo con los propios registros de eventos de NCSI y, si hace falta, una captura de paquetes.

¿Sigue siendo necesario un sondeo DNS a dns.msftncsi.com en Windows 11?

Las preguntas frecuentes oficiales de NCSI explican que el sondeo activo a partir de Windows 11 usa HTTP. Distinga el tráfico DNS que resuelve el destino HTTP del sondeo DNS de versiones anteriores. Lo importante es no dar por supuesto en bloque que toda petición de un procedimiento antiguo sea obligatoria.

¿Poner EnableActiveProbing a 0 lo arreglará?

Ese ajuste detiene el tráfico de comprobación; no es un ajuste que repare una causa como el DNS o el enrutamiento. Salvo que lo adopte como directiva de gestión para algo como una red aislada, no lo cambie para hacer desaparecer el mensaje: investigue antes dónde se produce el fallo.

Si NCSI dice «Internet», ¿tengo garantizado llegar a nuestros sistemas de negocio?

No necesariamente. El veredicto de conectividad del sistema operativo no garantiza que una API o un recurso compartido concreto esté funcionando, que la autenticación tenga éxito ni que usted tenga permiso para usarlo. Una aplicación tiene que emitir el tráfico que realmente necesita y tratar los tiempos de espera, la cancelación, el tipo de fallo y si un reintento es seguro.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.