ERR_EMPTY_RESPONSE

The short version: The server received your request but sent back nothing, then dropped the connection. Reload first, and if it persists check the website's application logs, worker timeouts, and any proxy or load balancer sitting in front of it.

Key takeaways

• ERR_EMPTY_RESPONSE is Chromium net error -324: the connection opened and closed with zero bytes, no status line, no headers, no body. It is the absence of a reply, which is what makes it different from a 5xx.
• The most common root cause is a backend killed mid-request: a PHP fatal error, an out-of-memory kill, or a worker timeout firing before any output is flushed.
• To tell whose fault it is, run curl -v https://yourdomain.com: 'Empty reply from server' (curl: (52)) confirms the server is sending nothing, while a clean reply points the problem back at your browser, VPN, or antivirus.
• For visitors a reload often succeeds because the failure is frequently transient; clearing extensions and disabling HTTPS-scanning antivirus rules out the local causes.
• Because no status code is ever sent, HTTP error dashboards stay blank, so the prevention angle is an external check with a keyword assertion that treats a zero-byte reply as a failure.

Error type

Browser connection error (zero-length response)

Whose side

Either

Fix difficulty

Moderate

Common cause

Backend process crashed, timed out, or was killed before it could send a response

What does ERR_EMPTY_RESPONSE mean?

ERR_EMPTY_RESPONSE is Chrome's way of saying the TCP connection opened and then closed again with no HTTP response inside it. The browser sent its request, the server (or something between you and it) acknowledged the socket, but the reply contained zero bytes: no status line, no headers, no HTML. Because there is nothing to render or interpret, Chrome falls back to its generic 'This page isn't working' screen and the net error code.

The key insight is that an empty response is fundamentally different from a 500, 502, or 503. A 5xx is a complete, well-formed HTTP reply that says 'I failed' in a way the browser, your logs, and your monitoring can all read. An empty response says nothing at all. That distinction matters when you debug: a backend that returns 500 finished the request handler and reached the error path, while an empty response usually means the worker process was terminated mid-request, before it could flush even a single header.

The most common backstory is a backend killed under load. A PHP fatal error or a PHP-FPM request_terminate_timeout fires, the worker is reaped, and the upstream connection is reset before any output. Sometimes a proxy or load balancer that cannot reach a healthy backend will close the socket instead of synthesizing a 502. A stray warning printed to stdout can even corrupt the FastCGI framing so the front-end gives up and returns nothing. In every case the symptom is the same empty reply, but the fix lives at a different layer.

0 bytes

Data the server actually returned before the connection closed

(52)

curl exit code for an empty reply from the server

5xx-free

No status code is sent, so logs and monitors see no HTTP error to parse

How the ERR_EMPTY_RESPONSE error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This page isn't working

example.com didn't send any data.

ERR_EMPTY_RESPONSE

• ERR_EMPTY_RESPONSE Chrome / Edge net error code for a zero-byte reply
• This page isn't working Chrome page heading shown above the code
• example.com didn't send any data Chrome sub-line naming the host
• No data received older Chrome wording for the same condition
• curl: (52) Empty reply from server the command-line equivalent from curl

ERR_EMPTY_RESPONSE vs similar errors

Empty responses are easy to confuse with gateway and reset errors. Here is how they differ in what the server actually sends back.

Timeout and worker settings that cause empty replies

An empty response usually means one of these limits fired before the request finished; align them so a slow-but-valid request can complete.

curl exit codes near an empty response

curl -v distinguishes a true empty reply from neighbouring failures that look similar in the browser.

What causes ERR_EMPTY_RESPONSE?

• The application process crashed mid-request (PHP fatal error, segfault, or out-of-memory kill) before sending any output
• A worker or execution timeout (PHP-FPM request_terminate_timeout, max_execution_time, or a fastcgi/proxy read timeout) terminated the request
• The server is overloaded and ran out of available workers, so connections are accepted and then dropped
• A reverse proxy, load balancer, or CDN closed the connection because it could not get a clean response from the origin
• A firewall, IDS, or network device silently dropped the response packets after the TCP handshake
• Client-side interference: a browser extension, VPN, or HTTPS-scanning antivirus stripped or blocked the response

How to find the cause fast

1. Reload once and try a different browser or an incognito window with extensions off, to separate a client-side cause from a server-side one
2. Run curl -v https://example.com and watch for 'Empty reply from server' (curl: (52)); seeing it confirms the server, not your browser, is sending nothing
3. Test from a second network or a remote host (for example curl from a VPS) to rule out a local firewall, VPN, or ISP device dropping the reply
4. Tail the application and PHP-FPM logs while you reproduce; look for fatal errors, 'request_terminate_timeout', or worker 'killed' lines that line up with the failed request
5. Check the proxy or load balancer error log for upstream resets such as 'recv() failed (104: Connection reset by peer) while reading response header from upstream'

