ERR_EMPTY_RESPONSE means the server accepted the connection and then closed it without sending anything back, not a status code, not a header, not one byte. Chrome's phrasing is exact: the site didn't send any data. The conversation started normally and ended in a hang-up.
This makes it a strange error to place. It is not a DNS problem, because the address resolved. It is not a refusal or a timeout, because the connection opened. And it is not an HTTP error like a 500 or 503, because HTTP never happened; those codes are things a server says, and this server said nothing. What produces silence after a successful hello is almost always a process dying or being killed in the instant it should have been writing the response, with a shorter list of local causes on the visitor's machine that intercept or strip the reply. This article covers both, and closes with the monitoring angle, because an empty response is precisely the kind of failure a simple up-or-down check catches on the first attempt.
What kills a response mid-birth
For a response to come back empty, something has to fail in the narrow window between accepting the connection and writing the first bytes. The classic causes cluster there. The application process crashes while generating the page, a segmentation fault in a PHP worker, an unhandled fatal in the app code, and the dying process takes the open connection with it. The operating system kills the process for exceeding memory, the out-of-memory kill that container platforms report as exit code 137 and memory-hungry runtimes reach the same cliff through their own doors, as Odown's guide to the Java heap space error shows. A worker pool is exhausted and a proxy in front closes connections it cannot hand off. Or the request reaches a port where the wrong protocol lives, and the listener drops the conversation it cannot parse.
The unifying theme is that the server-side cause is nearly always visible in a log, because processes rarely die without the error log, the kernel log, or the service manager recording the death. Empty responses are silent to the visitor and loud in the logs, which is what makes the owner-side diagnosis short.
Visitor-side fixes, quickly
The local causes are interception rather than crashes: something on your machine sits between the browser and the network and mangles the reply. Test in an incognito window with extensions disabled, because a broken extension, ad blockers and privacy tools especially, can swallow responses whole; if incognito works, re-enable extensions one at a time to find the offender. Pause any antivirus feature that scans HTTPS traffic, since these tools decrypt and re-encrypt responses and occasionally drop one on the floor. Clear the browser cache, flush DNS with ipconfig /flushdns or your platform's equivalent, and reset the network stack if the error is spreading across sites. And as always, the phone-on-mobile-data test settles jurisdiction in ten seconds: if the site sends nothing no matter where you connect from, the server side owns the problem.
Owner-side fixes: follow the dying process
Read the error logs first. The web server's error log and the application's log, at the timestamp of the failure, usually contain the entire story: a segfault line, a fatal exception, a worker exiting on signal. This is a two-minute step that regularly saves the following hour.
Check for memory kills. Run dmesg and look for out-of-memory killer entries, and check the service manager's record of the process. A server that intermittently returns nothing under load, then recovers, is the classic OOM rhythm: workers get killed at traffic peaks and respawn in the quiet.
Verify the worker pool is alive and sized. With PHP-FPM and similar pools, a crashed pool answers nothing while the web server in front stays up. Restart the pool, then examine why it died, a leaking script, a max-children ceiling set for a smaller site than you now run.
Confirm the port speaks the protocol you think. An HTTPS request delivered to a plain-HTTP listener, or traffic aimed at an application port instead of the web server, produces garbage or nothing. Check the proxy's upstream definition and the listener list with ss -tlnp against your intended layout.
Bisect recent changes. If the error began after a deploy, a new module, or a configuration change, roll it back before debugging forward. A misbehaving server module or a fresh dependency that crashes on certain inputs will produce empty responses only on the pages that trigger it, which is why the error can seem random while being perfectly deterministic.
Common mistakes in fixing ERR_EMPTY_RESPONSE
Treating it as a timeout. Nothing timed out; the connection opened and died. The suspect list is crashing processes and interception, not slow networks, and the fix lives in logs, not patience.
Restarting the service without reading why it died. The restart works until the same request kills the same worker again. One minute in the error log converts a recurring mystery into a one-time fix.
Ignoring the pattern of which pages fail. If only certain URLs return nothing, the crash is input-dependent, a specific query, upload, or code path. The failing URLs are the reproduction case; treasure them.
Chasing it on a machine full of security extensions. Test clean before testing hard. An incognito window with extensions off eliminates half the local suspects in one move.
Assuming the site is fine because it loads for you. Crashes triggered by load or by specific inputs spare the owner constantly. External checks, and attention to user reports naming exact pages, see what your own browsing never will.
FAQ
What causes ERR_EMPTY_RESPONSE most often?
On the server, a process that dies while generating the response: an application crash, an out-of-memory kill, or an exhausted worker pool. On the visitor's machine, an extension or antivirus intercepting the reply. The mobile-data test tells you which side to search.
Why do I get it on localhost during development?
Your dev process accepted the connection and crashed before responding, or you connected to a port where a non-HTTP process lives. The terminal running the server almost always shows the crash at the exact moment of the error.
Is ERR_EMPTY_RESPONSE the same as a 500 error?
No. A 500 is a delivered HTTP response with a server-error status; this error means no HTTP response was delivered at all. A 500 says the server failed and told you; an empty response says it failed before it could speak.
Why does the error come and go?
Intermittent empties usually track load or specific inputs: workers killed at memory peaks, or a crash triggered only by particular requests. Logs at the failure timestamps, matched against traffic, reveal the rhythm.
Closing thought
An empty response is a death in a narrow window, after hello and before the first byte, so the investigation is mercifully contained: logs at the timestamp, memory kills, worker pools, protocol-port mismatches, recent changes. Visitors clear their side with an extension audit and a clean browser test; owners follow the dying process, which almost always left a note.
The operational catch is that this failure is invisible to any check that only asks whether the server is on. Odown performs full HTTP checks from 17 locations, so a site that opens connections and sends nothing fails the check exactly as a user experiences it, and the alert reaches you while the fix is a worker restart, not a morning of missed signups. For the broader taxonomy of what can go wrong at this layer, Odown's overview of the most common web errors is the companion read.
