Как отличить известную регрессию Firefox 155 в сетях с блокировкой UDP от DNS, proxy и сбоя сайта, а затем безопасно проверить обратимый policy-workaround.
Какой дефект признала Mozilla
Короткий ответ: в Firefox 155 Mozilla признала ошибку, из-за которой некоторые сайты медленно открываются или не открываются в сетях, блокирующих UDP. В notes отдельно названы корпоративные proxy и firewall, где QUIC блокируется как часть TLS inspection. Это не значит, что любой сбой Firefox 155 имеет одну причину. Сначала нужен узкий контроль: один URL, одна версия, одна сеть и одно изменение за проход.
Матрица из четырёх контролей
Запишите в одну строку фактическую версию Firefox, URL без query-параметров, тип сети и момент сбоя. Повторите открытие в Firefox ESR или другом поддерживаемом браузере той же машины и в той же сети. Затем Firefox 155 с тем же URL проверьте в обычной доверенной сети, если это разрешено. Не сравнивайте разные сайты и не переключайте одновременно proxy, DNS и endpoint policy: иначе матрица не покажет, какой фактор сработал.
Что указывает именно на HTTP/3 fallback
Bugzilla описывает границу точнее: спекулятивная HTTP/3-попытка могла остаться без TCP fallback, когда UDP блокирован. Поэтому сильный сигнал — Firefox 155 зависает, а ESR или контрольный браузер на той же машине и в той же сети открывает тот же URL. Слабый сигнал — единичная ошибка после долгого uptime, которая исчезла после reload. Отдельно исключите общую недоступность сайта и DNS failure. Наличие VPN не считайте доказанной причиной.
Обратимый workaround для тестовой группы
Mozilla документирует временную меру: задать `network.http.happy_eyeballs_enabled=false` через enterprise `Preferences` policy. Её применяют не ко всем клиентам, а к малой тестовой группе с подтверждённым симптомом. Зафиксируйте исходную policy, примените одно изменение, перезапустите браузер по штатной процедуре и повторите тот же URL. Не отключайте firewall, TLS inspection или весь proxy: это сменит сразу несколько переменных и ослабит защиту.
Критерии PASS, FAIL и UNKNOWN
PASS для рабочей гипотезы означает, что сбой стабильно воспроизводится в Firefox 155 на сети с блокировкой UDP и исчезает только после документированного preference. FAIL — поведение не меняется или тот же сбой виден в контрольном клиенте. UNKNOWN — неизвестны версия, факт UDP-блокировки или применённая policy. Остановитесь, если проверка требует обойти корпоративную policy, установить неизвестный сертификат или раскрыть секреты прокси. После обновления с исправлением временную policy нужно убрать и повторить control.
Что передать в поддержку
Сетевой команде достаточно передать версию Firefox, канал обновлений, тип сети, один обезличенный URL, время с часовым поясом, исход контрольного браузера и результат с preference. Полный HTTP log может содержать адреса, cookies и другие личные данные; его не публикуют. В Bugzilla сама Mozilla просила передавать такие логи по закрытому каналу. Для обычной заявки хватает матрицы и вердикта. Источниики объясняют upstream defect, но не доказывают причину конкретного сбоя без этого контроля.
Материал подготовлен редакцией VOne с помощью автоматизированного черновика. Дата Firefox 155, область дефекта, отличие от ESR и временный workaround сверены 4 сентября 2026 года по официальным notes и Bugzilla Mozilla. Текст не обещает универсальной причины и не предлагает отключать сетевую защиту.
Источники и проверка
- Mozilla Firefox 155 enterprise release notes проверено 2026-09-04
- Mozilla Bugzilla 2063452 — HTTP/3 fallback regression проверено 2026-09-04
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.