How is ERR_EMPTY_RESPONSE different from ERR_CONNECTION_REFUSED?

ERR_CONNECTION_REFUSED means the TCP connection never opened — nothing is listening. ERR_EMPTY_RESPONSE (Chromium net error -324) means the opposite: the connection opened fine, the server accepted it, and then closed it without sending a single byte of HTTP response — not even headers. One is a closed door; the other is a door that opens and then slams in your face.

Why do I get it on a site that works in another browser?

Then it's probably not the origin. A browser extension, a local proxy or VPN, or an antivirus that inspects traffic can strip the response before Chrome sees it. Test in an incognito window with extensions off, or run curl -v against the URL — if curl gets a response and Chrome doesn't, the problem is on the client side.

Can pointing HTTP at an HTTPS port cause this?

Yes, and it's a classic. If you request http:// against a port that only speaks TLS, the server often reads your plaintext as garbage and closes the connection without a real HTTP error. Node.js, for one, produces ERR_EMPTY_RESPONSE here instead of a clean 400. Switch the scheme to https:// and the 'empty' response usually appears.

Views: 7

ERR_EMPTY_RESPONSE Fix

ERR_EMPTY_RESPONSE means the server closed the connection with no reply. Tell a crash from an HTTPS-port mix-up in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The browser shows ERR_EMPTY_RESPONSE — Chromium net error code -324. The page never loads.

Symptoms

A blank error page in Chrome/Edge reading “ERR_EMPTY_RESPONSE” or “didn’t send any data.”
The site sometimes loads on retry, or loads for other people but not you.
It happens on one site while everything else works.

What ERR_EMPTY_RESPONSE Actually Means

This is one of the more honest error messages a browser produces, because it describes exactly what happened: the TCP connection opened, the server accepted it, and then the server closed it without sending any HTTP response at all — no status line, no headers, nothing. Chrome had a complete conversation channel and the other side hung up before saying a word.

That detail is the whole diagnosis. It rules out a class of problems immediately. The network path works (the handshake completed). DNS resolved (you reached an IP). A port is listening (the connection was accepted, not refused). What broke is everything after the connection: the server process that was supposed to write a response either died, never started writing, or had its output thrown away by something in the middle.

Top 3 Causes

The server process crashed or was killed mid-request - A worker segfaults, the OOM killer reaps it, an unhandled exception takes the process down — and it dies after accepting the socket but before writing a response. The connection closes empty. This is the most common origin-side cause, and it’s usually intermittent, which is why “it works on retry” is such a familiar symptom.
You’re speaking plain HTTP to a TLS-only port - Request http://host:443 (or any HTTPS-only port) and the server tries to parse your plaintext GET as a TLS ClientHello, fails, and closes the connection without a real HTTP error. The fix is to use https://. This trips up local dev setups and misconfigured redirects constantly.
Something in the middle is eating the response - A reverse proxy with a broken upstream, a corporate firewall or antivirus that inspects and drops traffic, a browser extension, or a VPN can swallow the response before it reaches the browser. If the site works elsewhere but not for you, suspect the client side first.

Diagnose with DechoNet

HTTP Check from outside your network — if it gets a normal status code and headers while your browser gets ERR_EMPTY_RESPONSE, the origin is fine and the problem is local to your machine or network.
Port Check to confirm the port is actually open and accepting connections — ERR_EMPTY_RESPONSE means it is, but verifying separates a true “accepted then closed” from a flapping service that only sometimes listens.

Resolution Checklist

Confirm the scheme: if you typed or were redirected to http:// on a TLS port, switch to https://.
Reproduce in an incognito window with all extensions disabled — if it goes away, an extension was eating the response.
Run curl -v https://yoursite.com from a clean network. No HTTP response means the origin is the problem; a normal response means the client side is.
On the origin, check process logs for crashes, OOM kills, or restarts timed to the failed requests — an empty response almost always has a dead worker behind it.
If a reverse proxy fronts the app, check that its upstream is healthy and not closing connections without forwarding a response.
Re-run HTTP Check and confirm the server now returns a real status code.

When to Escalate

Escalate to whoever runs the origin if external HTTP Check also gets no response — the server is dropping connections and the fix is on their side, not the browser’s.
If the failure is intermittent under load, treat it as a stability problem: investigate worker crashes, memory limits, and request timeouts rather than chasing browser settings.