Windows 11 rompe localhost: causas, efectos y soluciones prácticas

Inicio » Tutoriales » Windows 11 rompe localhost: causas, efectos y soluciones prácticas

Lo que parecía una actualización rutinaria de octubre para Windows 11 se ha convertido en un auténtico quebradero de cabeza para desarrolladores y equipos técnicos: tras instalar el paquete acumulativo KB5066835 (y, en algunos casos, con la herencia de KB5065789), el acceso a ‘localhost’ deja de responder con normalidad en la build 26100.6899. La consecuencia práctica es clara: los servicios locales en 127.0.0.1 y el ciclo de probar-depurar se van al traste, con fallos especialmente acusados cuando entra en juego HTTP/2.

El desbarajuste llega, además, en una semana sensible: con Windows 10 ya fuera de soporte, era el momento natural para que muchos dieran el salto definitivo. En lugar de un aterrizaje suave, una pieza crítica del sistema se ha venido abajo, dejando a Visual Studio, ASP.NET, IIS Express, Kestrel, Node.js, Python o Docker encallados en casa: el navegador no levanta, las pruebas se resetean y la depuración se frustra.

Qué está fallando exactamente y cómo se manifiesta

Los reportes que han ido apareciendo en los foros de Microsoft, Stack Overflow y Server Fault pintan un patrón muy consistente: las conexiones en el bucle local ‘localhost’ (127.0.0.1) fallan o se resetean, y en particular las sesiones HTTP/2 se caen con errores de conexión. Navegadores mostrando ‘ERR_CONNECTION_RESET’, clientes que no llegan a negociar correctamente el protocolo y servicios que no escuchan como deberían.

A nivel de herramientas, el impacto es transversal. Visual Studio falla al iniciar sesiones de depuración contra servidores locales, ASP.NET no consigue arrancar entornos de desarrollo de forma utilizable y proyectos con webs embebidas se quedan a medias. También aparecen quejas en stacks populares: Node.js, Python y contenedores con Docker ven cómo sus endpoints locales no responden o lo hacen de manera intermitente.

En flujos de CI que dependen de pruebas locales, la cosa es igual de áspera: los pipelines se llenan de falsos negativos si el runner está en Windows 11 afectado, y tareas que antes tardaban minutos pasan a estar bloqueadas. No es un glitch cosmético; es un tapón en la tubería del día a día.

Señalados principales: HTTP.sys y la build 26100.6899

Las miradas apuntan a HTTP.sys, el componente en modo kernel que orquesta el tráfico HTTP en Windows. Con la build 26100.6899, muchos reproducen fallos específicamente ligados a HTTP/2 cuando el tráfico se queda en casa (loopback). No hablamos de un problema de DNS ni del archivo hosts per se: el tropiezo se nota más abajo, en la capa que arbitra el protocolo y enruta dentro del propio sistema.

Esta hipótesis encaja con la sintomatología: resets de stream, problemas en la negociación ALPN y sesiones que no pasan del preface de HTTP/2. Clientes y servidores que prefieren HTTP/2 por defecto (navegadores modernos, Kestrel, IIS Express) sufren más; cuando se les fuerza a HTTP/1.1, en muchos equipos se recupera la vida mínima funcional.

Lo que duele en el día a día del desarrollo

‘Localhost’ no es un lujo; es la base de trabajo de cualquier equipo que construye software. Ahí se levantan APIs para pruebas, se montan microservicios, se ejecutan suites automatizadas y se depura con confianza porque todo sucede en un circuito controlado. Si se pincha ese circuito, el proyecto puede compilar, pero no hay forma de verlo “vivo” en tu propio PC.

Más delicado aún: al romperse la red local se dispara la confusión. El desarrollador pierde tiempo persiguiendo errores que no están en su código, se tocan configuraciones que no proceden y se introducen cambios apresurados que, en ocasiones, terminan en producción. La productividad se resiente y la moral también.

Estado de la cuestión: lo que se sabe y lo que se sospecha

En el momento en que más casos salían a la luz, la comunicación oficial de Microsoft era escasa respecto a ‘localhost’, aunque sí se movieron con rapidez en otro frente crítico (lo veremos más abajo). Los hilos de soporte reflejan escenarios dispares: equipos donde reinstalar no arregla nada, otros donde instalaciones limpias de 24H2 no reproducen el problema, y algunos que sólo funcionan tras deshacer la actualización.

Medios especializados también han puesto el foco en la regresión: informes públicos hablan de una actualización de octubre que “rompe localhost” con HTTP/2 en 127.0.0.1, afectando a servidores y clientes que confían en esa ruta en el propio equipo. La conclusión operativa es nítida: tocar una pieza de la pila HTTP del sistema puede levantar olas enormes río arriba.

Solución inmediata que sí funciona: desinstalar KB5066835 (y, si hace falta, KB5065789)

