Windows 11 rompe localhost: qué pasa, a quién afecta y cómo arreglarlo

Para muchos desarrolladores y equipos de TI, que falle “localhost” en Windows 11 es quedarse sin banco de pruebas. Tras las últimas actualizaciones acumulativas, varios sistemas han empezado a cortar las conexiones al bucle local 127.0.0.1 cuando se usa HTTP/2, dejando en el aire servidores de desarrollo, depuraciones y herramientas internas.

Los reportes se repiten en foros de Microsoft, Stack Overflow, Server Fault y Reddit: la actualización de octubre KB5066835 y la previa de septiembre KB5065789 (build 26100.6899 en algunos equipos) desencadenan errores al intentar conectar con endpoints locales. No es un problema de DNS ni del archivo hosts; el fallo aparece más abajo, en la pila del sistema.

Qué está pasando con localhost en Windows 11

Los sistemas afectados dejan de completar conexiones HTTP a 127.0.0.1 cuando negocian HTTP/2, devolviendo mensajes como “ERR_CONNECTION_RESET” o “ERR_HTTP2_PROTOCOL_ERROR”. En la práctica, los servicios que deberían escuchar en 127.0.0.1 no responden como es debido, los navegadores no llegan al endpoint local y las sesiones de depuración se interrumpen.

El patrón es consistente: con KB5066835/KB5065789 instalados, las peticiones al loopback fallan. Tras desinstalarlas y reiniciar, el circuito local vuelve a funcionar. Por eso, muchos lo han identificado como una regresión concreta introducida por estas compilaciones.

Aplicaciones y servicios afectados

Además de los escenarios de desarrollo web, han aparecido incidencias en herramientas habituales de trabajo y seguridad que tiran de servicios locales para operar.

• Depuración y ejecución en Visual Studio (proyectos ASP.NET/ASP.NET Core) e IIS.
• Autenticación y utilidades como SSMS Entra ID.
• Aplicaciones de seguridad como Duo Desktop, que verifican el estado del equipo y requieren endpoints locales.

En organizaciones con microservicios y utilidades internas, la caída del loopback bloquea pruebas, demos y validaciones, lo que dispara tiempos de diagnóstico aunque el código de la aplicación esté correcto.

El origen técnico: HTTP.sys y la negociación HTTP/2

Todo apunta a HTTP.sys, el componente en modo kernel que arbitra el tráfico HTTP de Windows y del que dependen IIS y ASP.NET Core. Con las builds recientes, la negociación de HTTP/2 en el bucle local provoca reinicios de conexión, de ahí los mensajes de error observados en navegadores y clientes.

Importa subrayarlo: no es un fallo de resolución de nombres, ni se arregla editando hosts. El desvío se produce en la capa que gestiona las conexiones dentro del propio sistema.

Síntomas y mensajes de error habituales

En los equipos afectados, al lanzar el sitio de desarrollo o un servicio local, las peticiones se cortan con códigos genéricos que apuntan a un reset de la conexión durante el handshake.

Ejemplos reportados: ERR_CONNECTION_RESET y ERR_HTTP2_PROTOCOL_ERROR. En servidores locales sobre IIS o Kestrel, las trazas muestran intentos fallidos de establecimiento de sesión cuando la conexión intenta negociar HTTP/2.

Soluciones temporales y mitigaciones que están funcionando

Hasta que llegue la corrección permanente, hay tres vías que la comunidad y Microsoft están utilizando, con distinto grado de invasividad y eficacia.

• Desinstalar las actualizaciones problemáticas y reiniciar: restaura el comportamiento anterior del loopback en la mayoría de equipos. Comandos de ejemplo:
  wusa /desinstalar /kb:5066835
wusa /desinstalar /kb:5065789
• Deshabilitar HTTP/2 en el registro para forzar HTTP/1.1 en el tráfico local. Es un parche quirúrgico, pero no es ideal para producción:
  
"EnableHttp2Tls"=dword:00000000
"EnableHttp2Cleartext"=dword:00000000
• Aplicar el Known Issue Rollback (KIR) de Microsoft, que revierte selectivamente el cambio problemático sin desinstalar toda la actualización.

Algunos usuarios comentan que actualizar las firmas de Microsoft Defender ha mejorado su situación, pero los resultados no son consistentes y no se recomienda como solución principal.

Qué ha dicho Microsoft y estado actual

Microsoft ha reconocido la regresión y ha activado una mitigación automática con KIR para equipos domésticos y no gestionados. En muchos casos, basta con buscar actualizaciones y reiniciar para que el rollback se aplique.

1. Abrir Configuración > Windows Update.
2. Pulsar en Buscar actualizaciones.
3. Reiniciar el dispositivo, incluso si no aparece nada nuevo.

En entornos corporativos, los administradores deben desplegar la directiva de grupo KIR correspondiente a Windows 11 24H2/25H2 y Windows Server 2025 para aplicar la reversión de forma controlada. La compañía ha indicado que la corrección permanente llegará en una actualización futura.

Recomendaciones prácticas para desarrolladores y TI

Mientras se estabiliza el canal de actualizaciones, conviene adoptar medidas prudentes para no frenar proyectos ni afectar a servicios críticos.

• En máquinas de desarrollo: si el bloqueo es inmediato, desinstalar KB5066835/KB5065789 o deshabilitar HTTP/2 temporalmente.
• En producción y laboratorios: validar el KIR y, si es necesario, distribuir la política de grupo correspondiente.
• Pausar la instalación de estos parches en entornos críticos hasta confirmar que el loopback funciona.
• Documentar los cambios (registro, KIR, desinstalaciones) para revertirlos en cuanto llegue la actualización definitiva.

Para quien trabaja a diario con endpoints locales, localhost no es un lujo: es la base del ciclo de probar y depurar. Los indicios señalan a una regresión en HTTP.sys con HTTP/2, ya reconocida por Microsoft y mitigada mediante KIR, mientras se prepara un parche estable. Con las soluciones provisionales de arriba, es posible seguir avanzando sin rehacer el entorno y minimizar el impacto en los plazos.