Nach den jüngsten Windows-11-Patches berichten Nutzer vermehrt über instabile localhost-Verbindungen: HTTP/2-Sessions zu 127.0.0.1 werden zurückgesetzt. Betroffen sind Systeme nach dem Oktober-Kumulativupdate KB5066835 sowie dem September-Preview KB5065789. Die Ausfälle sind in Microsoft-Community-Foren, auf Stack Exchange und Reddit breit dokumentiert.
Problemüberblick: HTTP/2 verweigert Loopback-Verbindungen
Beim Aufbau eines HTTP/2-Transports zu lokal laufenden Diensten bricht der Verbindungsaufbau ab. Browser und Clients melden typischerweise ERR_CONNECTION_RESET oder ERR_HTTP2_PROTOCOL_ERROR. Praktisch bedeutet das: Entwicklungs- und Test-Workflows auf localhost scheitern, ebenso Anwendungen, die lokale Webendpunkte für Authentifizierung, Geräte-Health oder Datenaustausch nutzen.
Betroffene Tools und Szenarien
Die Störung trifft eine breite Toolkette. Berichtet werden Debugging-Probleme aus Visual Studio, Authentifizierungsfehler in SSMS Entra ID sowie Ausfälle bei Duo Desktop/Duo Prompt, die lokale HTTP/2-Endpunkte nutzen. Laut Supporthinweis von Duo können auf Windows 11 24H2/25H2 nach den genannten Updates Duo Prompt-Flows nicht auf Duo Desktop zugreifen. Das führt zu fehlerhafter Anmeldung oder eingeschränkter Zero-Trust-Funktionalität (z. B. Trusted Endpoints, Device Health, Duo Passport, Verified Duo Push mit Bluetooth-Autofill/Proximity Verification).
Mögliche technische Ursache im Netzwerk-Stack
Offizielle Root-Cause-Details liegen noch nicht vor. Der Fehlermodus deutet auf Änderungen im Windows-Netzwerkstack bei der HTTP/2-Verarbeitung auf dem Loopback-Interface hin. HTTP/2 nutzt Multiplexing, Header-Kompression und die ALPN-Aushandlung (Application-Layer Protocol Negotiation). Schon kleine Anpassungen in HTTP.sys oder der ALPN-Policy können dazu führen, dass lokale HTTP/2-Streams auf 127.0.0.1 verworfen werden. Obwohl es um lokalen Verkehr geht, sind die Auswirkungen geschäftskritisch – von SSO-Flows bis CI/CD-Pipelines.
Temporäre Workarounds
HTTP/2 systemweit deaktivieren (Registry)
Als verlässlicher Hotfix gilt die Deaktivierung von HTTP/2 auf Betriebssystemebene (gemäß Berichten u. a. bei BornCity). In HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters die DWORD-Werte EnableHttp2Tls=0 und EnableHttp2Cleartext=0 setzen. Dadurch fällt der Stack auf HTTP/1.1 zurück, was die Verbindungsabbrüche beseitigt. Beachten Sie mögliche Performance- und Funktionsverluste. Ein Neustart ist erforderlich; Ausrollung ist via GPO/Skripte steuerbar.
Microsoft-Defender-Signaturen aktualisieren
Ein Teil der Anwender berichtet über Besserung nach Aktualisierung der Microsoft Defender-Signaturen. Dieser Ansatz ist jedoch inkonsistent und nicht in allen Umgebungen wirksam.
Problematische Updates deinstallieren
Der bislang zuverlässigste Weg ist der Rollback der Pakete KB5066835 und KB5065789 mit anschließendem Neustart. Danach akzeptiert der Loopback-Stack wieder HTTP/2-Verbindungen.
Empfehlungen für IT und Entwickler
Patch-Management und Monitoring
Stoppen Sie die breitflächige Verteilung der Updates vorübergehend in WSUS/Intune und setzen Sie auf gestaffelte Pilotringe. Erhöhen Sie das Monitoring für lokale Verbindungsfehler, sammeln Sie System- und Applikationslogs sowie HTTP/2-Traces, und dokumentieren Sie Vorfälle im Ticket-System. Verfolgen Sie offizielle Hinweise von Microsoft sowie der betroffenen Hersteller (z. B. Duo).
Mitigation auf Anwendungsebene
Erzwingen Sie bis zur Fehlerbehebung HTTP/1.1, sofern möglich: per Client-Flags (z. B. curl –http1.1), SDK/Framework-Settings oder durch Upstream-/Reverse-Proxies. Prüfen Sie in latenzsensitiven Services die Auswirkungen des Protokollwechsels, bevor Sie die systemweite Registry-Mitigation ausrollen.
Quellenlage und Verifizierung
Die Problematik ist über mehrere unabhängige Kanäle belegt, darunter Microsoft-Community-Threads, Stack Exchange, Reddit, Analysen bei BornCity sowie ein Support-Bulletin von Duo. Bis zu einer offiziellen Ursachenanalyse empfiehlt sich eine enge Beobachtung der Release Notes und Health-Dashboards von Microsoft sowie der betroffenen Drittanbieter.
Organisationen, die ERR_CONNECTION_RESET oder ERR_HTTP2_PROTOCOL_ERROR auf 127.0.0.1 nach KB5066835/KB5065789 sehen, sollten kurzfristig einen der genannten Workarounds umsetzen, Vorfälle dokumentieren und Updates nur nach erfolgreichem Pilottest freigeben. Ein strukturiertes Patch-Management mit Telemetrie, klaren Rollback-Pfaden und frühzeitiger Kommunikation minimiert Betriebsrisiken und sichert die Cyber-Resilienz.