Hasta que llegue un parche correctivo, la comunidad ha encontrado un camino pragmático: quitar la actualización de octubre (KB5066835) y reiniciar. Donde el problema persiste, retirar también la acumulativa previa (KB5065789) devuelve la funcionalidad. Es un compromiso incómodo, porque hablamos de calidad y seguridad, pero permite retomar el trabajo sin reedificar el entorno.

Si prefieres hacerlo desde la interfaz de Windows 11, estos son los pasos típicos que se están siguiendo en equipos afectados: entra en Windows Update, revisa el Historial y desinstala la actualización concreta. Tras el reinicio, ‘localhost’ vuelve a comportarse, y conviene pausar temporalmente las actualizaciones para evitar que el parche regrese de forma automática.

• Abre ‘Windows Update’ desde el buscador, entra en ‘Buscar actualizaciones’ y luego en ‘Historial de actualizaciones’ (ahí verás KB5066835).
• Baja hasta ‘Desinstalar actualizaciones’, localiza KB5066835 y pulsa ‘Desinstalar’ (repite con KB5065789 si el fallo sigue).
• Reinicia el equipo y, como medida preventiva, pausa las actualizaciones unos días para esquivar la reinstalación automática.

Ten presente el contexto: desinstalar acumulativas puede dejarte sin mitigaciones recientes. Valora el riesgo en tu organización y coordina la decisión con seguridad/IT si es un entorno corporativo.

Mitigación alternativa: deshabilitar HTTP/2 de forma temporal

Otra vía que ha funcionado para muchos pasa por decirle al sistema que no use HTTP/2 mientras llega una actualización buena. Es un cambio quirúrgico que reduce el alcance del problema al forzar HTTP/1.1, aunque sacrifica ventajas de rendimiento y multiplexación propias de HTTP/2. Varios ingenieros de soporte han indicado que tocar estos valores del registro puede estabilizar el entorno.

Se han reportado resultados positivos al establecer a 0 los siguientes valores del registro (y reiniciar): ‘EnableHttp2’ y ‘EnableHttp2OverTls’. La edición debe hacerse con cuidado, privilegios de administrador y, si es posible, en un entorno de pruebas.

Ruta sugerida del registro (referencial):
HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

Valores DWORD:
'EnableHttp2' = 0
'EnableHttp2OverTls' = 0

Si no quieres tocar el registro, otra táctica válida es forzar HTTP/1.1 en el cliente o en el servidor mientras tanto. Por ejemplo, usar curl con la opción ‘–http1.1’, o configurar Kestrel/IIS Express/tu runtime para que negocien HTTP/1.1 de forma preferente en desarrollo.

Pruebas rápidas para acotar el problema

Antes de aplicar medidas más profundas, conviene aislar el alcance. Estas comprobaciones ayudan a confirmar si tu caso es el de HTTP/2 en loopback y a separar ruido de señal:

• Prueba el mismo servicio con HTTP/1.1 (por ejemplo, curl –http1.1) y verifica si responde de forma estable en 127.0.0.1.
• Comprueba si en ‘::1’ (loopback IPv6) el problema se reproduce igual; a veces IPv6 e IPv4 recorren rutas distintas y el fallo no se presenta en ambos.
• Activa más logging en el servidor/cliente para capturar negociaciones ALPN, resets de stream y timeouts.
• Si puedes, captura tráfico para ver dónde se corta el intercambio (inicio, SETTINGS, data, etc.).

Soluciones adicionales que algunos están aplicando (con cautela)

En hilos comunitarios se han propuesto ajustes complementarios que, bien ejecutados, han servido en entornos específicos. No son la primera opción, pero pueden ayudar si tu caso tiene particularidades de red o virtualización:

• Archivo hosts: asegurarte de que existen entradas explícitas ‘127.0.0.1 localhost’ y ‘::1 localhost’ puede despejar dudas. Tras el cambio, reinicia el servicio DNS (‘Dnscache’).
• Firewall de Windows: crea reglas de entrada limitadas a 127.0.0.1 y ::1 para puertos de desarrollo (80, 443, 3000-5000), evitando exposición externa.
• IPv6: deshabilitarlo si todo tu stack es solo IPv4 puede aliviar síntomas, aunque no es recomendable a largo plazo. Reviértelo en cuanto sea posible.
• WSL2/Hyper-V: revisa la conectividad de adaptadores virtuales y el NAT si tu flujo depende del puente con máquinas virtuales o subsistemas Linux. Pequeños cambios en conmutadores virtuales pueden marcar la diferencia.

Sea cual sea la mitigación elegida, pruébala primero en un entorno de staging y documenta cada ajuste para no perder trazabilidad.

Impacto operativo y riesgos a considerar

El daño inmediato es la productividad: equipos enteros pierden horas en incidentes que no están en su código, pipelines se rompen y tareas automatizadas fallan. A eso se suma el riesgo de “remedios” excesivos: desactivar protocolos o bajar defensas de seguridad para salir del paso.

En organizaciones con compliance estricto (GDPR, HIPAA, ISO 27001), las excepciones improvisadas generan dolor de cabeza. Cualquier cambio en firewall o protocolo debe quedar registrado, con plan de reversión y evaluación de impacto. Y en productos con cadencias de release cortas, el golpe en CI/CD se traduce en entregas retrasadas.

