Skip to content

ERR_EMPTY_RESPONSE: The Server Sent Nothing

Key idea:

ERR_EMPTY_RESPONSE means the server accepted the TCP connection but closed it without sending an HTTP response. Typical for PHP-FPM/Apache crashes, nginx timeouts toward the upstream, or OOM kills. Causes: backend died, worker_connections exhausted, DB query hung. Fix: check backend logs, nginx error_log, systemctl status, raise PHP memory_limit.

This error blocks HTTPS access. Below: causes, fixes, working config, FAQ.

Check your site's SSL →

Common Causes

  • PHP-FPM/Apache worker crash or segfault
  • nginx upstream timeout — backend did not answer in time
  • OOM killer killed the PHP/worker
  • DB connection pool exhausted — request waits and server drops connection
  • Backend infinitely returns 499 (client closed) in a redirect loop
  • Cloudflare Error 520 (server returns empty reply)

Step-by-Step Fix

  1. Check tail -f /var/log/nginx/error.log — look for "upstream prematurely closed" or "recv() failed"
  2. PHP-FPM logs: tail -f /var/log/php8.x-fpm.log — look for "child exited on signal" or OOM
  3. Raise memory_limit: php_admin_value[memory_limit] = 512M
  4. Check status: systemctl status php-fpm nginx — all running?
  5. Monitor uptime via Enterno Monitor — instant flap alerts
  6. On Cloudflare — test origin: curl -H "Host: example.com" https://IP/

Check SSL Certificate →

Example: Proper nginx TLS config

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    ssl_stapling        on;
    ssl_stapling_verify on;
}

Related SSL Errors

TL;DR

The ERR_EMPTY_RESPONSE error indicates that the server did not send any data in response to a request. This can result from server misconfigurations, network issues, or firewall settings. To resolve it, check server logs for errors, ensure the server is running, and verify network configurations. Use commands such as ping and traceroute to diagnose connectivity issues.

Understanding ERR_EMPTY_RESPONSE: Causes and Implications

The ERR_EMPTY_RESPONSE error is a common issue encountered by web developers and system administrators. It signifies that the server failed to send a response back to the client, which can lead to a frustrating user experience. Understanding the underlying causes is essential for effective troubleshooting and remediation.

Several factors can contribute to the ERR_EMPTY_RESPONSE error. Here are some of the most prevalent:

  • Server Misconfiguration: Incorrect server settings can prevent proper response transmission. This includes issues in the server's configuration files, such as nginx.conf or httpd.conf.
  • Network Connectivity Issues: Problems in the network path between the client and server can lead to dropped packets or timeouts. This may involve faulty routers or ISP-related issues.
  • Firewall Restrictions: Firewalls may block certain requests or responses based on predefined rules, causing the server to appear unresponsive.
  • Server Overload: High traffic loads can exhaust server resources, resulting in an inability to process incoming requests.
  • Application Errors: Bugs or unhandled exceptions in web applications can lead to empty responses, especially when error handling is not properly implemented.

To illustrate, let’s consider a scenario where a web server is returning an ERR_EMPTY_RESPONSE error. Assume you are using an NGINX server. You might start by checking the NGINX error logs located at /var/log/nginx/error.log. You can use the following command:

sudo tail -f /var/log/nginx/error.log

This command will display the last few lines of the error log in real-time, allowing you to monitor any new entries as they occur. Look for entries that indicate misconfigurations or application issues.

Another useful command for diagnosing network issues is curl. By running the following command:

curl -I http://yourdomain.com

You can check if the server is reachable and see if it sends any HTTP headers. If the response is empty, it confirms that the server is not responding as expected.

To further diagnose connectivity, you can use ping and traceroute commands:

  • ping yourdomain.com - This tests if the server is reachable and measures the round-trip time for messages sent to the server.
  • traceroute yourdomain.com - This shows the route packets take to reach the server, helping identify where the connection might be failing.

After identifying the root cause, remediation steps can vary. For instance, if server configuration is at fault, you might need to edit your NGINX configuration file:

sudo nano /etc/nginx/nginx.conf

Ensure that your server blocks and location directives are correctly defined. After making changes, remember to test the configuration:

sudo nginx -t

If the test passes, reload the NGINX service:

sudo systemctl reload nginx

By following a systematic approach to diagnose and resolve the ERR_EMPTY_RESPONSE error, you can significantly improve the reliability of your web infrastructure and enhance user experience.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Sources

Frequently Asked Questions

How is it different from ERR_CONNECTION_REFUSED?

Refused — TCP connect failed (no listener). Empty — connection established but reply is empty. The cause is deeper: the worker died after accept().

Only happens on POST requests — why?

Large POST bodies exceed nginx <code>client_max_body_size</code> or PHP <code>post_max_size</code>. PHP-FPM rejects, nginx drops the connection → empty response.

How can I catch the exact moment of failure?

Enable nginx <code>access_log</code> with <code>$upstream_response_time</code> and <code>$upstream_status</code>. An empty upstream_status with a timestamp is the moment.

Does restarting help?

Temporarily, yes. The problem returns. Find the root cause in the logs.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.