ERR_EMPTY_RESPONSE (Didn't Send Any Data): Causes and Fixes

ERR_EMPTY_RESPONSE is a Chrome and Edge error that reads "This page isn't working. example.com didn't send any data." The browser connected, sent its HTTP request, and then the server closed the connection without writing a single byte of response, not even a status line. Firefox reports a similar situation as "The connection was reset" or "The connection was interrupted." Command-line tools show it as curl: (52) Empty reply from server.

The key fact is that the request reached something that accepted it. The failure happened after the request was received, so look at the web server, the application behind it, and any security layer, rather than DNS or routing.

Reproduce it from the command line

curl -v https://example.com/path -o /dev/null
# curl: (52) Empty reply from server

Try variations to localize the trigger: a different path, -X POST, a different User-Agent, and a request direct to the origin (--resolve example.com:443:ORIGIN_IP). If a static file works and a PHP page does not, the application layer is dropping it. If every request fails only from some IPs, a firewall is dropping them.

If you are a visitor

1. Reload and try another page. A single failing URL points to a server-side fault on that page.
2. Disable extensions or try incognito. Security extensions can modify requests so the server rejects them.
3. Clear cookies for the site. An oversized or corrupt cookie header can cause some servers to close the connection. Clear only that site's cookies.
4. Turn off VPN and antivirus web shields for a test.
5. Switch network. If another network works, your IP may be blocked by a firewall rule.
6. Check whether the site is down for others with website down for everyone or just me. If it is, there is nothing to fix on your side.

If you own the site

1. The backend process crashed

When PHP-FPM, Node, Gunicorn or another backend dies while handling a request, the web server may close the connection with no response. Look for crash evidence:

dmesg -T | grep -i -E "segfault|out of memory|killed process"
sudo tail -n 100 /var/log/php8.2-fpm.log
sudo journalctl -u gunicorn --since "30 min ago"

A segfault in a PHP extension, or the kernel's OOM killer ending the worker, are typical. Fix by updating or disabling the extension, adding memory or swap, or reducing pm.max_children so workers do not exhaust RAM. For memory limits inside PHP itself, see PHP allowed memory size exhausted.

2. nginx return 444

In nginx, status 444 is a special value that closes the connection without a response. It is commonly used in catch-all blocks to drop bad hosts:

server {
    listen 80 default_server;
    return 444;
}

If your real hostname lands in this block (because of a missing server_name, a typo or a new domain), visitors see ERR_EMPTY_RESPONSE. Search for it with grep -rn "444" /etc/nginx/ and confirm nginx -T | grep server_name lists the hostname.

3. A WAF or security module drops the request

ModSecurity, a cloud firewall or a hosting provider's protection may reset requests matching a rule. Check the audit or access logs for the same timestamp, whitelist the false positive, or relax the rule. Rate-limiting tools such as fail2ban and CSF also drop banned IPs silently.

4. Apache child process crashes

Apache logs lines such as child pid 1234 exit signal Segmentation fault in error.log when a worker dies. Update modules, and if a particular PHP extension is involved, disable it to test.

5. Request too large or too slow

Large POST bodies, long-running scripts and header sizes over limits can lead to dropped connections on some stacks. Check client_max_body_size, PHP's post_max_size and timeouts. For gateway timeouts that produce proper status codes instead, see fix 504 Gateway Timeout.

6. Protocol mismatch on the port

Sending plain HTTP to a TLS-only port, or the reverse, can result in an empty reply or a close. Confirm that your port 80 and 443 listeners use the intended protocol, and that a proxy is not speaking HTTP to an HTTPS backend. Compare with ERR_SSL_PROTOCOL_ERROR.

7. Database failures that kill the request

Some applications abort with no output when the database is down. Check connections with MySQL error 2002 and MySQL server has gone away, and consider enabling application error logging.

Confirm the fix

1. Re-run the curl -v test. You should see an HTTP status line rather than "Empty reply."
2. Use the HTTP Status Checker to confirm a normal response from outside your network.
3. Inspect what comes back with the HTTP Header Checker.
4. Add an uptime monitor with a keyword check, so a blank or dropped response triggers an alert even if the port is open.

Next steps

• Read ERR_CONNECTION_REFUSED vs timed out vs reset.
• Compare with ERR_CONNECTION_CLOSED.
• Learn about server-error patterns in fix 500 Internal Server Error and fix 502 Bad Gateway.
• Check ports and listeners with the Port Checker.

FAQ

What is the difference between ERR_EMPTY_RESPONSE and a 500 error?

A 500 error is an HTTP response that tells the browser something went wrong. An empty response is the absence of any HTTP response at all, usually because the process or connection died.

Why does it only happen on one page?

That page's code path probably crashes the backend, exceeds a limit or matches a firewall rule. Compare logs for that URL.

Can a plugin cause it on WordPress?

Yes. A plugin that triggers a PHP crash or runs out of memory can produce it. Disable plugins to test, as described in WordPress plugin conflict troubleshooting.

Is it a problem with my browser?

Rarely. If curl shows the same empty reply, the cause is on the server or the path to it.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.