Una semana complicada para Microsoft: más tropiezos en paralelo

El barullo de ‘localhost’ ha coincidido con otros incidentes. La Media Creation Tool llegó a romperse justo antes del adiós de Windows 10, complicando instalaciones y actualizaciones en el peor momento posible. Además, cada vez es más difícil esquivar el requisito de cuenta en línea durante instalaciones limpias de Windows 11.

En sentido contrario, Microsoft sí se ha movido muy rápido ante otro fallo crítico de la misma hornada: lanzó un parche fuera de banda (KB5070773) para recuperar teclado y ratón USB en el Entorno de Recuperación de Windows (WinRE), que había quedado inutilizable. Es un buen ejemplo de reacción ágil, aunque no ha habido el mismo grado de inmediatez con ‘localhost’.

Recomendaciones prácticas para ingenieros y administradores

Mientras llega el arreglo oficial, conviene adoptar disciplina operativa. Estas pautas te ayudarán a mantener el barco a flote sin abrir nuevos agujeros:

• Pausar o deshacer la actualización problemática si existe correlación clara con el fallo, alineando la decisión con seguridad/IT.
• Forzar HTTP/1.1 en desarrollo y pruebas locales, sin replicar ese cambio de forma indiscriminada en producción.
• Monitorizar el Windows Health Dashboard y los canales de soporte de Microsoft, además de issues en GitHub y foros técnicos.
• Aumentar el nivel de logs, capturar reproducciones mínimas y documentar HRESULTs o códigos de error de protocolo.
• Evitar “apagones” globales de HTTP/2: mejor mitigaciones localizadas y temporales hasta que haya parche del sistema.

Cómo escalar el caso con pruebas útiles

Si necesitas elevar el incidente a soporte o compartirlo con la comunidad, prepara evidencias ordenadas. Eso acelera diagnósticos y reduce ida y vuelta estéril:

• Versión exacta de Windows, fecha de la actualización y build instalada.
• Pasos mínimos para reproducir, comandos de cliente/servidor y salida esperada vs. real.
• Mensajes de error, códigos y extractos de logs que señalen la fase en la que rompe (negociación, envío de datos, cierre).
• Cuando sea posible, trazas de red que muestren resets o fallos en frames SETTINGS/ALPN.

Buenas prácticas para evitar disgustos similares en el futuro

Incidentes de este tipo recuerdan la importancia de jugar en equipo entre desarrollo, operaciones y seguridad. Planifica ventanas de pruebas de parches con WSUS u otras herramientas de orquestación, escalonando la llegada a desarrollo, preproducción y producción.

Vigila los cambios en la pila de red con Sysmon y alertas específicas (firewall, DNS, SChannel, HTTP). Donde tenga sentido, encapsula entornos locales en contenedores (Docker Compose) o proxys reversos (Traefik, Caddy) para domesticar dependencias del host y reducir sorpresas.

Desde ciberseguridad, valida que las mitigaciones no abren puertas indeseadas. Escanea configuraciones y documenta excepciones de firewall bajo la óptica de OWASP A05:2021 (Security Misconfiguration). Y si tienes flujos con WSL2, Hyper-V o redes virtuales, incluye esos componentes en tu checklist de compatibilidad post-parche.

Lo que se espera ahora de Microsoft

El desenlace lógico: reconocimiento explícito y parche correctivo que restaure el comportamiento previo de HTTP.sys en loopback. Hasta entonces, la realidad manda: quien necesite trabajar hoy debe revertir la actualización, forzar HTTP/1.1 o frenar Windows Update de forma temporal mientras se estabiliza todo.

La ironía de esta historia es que no discute la ambición de Windows 11, sino la rutina. Un sistema operativo se gana la confianza cuando lo básico nunca falla. Si una acumulativa te deja sin ‘localhost’, el problema no es el futuro; es el presente.

Guía de comprobaciones rápida para tu equipo

Para equipos que buscan una lista de control concisa, estas acciones encadenadas ayudan a recuperar ritmo sin correr riesgos innecesarios:

• Verifica si el fallo desaparece al forzar HTTP/1.1 y si sólo aparece al negociar HTTP/2.
• Prueba ‘::1’ y confirma si la regresión afecta por igual a IPv4/IPv6 en tu entorno.
• Si decides desinstalar KB5066835/KB5065789, documenta el cambio y pausa Windows Update temporalmente.
• Considera la mitigación alternativa de deshabilitar HTTP/2 a nivel de sistema sólo mientras llega el parche.
• Comunica a tu organización el estado, el riesgo y el plan de reversión para mantener alineados a desarrollo, QA y seguridad.

Queda claro que una actualización que debía aportar estabilidad ha destapado un flanco muy doloroso: ‘localhost’ es el nervio del trabajo diario, y sin él el resto de promesas se quedan en papel. Con las soluciones temporales arriba y una política prudente de parches, es posible seguir avanzando sin romper más cosas por el camino.