AdGuard объяснила, почему в версии AdGuard 7.22 для Windows зависали страницы, и как проблема была устранена

После выхода версии AdGuard для Windows 7.22 в начале октября 2025 года у некоторых пользователей появились сбои при загрузке веб-страниц. Обновление привело к серьёзным задержкам в загрузке страниц и ошибкам «Timed Out», особенно в браузере Firefox.

Проблема оказалась редкой и сложной для воспроизведения: Chrome-пользователи почти не замечали её, а в Firefox она проявлялась чаще. В официальном отчёте об инциденте команда AdGuard извинилась за неудобства и сообщила, что выпустила хотфикс AdGuard v7.22.1, полностью устраняющий проблему. На данный момент уже доступна версия AdGuard для Windows 7.22.2.

Хронология событий

• 2 октября: вышла версия AdGuard для Windows 7.22.
• 4 октября: пользователь открыл задачу на GitHub с жалобами на медленную загрузку страниц и ошибки «Timed Out» после обновления до 7.22.
• 6 октября: команда контроля качества (QA) начала расследование, но сразу не смогла воспроизвести баг; информацию передали разработчикам.
• 16 октября: к обсуждению подключились новые пользователи, но из-за разнородности отчётов проблему приняли за баг одной из предыдущих версий и решили исправить в следующем релизе. Хотя инциденту был присвоен приоритет «P1: Critical», он не был должным образом эскалирован, и на решение ушло больше времени, чем следовало.
• 30 октября: спустя 24 дня проблему снова подняли: её удалось воспроизвести, и началась работа над хотфиксом v7.22.1. При расследовании обнаружили сопутствующие проблемы: баг в Firefox, связанный с QUIC (HTTP/3), и отдельную ошибку фильтрации QUIC при работе AdGuard в режиме совместимости с программой AdGuard для перенаправления трафика при отключённом Wintun.
• 1 ноября: частично установлена причина сбоя и выпущен ночной билд с исправлением в DNS-движке DnsLibs для тестирования.
• 5 ноября: обнаружена основная причина — ошибка в компоненте CoreLibs, ответственном за детекцию зацикливания маршрутизации. Ошибка исправлена, выпущен второй nightly-билд.
• 6 ноября: тесты nightly-сборок показали, что исправления устранили большинство проблем с TCP-соединениями, но остались проблемы с UDP. Решено было выпускать обновления поэтапно: сначала третий nightly-билд с доработками, а затем в тот же день – финальный патч v7.22.1, который полностью решил проблему.

Технические детали

По данным отчёта, ошибка в AdGuard v7.22 проявлялась в случайных зависаниях при загрузке страниц в Firefox и практически не затрагивала Chrome. Причиной стал новый механизм защиты от зацикливания маршрутизации, введённый в CoreLibs v1.19. Этот механизм прекращает только те соединения, которые возвращаются к исходному приложению и выглядят как потенциальная петля. У этого бага было две основные причины:

• Программная ошибка, из-за которой один из портов исключался из проверки на петли. В результате некоторые нормальные соединения (например, запросы браузера после внутренних сервисных запросов типа OCSP) могли блокироваться.
• Проверка зацикливания применялась в неправильном месте — к уже установленным соединениям, что приводило к лишним обрывам соединений.

Зацикливание маршрутизации – ситуация, когда сетевой пакет потенциально бесконечно маршрутизируется по кругу. Такие петли замедляют соединения и сильно нагружают CPU. Для предотвращения подобных случаев AdGuard отслеживает исходящие соединения по адресу-источнику и разрывает соединения, возвращающиеся к тому же адресу.

Chrome-пользователи почти не заметили инцидент, поскольку браузер автоматически повторял неудачные запросы. После сбоя соединения Chrome пробовал отправить запрос повторно, и проблемы оставались малозаметными. Firefox же не делает автоматических повторных попыток при сетевых ошибках, поэтому один единственный сбой сразу приводил к задержке загрузки.