Terminal

curl -v https://example.com/curl: (52) Empty reply from server# the server accepted the connection but returned zero bytes, no status, no headers

How ERR_EMPTY_RESPONSE looks from the outside

From the outside, an empty response is one of the hardest failures to catch by eye, because there is no status code to alert on: the server simply accepts the connection and sends nothing. An external HTTP check from Pulsetic treats that zero-byte reply as a failed request the same way curl reports exit code 52, so a check that expects a 200 and a matching keyword flags the outage even though no 5xx was ever returned. Pulsetic probes from 15+ locations on intervals as fast as 30 seconds, which also helps tell a one-off blip apart from a sustained failure. What an outside monitor cannot see is the cause inside the box (the crashed worker, the exhausted pool, or the timeout), so pair the alert with your own application and PHP-FPM logs to pin down which layer dropped the response.

How to fix ERR_EMPTY_RESPONSE

For visitors

1. Reload the page; an empty response is often transient and a retry succeeds.
2. Open the website in an incognito window, which disables most extensions, to rule out an extension stripping the response.
3. Clear cached images, files, and cookies for the website (Ctrl+Shift+Delete, range 'All time'), then reopen the page.
4. Temporarily turn off any VPN, proxy, or HTTPS-scanning feature in your antivirus and try again.
5. Restart your router and flush the DNS cache so a stale or wrong route is not sending you to a dead endpoint.

For website owners

1. Reproduce with curl -v and read your application logs to find the fatal error or timeout that killed the request.
2. Raise the worker and execution limits that are firing too early (PHP-FPM request_terminate_timeout, PHP max_execution_time, and the proxy fastcgi/read timeout) so slow-but-valid requests can finish.
3. Increase PHP-FPM pm.max_children or scale out if the pool is exhausted under load and connections are being dropped.
4. Set display_errors off in production so stray warnings cannot corrupt FastCGI framing and produce empty replies.
5. Verify the reverse proxy or load balancer points at a healthy backend and is configured to return a real error rather than closing the socket.
6. After fixing, watch it from outside with an uptime monitor so the next empty response pages you instead of a customer.

Browser

1. Hard refresh with Ctrl+Shift+R (Cmd+Shift+R on macOS).
2. Test in an incognito window to disable extensions.
3. Clear cache and cookies for the website, then retry.
4. Disable VPN or proxy software and try again.

Server (PHP-FPM / Nginx)

1. Tail the PHP-FPM and Nginx error logs while reproducing the request.
2. Raise request_terminate_timeout and the matching fastcgi_read_timeout.
3. Confirm display_errors is off so no output corrupts the FastCGI stream.
4. Restart PHP-FPM and Nginx after config changes and re-test with curl.

Still not fixed? Next steps

• Reproduce while tailing both logs at once: tail -f /var/log/php*-fpm.log and the Nginx error log. A 'child exited on signal' or 'request_terminate_timeout' line that lines up with the failed request names the killed worker.
• If the FPM log shows out-of-memory kills, raise memory_limit and the pool's pm.max_children, or profile the request to cut peak memory, since a single heavy endpoint can starve the whole pool.
• If the proxy log shows 'upstream prematurely closed connection while reading response header', the backend is dying before the proxy can read a status, so the fix is at the application or FPM layer, not the proxy.
• Set display_errors = Off and log_errors = On in production: a stray warning printed to stdout can corrupt the FastCGI framing and produce empty replies even when the script otherwise succeeds.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Confirm the empty reply with curl

curl -v https://example.com/
# *   Trying 203.0.113.10:443...
# * Connected to example.com (203.0.113.10) port 443
# > GET / HTTP/2
# > Host: example.com
# * Empty reply from server
# curl: (52) Empty reply from server

Stop PHP-FPM from killing requests too early

; /etc/php/8.x/fpm/pool.d/www.conf
request_terminate_timeout = 120s
pm.max_children = 25

; php.ini (production)
max_execution_time = 120
display_errors = Off

Match the proxy read timeout (Nginx)

location ~ \.php$ {
    fastcgi_pass   unix:/run/php/php-fpm.sock;
    fastcgi_read_timeout 120s;
    include        fastcgi_params;
}

How to prevent ERR_EMPTY_RESPONSE

Most empty responses trace back to a backend that quietly ran out of headroom: a worker pool too small for peak traffic, a timeout set shorter than a legitimate request, or an unhandled fatal error. Give your workers realistic timeouts and limits, keep display_errors off in production, and load-test before traffic spikes so the failure shows up in staging rather than in front of customers. Because an empty reply carries no status code, you will not see it in HTTP error dashboards, so run a Pulsetic HTTP check with a keyword assertion and multi-location alerting (email, SMS, voice, Slack, Discord, Telegram, or webhook) to catch the silent ones the moment they start.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.