Після встановлення кумулятивних оновлень KB5066835 (жовтень) та preview-пакета KB5065789 (вересень) частина користувачів Windows 11 зіткнулася з відмовою HTTP/2-підключень до localhost (127.0.0.1). Типові симптоми — помилки ERR_CONNECTION_RESET і ERR_HTTP2_PROTOCOL_ERROR у браузерах і клієнтах. Інцидент масово фіксується на форумах Microsoft, Stack Exchange, Reddit і підтверджений бюлетенями підтримки вендорів, зокрема Duo.
Суть інциденту: HTTP/2-рукостискання до 127.0.0.1 зривається
Збій проявляється під час спроби встановити HTTP/2-з’єднання з локально запущеним сервісом на loopback-інтерфейсі. Замість успішного рукостискання клієнти отримують скидання з’єднання або протокольні помилки. Це порушує сценарії розробки й тестування на localhost, а також роботу застосунків, що покладаються на локальні веб-служби для SSO, перевірок стану пристрою, взаємодії з агентами безпеки та CI/CD-конвеєрами.
Кого зачепило: розробники, DBA та Zero Trust-агенти
Користувачі повідомляють про збої під час відладки веб-додатків із Visual Studio, проблеми з автентифікацією SSMS Entra ID і порушення роботи Duo Desktop/Duo Prompt, що використовують локальні веб-ендпоінти. За даними підтримки Duo, на системах Windows 11 24H2/25H2 після згаданих оновлень Duo Prompt може втратити доступ до Duo Desktop, що веде до невдалих автентифікацій або обмеженої функціональності у сценаріях Zero Trust (Trusted Endpoints, Device Health, Duo Passport, Verified Duo Push із Bluetooth Autofill/Proximity Verification).
Можливі технічні причини: зміни в мережевому стеку Windows
Офіційних технічних деталей поки небагато. Характер помилок вказує на можливі зміни в обробці HTTP/2 у loopback-шляху Windows — наприклад, у компонентах HTTP.sys або політиках ALPN (узгодження версій протоколу поверх TLS). Оскільки HTTP/2 застосовує мультиплексування потоків і відмінну від HTTP/1.1 семантику, навіть незначні правки можуть спричинити скидання з’єднань на 127.0.0.1. Наслідки відчутні для бізнес-критичних процесів: SSO-потоків, контролю відповідності політикам безпеки та автоматизованих пайплайнів.
Тимчасові обхідні шляхи: реєстр, Defender, відкочування оновлень
Найбільш стабільним на сьогодні способом відновлення роботи є тимчасове відключення HTTP/2 на рівні ОС. За повідомленнями спільноти (зокрема, BornCity), допомагає встановлення значень EnableHttp2Tls=0 і EnableHttp2Cleartext=0 у реєстрі за шляхом HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters. Це змушує локальні підключення використовувати HTTP/1.1 і усуває збої, але може вплинути на продуктивність та функції, що очікують HTTP/2.
Деякі користувачі відзначають покращення після встановлення актуальних сигнатур Microsoft Defender, утім цей підхід працює не для всіх конфігурацій. Якщо проблема зберігається, найнадійніший варіант — видалити пакети KB5066835 і KB5065789 із подальшим перезавантаженням: після відкоту loopback знову приймає HTTP/2-підключення.
Рекомендації для ІТ: керування оновленнями і моніторинг
Для корпоративних середовищ доцільно тимчасово призупинити розповсюдження згаданих патчів через WSUS/Intune, перейти на поетапне розгортання і посилити моніторинг помилок на localhost. Варто фіксувати інциденти в сервіс-деску, збирати журнали мережевого стека та застосунків (включно з трасами HTTP/2) і відстежувати офіційні повідомлення Microsoft і постачальників, чиї продукти використовують локальні веб-ендпоінти.
Рекомендації для розробників: примусовий перехід на HTTP/1.1
До виходу виправлення переведіть локальних клієнтів на HTTP/1.1, якщо це підтримується: параметрами запуску (наприклад, для curl –http1.1), налаштуваннями SDK/фреймворків або конфігурацією зворотних проксі. Для сервісів, чутливих до затримок, попередньо оцініть вплив відмови від HTTP/2 порівняно з системним обходом через реєстр.
Проблема з HTTP/2 на
