ERR_EMPTY_RESPONSE: when the server sends no data

The server closed the connection without a reply. Crashed workers, rules that drop requests on purpose, and proxies that give up silently.

· 3 min read · By the Spot Downtime team

ERR_EMPTY_RESPONSE (“example.com didn't send any data”) means the browser connected and sent its request, and the server closed the connection without a single byte in reply. No status code, no headers, no error page. curl reports it as Empty reply from server.

Since a connection was made, DNS and the network are fine. Something on the server side started handling the request and then gave up on it.

Common causes

The process died while handling the request

Killed for memory, crashed in native code, or hit a hard execution limit. The connection closes with nothing sent. Check for out-of-memory kills and crash logs:

bash
dmesg -T | grep -iE "killed process|out of memory"
journalctl -u your-app --since "30 min ago" | grep -iE "error|fatal|signal"

A server rule that closes on purpose

nginx's return 444; closes a connection without responding, a common way to drop unwanted bots. A rule meant for bad traffic that matches real requests causes exactly this error.

A proxy timing out with no response

Some proxies and load balancers close the connection silently when the backend is too slow, instead of sending a 504.

Plain HTTP to an HTTPS-only port, or the reverse

Mismatched protocols on a port (for example, an app listening for HTTPS where the proxy sends HTTP) can produce a closed connection with nothing usable in it.

For visitors

  • Reload once; a one-off crash may already be over.
  • Try a private window and turn off VPN or proxy settings.
  • If it happens on every site, reset your network settings or check antivirus web filtering.
Is it down for everyone?Check whether the site returns a response from outside your network.HTTP headers checkerSee whether a URL returns any status code and headers at all.

Only some pages?

If the home page works and one heavy page gives an empty response, that page is crashing the worker: a huge query, an image too large to process, or an infinite loop. Its logs will usually show the process ending at the same timestamp.

Why monitoring helps: empty responses don't produce an error code that shows up in most analytics. An outside monitor records them as failed checks with the exact error, so you see them even when no visitor reports them. Related: ERR_CONNECTION_RESET and Cloudflare error 520, which is how this looks behind Cloudflare.

Keep reading