ERR_HTTP_RESPONSE_CODE_FAILURE: что означает и откуда берётся
net::ERR_HTTP_RESPONSE_CODE_FAILURE — сетевая ошибка Chromium -379: ответ со статусом не 2xx дошёл до вызывающего, который сам читает код статуса. Комментарий в исходниках Chromium говорит об этом прямо: ошибка «используется только некоторыми API, которые сами интерпретируют HTTP-ответ. URLRequest, например, отдаёт большинство ответов не 2xx как успех». Поэтому таблица стилей с 404 на обычной странице эту ошибку не вызывает — вы просто видите 404 в DevTools. Она появляется там, где URL загружает не обычный рендеринг страницы: оболочка WebView или Cast, PAC-скрипт прокси, загрузка сертификата, обновление расширения или драйвер автоматизации вроде Playwright.
Ниже: где именно Chromium её поднимает, как найти отказавший URL и что проверять в каждом окружении.
Бесплатный онлайн-инструмент — проверка HTTP-заголовков: результат мгновенно, без регистрации.
Где Chromium её действительно поднимает
Механизм — SimpleURLLoader. Если allow_http_error_results оставлен в значении по умолчанию false, то «при получении результата не 2xx (кроме редиректа) запрос завершится ошибкой net::ERR_HTTP_RESPONSE_CODE_FAILURE, не дожидаясь чтения тела ответа, хотя заголовки будут доступны через response_info()» (simple_url_loader.h). Каждое место вызова — это компонент, который загружает URL вне обычного рендеринга страницы и считает плохой статус фатальным.
| Кто загружает | Условие | Что видит пользователь |
|---|---|---|
Загрузка PAC-скрипта прокси pac_file_fetcher_impl.cc | статус не ровно 200 | Автонастройка прокси не загружается, корпоративная сеть или VPN не поднимается |
Загрузка сертификата — AIA / CRL cert_net_fetcher_url_request.cc | статус не 200 | Не строится цепочка или не проходит проверка отзыва |
Обновление расширения extension_downloader_delegate.cc | не 2xx, HTTP-код передаётся вместе с ошибкой | Расширение тихо перестаёт обновляться |
| Встраиваемые оболочки — Android WebView, Cast | оболочка открывает URL, отвечающий не 2xx | «Веб-страница недоступна» вместо приложения |
| Драйверы автоматизации — Playwright, Puppeteer | цель перехода не отвечает 2xx | Тест падает на переходе, а не на проверке |
Обратите внимание на строгость первых двух: загрузчик PAC и загрузчик сертификатов сравнивают статус ровно с 200. Достаточно 204 или 302, приводящего на страницу входа кэптив-портала, чтобы они отказали.
Чем эта ошибка не является
- Это не сбой TLS и не проблема рукопожатия. У ошибки -379 в пути нет TLS вообще — она принимается уже после того, как ответ пришёл, чтением строки статуса.
- Это не 404 на стиле, скрипте или картинке обычной страницы. Они идут через
URLRequest, который «отдаёт большинство ответов не 2xx как успех» (net_error_list.h); о 404 сообщает сама загрузка ресурса. - Сброс кэша CDN её не лечит — если только именно CDN не отвечает не 2xx на тот конкретный запрос, который отказал, а это можно узнать только получив URL.
Шаг 1 — найти отказавший URL
Любое исправление ниже требует знать, какой запрос получил плохой статус. Именно догадки делают эту ошибку неисправимой на вид.
- Откройте
chrome://net-exportи начните запись лога на диск. - Воспроизведите сбой.
- Остановите запись и откройте файл в просмотрщике NetLog.
- Найдите
HTTP_RESPONSE_CODE_FAILUREили-379. В соседних событиях лежат URL запроса и заголовки ответа.
На Android подключитесь к WebView из десктопного Chrome через chrome://inspect и смотрите панель Network там; adb logcat покажет сбой на уровне оболочки, но обычно без URL.
Шаг 2 — исправление по окружениям
Оболочка Android WebView (Capacitor, Cordova, своя)
Оболочка открывает стартовый URL, получает не 2xx и рисует «Веб-страница недоступна» вместо приложения. Сообщения о том, что сбой воспроизводится только на сборках из магазина и не воспроизводится на том же APK, установленном вручную (см. issue Capacitor #4743, закрыт без воспроизведения), указывают на то, что запрашивает устройство, а не на код приложения. Сначала получите URL, затем проверьте, не отвечает ли WAF, гео-правило или A/B-раскатка статусом не 2xx этой части клиентов.
Корпоративный прокси или VPN (PAC)
Запросите PAC-URL так же, как это делает браузер, и требуйте ровно 200:
curl -i --proxy "" "http://proxy.example.com/proxy.pac"401, 403, 404 или 500 роняют загрузку сразу. Редирект, приводящий на страницу SSO или кэптив-портала, — тоже: загрузчику нужен скрипт, а не форма входа.
Проверка сертификата (AIA / CRL)
Выпишите URL, зашитые в сертификат, и проверьте, что каждый отвечает 200:
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A2 "Authority Information Access"Playwright / Puppeteer в CI
Переход не состоялся, потому что цель не ответила 2xx, — браузер сообщает об окружении, а не о нестабильном тесте. Убедитесь, что сервер действительно слушает до первого перехода, и проверьте базовый URL, который передаёт джоба: обычные причины — 401 от basic-auth или 502 от контейнера, который не успел подняться.
Расширения
URL обновления обязан отвечать 2xx. Свой update_url за авторизацией даёт эту ошибку и больше ничего заметного.
Смежные сетевые ошибки
- ERR_BLOCKED_BY_RESPONSE — блокировка по CSP, X-Frame-Options или CORP, а не по TLS
- ERR_EMPTY_RESPONSE — соединение закрыто без данных
- ERR_TOO_MANY_REDIRECTS — петля редиректов
Больше по теме
Часто задаваемые вопросы
Это проблема SSL или сертификата?
Нет. Ошибка -379 принимается чтением строки статуса HTTP, TLS в её пути нет. Единственный случай рядом с сертификатами — когда Chrome при проверке загружает URL из AIA или CRL: там отказывает обычная HTTP-загрузка сертификата издателя или списка отзыва, а не рукопожатие.
Таблица стилей на моей странице отдаёт 404 — почему я не вижу этой ошибки?
Потому что обычные загрузки ресурсов не используют API, интерпретирующий статус. В Chromium сказано прямо: ошибка «используется только некоторыми API, которые сами интерпретируют HTTP-ответ. URLRequest, например, отдаёт большинство ответов не 2xx как успех». Вместо неё вы видите 404 в DevTools.
Как узнать, какой URL отказал?
Снимите NetLog: chrome://net-export, начать запись, воспроизвести, остановить, затем найти в файле HTTP_RESPONSE_CODE_FAILURE. URL запроса и заголовки ответа лежат в соседних событиях. Для Android WebView подключитесь через chrome://inspect и смотрите панель Network.
Ошибка только у тех, кто установил приложение из Google Play, а тот же APK вручную работает.
Такой сценарий описывали, но воспроизвести его upstream не удалось (issue Capacitor #4743 закрыт из-за отсутствия воспроизведения). Это значит, что отказавший запрос между установками различается: снимите URL с затронутого устройства до правок в коде — правило WAF, гео-ограничение или поэтапная раскатка, отвечающая не 2xx части клиентов, дают ровно такую картину.
Playwright показывает её в CI, хотя в браузере сайт открывается.
Переход не получил 2xx от цели. Проверьте, что веб-сервер в джобе действительно стартовал, что базовый URL для раннера тот, который вы ожидаете, и что basic-auth или SSO не отвечает автоматизации кодом 401.
Запустить инструмент, который описан в этой статье
Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.