ERR_HTTP_RESPONSE_CODE_FAILURE: What It Means and Where It Comes From
net::ERR_HTTP_RESPONSE_CODE_FAILURE is Chromium network error -379: a non-2xx HTTP response reached a caller that inspects the status code itself. Chromium's own comment is explicit — the error «is only used by certain APIs that interpret the HTTP response itself. URLRequest for instance just passes most non-2xx response back as success». That is why a 404 stylesheet on an ordinary page never produces it: you simply see a 404 in DevTools. It surfaces where something other than normal page rendering fetches a URL — a WebView or Cast shell loading the app, a PAC proxy script, a certificate fetch, an extension update, or an automation driver such as Playwright.
Below: the exact places Chromium raises it, how to find the failing URL, and what to check per environment.
Free online tool — HTTP header checker: instant results, no signup.
Where Chromium actually raises it
The mechanism is SimpleURLLoader. With allow_http_error_results left at its default of false, «if a non-2xx result is received (other than a redirect), the request will fail with net::ERR_HTTP_RESPONSE_CODE_FAILURE without waiting to read the response body, though headers will be accessible through response_info()» (simple_url_loader.h). Every call site is a component that fetches a URL outside normal page loading and treats a bad status as fatal.
| Who fetches | Condition | What the user sees |
|---|---|---|
PAC proxy script fetch pac_file_fetcher_impl.cc | status is not exactly 200 | Proxy auto-config never loads; corporate network or VPN fails to come up |
Certificate fetch — AIA / CRL cert_net_fetcher_url_request.cc | status is not 200 | Chain building or revocation check fails |
Extension update extension_downloader_delegate.cc | non-2xx, HTTP code carried with the failure | Extension silently stops updating |
| Embedder shells — Android WebView, Cast | the shell navigates to a URL answering non-2xx | «Webpage not available» instead of the app |
| Automation drivers — Playwright, Puppeteer | navigation target does not answer 2xx | The test fails at navigation, not at an assertion |
Note the strictness of the first two: the PAC fetcher and the certificate fetcher both compare against 200 exactly. A 204, or a 302 that ends on a captive-portal login page, is enough to fail them.
What this error is not
- Not a TLS or handshake failure. Error -379 has no TLS in its path — it is decided after a response has already arrived, by reading its status line.
- Not a 404 on a stylesheet, script or image in a normal page. Those go through
URLRequest, which «passes most non-2xx response back as success» (net_error_list.h); the resource load reports the 404 itself. - Not fixed by purging a CDN — unless the CDN is what answers non-2xx to the specific fetch that failed, which you can only know after you have the URL.
Step 1 — find the failing URL
Every fix below depends on knowing which request got the bad status. Guessing is what makes this error feel unfixable.
- Open
chrome://net-exportand start logging to disk. - Reproduce the failure.
- Stop logging and open the file in the NetLog viewer.
- Search for
HTTP_RESPONSE_CODE_FAILUREor-379. The surrounding events carry the request URL and the response headers.
On Android, attach to the WebView from desktop Chrome via chrome://inspect and read the Network panel there; adb logcat shows the shell-level failure but usually not the URL.
Step 2 — fix by environment
Android WebView shell (Capacitor, Cordova, custom)
The shell navigates to a start URL and gets a non-2xx, so it renders «Webpage not available» instead of your app. The reports that reproduce only for store-delivered builds and not for the same APK installed by hand (see Capacitor issue #4743, closed without a reproduction) point at what the device requests, not at the app code. Capture the URL first, then check whether a WAF, geo rule or A/B split answers non-2xx to that subset of clients.
Corporate proxy or VPN (PAC)
Fetch the PAC URL the way the browser does and require an exact 200:
curl -i --proxy "" "http://proxy.example.com/proxy.pac"A 401, 403, 404 or 500 fails the fetch outright. So does a redirect that lands on an SSO or captive-portal page — the fetcher wanted the script, not a login form.
Certificate validation (AIA / CRL)
List the URLs embedded in the certificate and check each one answers 200:
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A2 "Authority Information Access"Playwright / Puppeteer in CI
Navigation failed because the target did not answer 2xx — the browser is reporting the environment, not a flaky test. Assert the server is actually listening before the first navigation, and check the base URL the job passes in; a 401 from basic auth or a 502 from a container that has not finished starting are the usual causes.
Extensions
The update URL must answer 2xx. A self-hosted update_url behind an auth gate produces this error and nothing else visible.
Related network errors
- ERR_BLOCKED_BY_RESPONSE — blocked by CSP, X-Frame-Options or CORP, not by TLS
- ERR_EMPTY_RESPONSE — connection closed with no data
- ERR_TOO_MANY_REDIRECTS — redirect loop
Learn more
Frequently Asked Questions
Is this an SSL or certificate problem?
No. Error -379 is decided by reading an HTTP status line, with no TLS in the path. The one certificate-adjacent case is Chrome fetching an AIA or CRL URL during validation: there the failing request is a plain HTTP fetch of the issuer certificate or revocation list, not the handshake.
A stylesheet on my page returns 404 — why do I not see this error?
Because ordinary resource loads do not use an API that interprets the status. Chromium states it plainly: this error "is only used by certain APIs that interpret the HTTP response itself. URLRequest for instance just passes most non-2xx response back as success." You get a 404 in DevTools instead.
How do I find out which URL failed?
Capture a NetLog: chrome://net-export, start logging, reproduce, stop, then search the file for HTTP_RESPONSE_CODE_FAILURE. The request URL and response headers sit in the surrounding events. On Android WebView, attach via chrome://inspect and use the Network panel.
It only happens for users who installed from the Play Store, not for the same APK installed by hand.
That pattern has been reported and never reproduced upstream (Capacitor issue #4743 was closed for lack of a reproduction). It means the failing request differs between those installs, so capture the URL from an affected device before changing app code — a WAF rule, a geo restriction or a staged rollout answering non-2xx to a subset of clients all produce exactly this.
Playwright reports it in CI but the site works in my browser.
Navigation could not get a 2xx from the target. Check that the web server in the job actually started, that the base URL passed to the runner is the one you expect, and that no basic-auth or SSO gate answers 401 to the automation.
Try the live tool that powered this guide
Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.