Geonode logo
Network errors

How to Fix ERR_EMPTY_RESPONSE in Chrome

Checks that tell a silent site from a failing proxy or dev server, and the fix for each.

Updated

Get residential proxiesCheck your proxy

TL;DR

ERR_EMPTY_RESPONSE means Chrome sent an HTTP/1.1 request and the server, or a proxy in between, closed the connection without sending a byte back. Reload once; if it still fails, find out whether your proxy, your own dev server or the site hung up, since each has its own fix.

What ERR_EMPTY_RESPONSE looks like in Chrome and curl

Chrome puts it under the heading it uses for HTTP 5xx errors and offers only a Reload button.

WhereWhat you see
Chrome error page, public siteThis page isn't working. www.example.com didn't send any data. ERR_EMPTY_RESPONSE
Chrome error page, local dev serverThis page isn't working. localhost didn't send any data. ERR_EMPTY_RESPONSE
Chrome DevTools, Network panel Status column(failed) net::ERR_EMPTY_RESPONSE
Chrome console, failed fetch() requestFailed to load resource: net::ERR_EMPTY_RESPONSE
Puppeteer page.goto()net::ERR_EMPTY_RESPONSE at http://localhost:3000
Playwright page.goto()page.goto: net::ERR_EMPTY_RESPONSE at http://localhost:3000/
curl, the same close seen from the command line (exit code 52)curl: (52) Empty reply from server

Why this happens

Your request went out on an open connection, and nothing came back.

Chrome got a clean close (TCP FIN), not a reply. Our local tests produced it with a crashed handler, a server time limit, a proxy that gave up and plain HTTP sent to an HTTPS port.

Diagnose your ERR_EMPTY_RESPONSE first

The first two need only a second device and Chrome's settings; the rest are for people who run the server.

  • Open the page on another device on your Wi-Fi with no proxy or VPN; if it fails there too, the silence comes from the site.

  • Turn off Chrome's proxy or proxy extension so it connects directly; if the page then loads, the drop happens on the proxy route.

  • Read the URL your dev server printed; if it says https:// while the address bar says http://, plain HTTP reached its TLS port.

  • Watch the server's terminal or error log while you reload; a fresh traceback or crash means the handler died before replying.

  • On nginx, find the failed visit in the access log; a 444 status there means your own config dropped it.

Solutions ranked by effectiveness

The first fix is for visitors, the second for dev servers, the third for site owners.

  1. Most common fix

    Rule out your proxy, then retry later

    Applies to public websites you don't run. Google's help says such a page sent nothing and might be down, leaving only your proxy and timing to change.

    1. Click Reload once; a server that was restarting or overloaded may answer now.

    2. If it works only with the proxy off, delete and re-enter the proxy entry.

    3. If only this site drops proxied traffic, go direct; refusing it is the owner's choice.

  2. For developers

    Open your HTTPS dev server with https://

    Applies when localhost or a dev port shows the error. Node.js HTTPS servers, Vite's server.https included, drop plain HTTP silently; nginx answers it with a 400 page.

    1. Retype the address with https:// at the start, keeping the same port number.

    2. To stay on http://, remove the HTTPS option from the dev server config and restart.

    3. If Chrome lands on http:// again, fix the link or redirect that sends it there.

  3. Site owners

    Send a status code instead of closing

    Applies when your own server closes on visitors. Chrome's page for this error tells them nothing about why, so answer with a status code.

    1. Where real visitors can trigger return 444, send 403 instead.

    2. When a request outlives your time limit, send an error status before closing.

    3. Put a one-line reason in the body; Chrome shows it instead of its error page.

Stop the ERR_EMPTY_RESPONSE from coming back

Habits for servers and monitors, so the next silent close leaves a trace.

  1. Add a tlsClientError listener to Node.js HTTPS servers; otherwise plain-HTTP visits fail with nothing logged.

  2. Run servers built on Python's http.server with standard error saved to a file; handler tracebacks go there.

  3. Make uptime checks fail on curl exit 52; the http_code value is just 000 then.

Check your proxy is activeYour Geonode dashboard shows whether the proxy is active and running before you dig deeper.
Try residential proxies

Related errors

Learn more

FAQ

It is Chromium's error -324: the server hung up with zero bytes in reply, so there is no HTTP status or page to display, only Chrome's own error screen.

ERR_EMPTY_RESPONSE is a clean close after an HTTP/1.1 request; the same close on an HTTP/2 connection, or during the TLS handshake, shows ERR_CONNECTION_CLOSED. ERR_CONNECTION_RESET follows an abrupt reset packet; those two say "This site can't be reached".

Chrome sends localhost requests straight to your machine, skipping any proxy by default, so your own server closed the connection. Look at that server process, not your network.

The proxy, or the site for visits that arrive through it, closed without replying, and Chrome names the site either way. In our tests, a proxy that hung up after a GET, or before answering CONNECT, gave this exact error.

Only if the name pointed at a wrong server. By the time this error appears, the name was resolved, a connection opened and the request went out; a failed lookup shows ERR_NAME_NOT_RESOLVED instead.

page.goto() had no response to return, so it rejects with Chrome's error text and your URL. A 500 or 503 reply resolves normally instead, so code that checks only the status also needs a catch for this error.

Test your site from home ISPs

A country and ASN in the proxy username route your test visits through that ISP.

Try residential proxies