На других платформах сбоя не наблюдалось. В AdGuard CLI для Linux с версией CoreLibs 1.19 баг практически не проявился – он возникал только в авторежиме Linux и преимущественно на Firefox, а число таких пользователей было очень небольшим. В AdGuard для Android v4.12 (тоже с CoreLibs 1.19) аналогичная проблема не возникала: на Android адреса исходящих и входящих соединений отличаются, и условия, необходимые для зацикливания, не создаются.

Диагностика

По сообщениям AdGuard, найти причину было непросто. Программа открывает относительно мало служебных соединений, а часть OCSP-запросов часто поступала из кеша, из-за чего ошибка при повторных попытках воспроизведения могла не проявляться. Кроме того, сбой касался только одного соединения за раз. Большинство пользователей Chrome не замечало проблемы (браузер автоматически повторял сбои), тогда как Firefox сразу выдавал ошибку без дополнительных попыток.

Обнаруженный побочный баг HTTP/3 в Firefox

При анализе выяснилось, что часть отчётов содержала иные симптомы: они повторялись и в старых версиях AdGuard. Так был обнаружен отдельный баг Firefox с HTTP/3: браузер сразу пытается установить HTTP/3-соединение, если сайт его поддерживает, даже если такое соединение ещё не установлено. AdGuard по умолчанию не фильтрует HTTP/3, и при включённой HTTPS-фильтрации Firefox видел поддержку HTTP/3 (например, из DNS-записи типа HTTPS) и назначал запросы на HTTP/3-соединение, которое ещё не было установлено. При невозможности установить HTTP/3 это приводило к паузам в загрузке (~20–30 секунд), после чего запросы переназначались на активное HTTP/2-соединение.

По итогам был создан отчёт в Bugzilla, а в AdGuard внедрили временную меру: модифицировали DNS-записи типа HTTPS, удалив из них параметр h3 ALPN. Это скрывает от браузера факт поддержки HTTP/3 в случаях, когда трафик всё равно будет заблокирован фильтром.

Исправление

Исправление бага шло в два этапа. Сначала обновили логику сопоставления соединений: добавили учёт порта в проверке зацикливания. Это решило основную часть проблем, однако до конца ошибки не исчезли: оказалось, что Windows может повторно использовать порт недавно закрытого исходящего соединения в течение ~1 секунды, из-за чего несвязанные соединения с тем же адресом и портом ошибочно идентифицировались как петли маршрутизации. На втором этапе учли и этот сценарий. В результате вышел финальный хотфикс AdGuard v7.22.1, полностью устранивший проблему.

Профилактические меры

В отчёте подчёркивается, что основная причина замедленного реагирования — сложность воспроизведения бага и первоначально недостаточное внимание к отзывам пользователей. Чтобы избежать подобных ситуаций в будущем, в AdGuard пересматривают процессы разработки и тестирования, усиливая контроль, автоматизацию и коммуникацию между командами.

Изменения в работе QA-команды

• Усилен мониторинг активности задач на GitHub: число комментариев и «лайков» (upvotes) теперь автоматически отслеживается, чтобы быстрее выявлять критические проблемы.
• Проведён дополнительный брифинг по инструкции triage (приоритезации багов) и введено обязательное внутреннее рассмотрение задач в Jira для обоснования их приоритетов.
• Составлен набор диагностических вопросов для пользователей, помогающий уточнять и анализировать проблемы с фильтрацией на основе обратной связи.
• Внедряются новые автотесты: разрабатывается скрипт-бенчмарк для оценки скорости фильтрации страниц в разных браузерах и постановки эталонных показателей; готовятся тесты на скорость загрузки известных «проблемных» сайтов (например, discord.com).

Изменения в работе команды разработки

• При разработке новых функций будет повышено внимание к тестированию: добавят интеграционные и другие автотесты, чтобы снизить риск ошибок в будущих релизах.
• Усилится техническая документация по новым возможностям и информирование вовлечённых команд о необходимости дополнительного тестирования, чтобы не упускать потенциальные уязвимости.
• Перед интеграцией новых версий CoreLibs продуктовые команды теперь будут ждать явного одобрения от команды CoreLibs, а не действовать «в изоляции». Это изменение должно снизить риск пропустить подобную проблему при следующей синхронизации движков.