ERR_HTTP_RESPONSE_CODE_FAILURE (-379): Where It Comes From and How to Fix

net::ERR_HTTP_RESPONSE_CODE_FAILURE is Chromium network error -379: the server returned a non-2xx status to a caller that inspects the status code itself. Chromium's own comment in net_error_list.h 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». DNS, TCP and TLS all worked; the decision is made after a response has arrived, by reading its status line.

Two mechanisms raise it. The first 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). Components that fetch a URL outside normal page loading use it and treat a bad status as fatal. The second is the main-frame navigation check in http_error_navigation_throttle.cc: when a top-level page answers 400 or higher, Chrome has its own error page for that status and the response body is empty, Chrome cancels the navigation and shows that page instead. It is not a TLS error, not a 404 on a stylesheet or image inside a normal page (DevTools simply shows the 404), and not something a CDN purge fixes unless the CDN is what answers non-2xx to the failing request.

Note the strictness of the PAC and certificate fetchers: both compare against 200 exactly, so a 204 is enough to fail them. Both follow redirects, so what counts is the status of the final response: a redirect that ends on an SSO or captive-portal page answering 403 or 404 fails the fetch, because the fetcher wanted a script or a certificate, not a login form. A PAC server that asks for credentials (401) also aborts the fetch, with a different error code, because Chromium does not authenticate PAC downloads. The certificate fetcher only fetches plain http:// URLs.

The page-load case is the one ordinary visitors meet. Many frameworks answer an unhandled error with a bare 500 and no body; Chrome then replaces the empty page with its own. If the server sends any body at all, even a one-line HTML error page, Chrome renders that instead and the -379 page does not appear.

A proxy matters here in two ways: it may be what answers non-2xx to a subset of clients (a WAF rule, geo block, bot score or basic-auth gate that hits a WebView, a CI runner or a PAC fetch but not your desktop browser), and it decides whether an empty upstream error reaches the browser. With nginx, proxy_intercept_errors replaces an upstream's empty 5xx with your own error page, which also removes Chrome's -379 page for real visitors:

location / {
    proxy_pass http://app;
    proxy_intercept_errors on;
    error_page 500 502 503 504 /50x.html;
}
location = /50x.html {
    root /usr/share/nginx/html;
    internal;
}

# Serve a PAC file outside any auth gate
location = /proxy.pac {
    auth_basic off;
    default_type application/x-ns-proxy-autoconfig;
    root /var/www/pac;
}

On Cloudflare, check Security Events for the failing URL and client: a block there returns 403 to exactly the clients that report -379, while your own tests pass.

1. Find the failing URL. Every fix depends on knowing which request got the bad status. Open chrome://net-export, start logging to disk, reproduce, stop, open the file in the NetLog viewer and search for HTTP_RESPONSE_CODE_FAILURE or -379; the surrounding events carry the request URL and response headers. On Android, attach to the WebView from desktop Chrome via chrome://inspect and read the Network panel; adb logcat shows the shell-level failure but usually not the URL.
2. Read its status and body size.

   curl -s -o /dev/null -w '%{http_code} %{size_download}\n' https://example.com/path
   # 500 0  -> error status with an empty body

3. Page loads: fix the error behind the 4xx/5xx in the application log, and make error responses carry a body (a framework error template, or nginx error_page as above).
4. Android WebView shell (Capacitor, Cordova, custom): the shell gets a non-2xx for its start URL. Reports that reproduce only for store-delivered builds and not for the same APK installed by hand (Capacitor issue #4743, closed without a reproduction) point at what the device requests, not at app code. Check whether a WAF, geo rule or A/B split answers non-2xx to that subset of clients.
5. Corporate proxy or VPN (PAC): fetch the PAC URL directly and require an exact 200:

   curl -i --noproxy '*' http://proxy.example.com/proxy.pac

6. Certificate validation (AIA / CRL): list the URLs embedded in the certificate and check that each answers 200 over plain HTTP:

   openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
     | openssl x509 -noout -text | grep -A2 -E 'Authority Information Access|CRL Distribution'

   If chain building still fails, see ERR_CERT_AUTHORITY_INVALID.
7. Playwright / Puppeteer in CI: the browser is reporting the environment, not a flaky test. Assert the server is 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.
8. Extensions: a self-hosted update_url behind an auth gate produces this error and nothing else visible. It must answer 2xx.

In most cases the fault is not on your side: the server, or a proxy in front of it, answered with an error status. Reload once in case it was a transient 5xx, then try another network or mobile data to rule out a network-specific block. Clearing the browser cache does not help, because the server answered the request fresh.

If the failure is on a corporate network and many sites fail at once, the PAC proxy script probably did not load: that is for your IT team, and the error in chrome://net-export shows them the PAC URL. If an app built on Android WebView shows «Webpage not available», report it to the app developer with your network and region; reinstalling rarely changes what the server answers.

Re-run the request and require a 2xx, or at least a non-empty body for an error page:

curl -s -o /dev/null -w '%{http_code} %{size_download}\n' https://example.com/path
# 200 18342

Then repeat the original scenario with chrome://net-export running and confirm -379 no longer appears. To see the status code and headers a URL returns from outside your network, use the HTTP status checker.

• ERR_BLOCKED_BY_RESPONSE — blocked by CSP, X-Frame-Options or CORP, not by the status code
• ERR_EMPTY_RESPONSE — connection closed with no data at all
• ERR_INVALID_HTTP_RESPONSE — the response could not be parsed
• ERR_TOO_MANY_REDIRECTS — redirect loop