ERR_EMPTY_RESPONSE means Chrome connected to the server, the TCP and TLS handshakes completed, and then the server sent back zero bytes of HTTP response. The connection was open. Data simply never arrived. Chrome waited, the server said nothing, and Chrome reported the void as ‘No data received.’
This is different from a connection refused error (server not running), a DNS error (domain not resolving), or an SSL certificate error (TLS handshake failed). ERR_EMPTY_RESPONSE is specifically: connection established, response absent.
The cause can be on your device, on the network between you and the server, or on the server itself. Identifying which before trying fixes saves significant time. One diagnostic question determines the path.
First: Which Pattern Matches Your Situation?
| Pattern | What it means | Go to |
| Error on one specific site; other sites load normally | The site’s server is the likely problem. Your browser and network are working. | Server-side section (you’re a visitor) or Site owner section |
| Error on many sites or all HTTPS sites simultaneously | Browser or device-level problem. The server is fine. | Visitor fixes: browser cache, extensions, network reset |
| Error started after a Chrome update or Windows update | Browser or system change caused the issue. | Visitor fixes: clear SSL state, reset flags, check date/time |
| Error on your own site; visitors are reporting it | Server configuration problem. | Site owner section below |
| Error only when connecting via certain network (VPN, corporate, mobile) | Network-level interception or proxy causing the issue. | Visitor: network and proxy fixes |
Section A: Visitor Fixes (Error on Sites You Don’t Own)
These fixes address causes on your device or network. Work through them in order; the earlier ones are faster and resolve most cases.
Fix 1: Reload and try incognito
Start with the simplest options before changing any settings. Press F5 or Ctrl+R to reload. If that fails, open an incognito window (Ctrl+Shift+N) and try the same URL. Incognito disables extensions and uses a fresh session without cached data. If the site loads in incognito and fails in your normal window, an extension or cached data is the cause.
Fix 2: Check if the site is down for everyone
Before spending time on browser fixes, confirm the site is actually reachable. Use downforeveryoneorjustme.com or isitdownrightnow.com to check the site’s status from external servers. If the site is down globally, no browser fix on your end will help. Wait and retry.
Fix 3: Clear Chrome’s cache and cookies for the affected site
Corrupted cached data for a specific site is a common cause. Rather than clearing all browsing data, clear only the affected site: navigate to the URL, click the padlock icon in the address bar, select Site settings, then click Clear data. This removes cached data for that site only without affecting your history or data from other sites.
Alternatively, open Chrome Settings (three-dot menu), Privacy and security, Delete browsing data. Select Cached images and files and Cookies and other site data. If the error affects only one site, check Advanced and use the time range that covers when the issue started.
Fix 4: Disable extensions
Extensions that intercept web traffic, such as ad blockers, VPNs, or privacy tools, can interfere with responses from specific sites. Navigate to chrome://extensions and toggle off all extensions. Reload the failing page. If it loads, re-enable extensions one at a time to identify the conflicting one.
Fix 5: Flush DNS and clear Chrome’s socket pool
Stale DNS cache entries or open socket connections can route traffic incorrectly. Open chrome://net-internals/#dns in Chrome and click Clear host cache. Then navigate to chrome://net-internals/#sockets and click Flush socket pools. These two steps clear Chrome’s internal network state.
At the operating system level, flush the DNS cache: on Windows, open a Command Prompt as administrator and run ipconfig /flushdns. On macOS, run sudo dscacheutil -flushcache in Terminal followed by sudo killall -HUP mDNSResponder.
Fix 6: Reset Chrome network settings via flags
Chrome’s experimental network settings can accumulate stale state. Navigate to chrome://flags and search for ‘Reset to default’ to restore all flags to their defaults. Alternatively, use Chrome’s built-in reset: Settings, Advanced, Reset settings, Restore settings to their original defaults. This resets startup page, new tab page, search engine, pinned tabs, and content settings, but does not delete bookmarks, history, or passwords.
Fix 7: Check your system date and time
An incorrect system clock causes certificate validation failures that can prevent HTTPS connections from completing. If the clock is wrong by more than a few minutes, TLS handshakes fail. On Windows, right-click the taskbar clock, select Adjust date/time, and enable Set time automatically. On macOS, go to System Settings, General, Date and Time.
Fix 8: Disable antivirus HTTPS scanning
Antivirus products that perform HTTPS inspection (Kaspersky, Avast, Bitdefender, ESET, Norton with Network Protection) insert themselves between Chrome and the server. When the inspection fails or produces an empty response, ERR_EMPTY_RESPONSE results. Temporarily disable the antivirus product’s web protection or HTTPS scanning feature and retry. If the error clears, the antivirus interception is the cause. Configure its URL exclusions for the affected site or update the antivirus product to a version compatible with the current Chrome version.
Fix 9: Reset TCP/IP and Winsock (Windows)
Corrupted Windows network stack configuration can cause all TCP connections to behave incorrectly. Open an administrator Command Prompt and run these commands in sequence, restarting after all four:
| # Reset Windows TCP/IP stack and network components:
# Run each line separately in an Administrator Command Prompt
netsh winsock reset netsh int ip reset ipconfig /release ipconfig /renew
# Restart the computer after running all four commands. # This resets the Windows network stack to defaults. # Saves Wi-Fi passwords and other network profile settings. |
Section B: Site Owner Fixes (Visitors Report ERR_EMPTY_RESPONSE on Your Site)
When ERR_EMPTY_RESPONSE appears for visitors to a site you operate, the server accepted the connection but sent no HTTP response. Chrome never received an HTTP status line. This is different from a 500 error: a 500 error has a response with a status code. ERR_EMPTY_RESPONSE has no response at all.
The server-side causes are specific and diagnosable. Work through the following in order.
Diagnose: what does curl tell you?
Use curl with verbose output from an external server to see exactly what the origin server returns. If you are behind a CDN or proxy, test the origin server directly to separate CDN-level failures from origin-level failures:
| # Test the public URL:
$ curl -v https://yourdomain.com/path
# Test the origin server directly (bypass CDN): # Replace ORIGIN_IP with your actual server IP $ curl -v –resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com/path
# If the public URL returns ERR_EMPTY_RESPONSE but origin is fine: # the problem is in the CDN/proxy layer (Cloudflare, load balancer, etc.)
# Test with explicit timeout: $ curl -v –max-time 30 https://yourdomain.com/path
# Check the server’s response headers only (faster for diagnosis): $ curl -I https://yourdomain.com/path
# If curl shows: ‘* Empty reply from server’ : the server sent zero bytes # If curl shows: ‘Connection reset by peer’ : the server closed the connection # If curl shows: ‘* Operation timed out’ : gateway or upstream timeout |
Cause 1: Application crash before sending response headers
The most common server-side cause. The web application (Node.js, PHP, Python, Ruby) begins processing a request and crashes or exits before sending any HTTP headers. The server closes the connection. Chrome receives an empty response.
Check application logs immediately after reproducing the error. Node.js will show unhandled exceptions or process exits. PHP will log fatal errors in the PHP error log. Look for errors timestamped at the moment of the request. Common causes: unhandled promise rejection in Node.js, PHP fatal error (memory limit, execution time limit), Python uncaught exception, or a handler that returns without sending a response.
In Express.js: missing res.send(), res.json(), or res.end() in a handler is a common mistake. The handler runs, does not send a response, and the connection hangs until timeout, then closes empty. In PHP: a fatal error after output buffering starts can produce an empty response if the error handler is also broken.
Cause 2: Reverse proxy or gateway timeout
When Nginx, Apache, HAProxy, or a cloud load balancer (AWS ALB, Azure Application Gateway) proxies requests to an upstream application server, the proxy has a timeout for how long it waits for the upstream to respond. If the upstream is slow or unresponsive and exceeds this timeout, the proxy closes the connection to the client and returns ERR_EMPTY_RESPONSE rather than a 504 status code in some configurations.
Symptoms: the error appears consistently on slow endpoints, or during peak load when upstream workers are overloaded. Nginx’s proxy_read_timeout defaults to 60 seconds; if the application takes longer, Nginx closes the connection. For Nginx, increase proxy_read_timeout in the location block for slow endpoints. For Cloudflare, the proxy timeout is 100 seconds for the Business plan and higher; Free plan users have no configurable timeout.
| # Nginx: increase upstream read timeout for specific locations
location /slow-endpoint { proxy_pass http://upstream; proxy_read_timeout 120s; # default is 60s proxy_connect_timeout 10s; proxy_send_timeout 120s; }
# Check current timeout errors in Nginx error log: $ grep ‘upstream timed out’ /var/log/nginx/error.log | tail -20 # If you see: ‘upstream timed out (110: Connection timed out)’ # the application is taking longer than proxy_read_timeout |
Cause 3: TLS/SSL origin certificate issues
When a CDN or load balancer (particularly Cloudflare) uses Full or Full (Strict) SSL mode, it establishes a separate TLS connection from its edge to your origin server. If the origin server’s certificate has expired, is misconfigured, or the TLS handshake stalls, the CDN cannot complete the origin connection. The CDN then returns an error to the visitor; in some scenarios this manifests as ERR_EMPTY_RESPONSE rather than Cloudflare’s own error page.
This is the SSL connection to this article’s topic. Check the origin server’s certificate independently using openssl s_client:
| # Check the origin server certificate directly:
$ openssl s_client -connect YOUR_ORIGIN_IP:443 -servername yourdomain.com
# Look for: # ‘Verify return code: 0 (ok)’ : certificate is valid and trusted # ‘Certificate expired’ : origin cert needs renewal # ‘unable to get local issuer certificate’ : missing intermediate cert
# If origin cert has expired, renew it and restart the web server. # Cloudflare will then be able to complete the TLS handshake to origin.
# For Cloudflare origin certificates specifically: # The origin cert issued by Cloudflare (under SSL/TLS, Origin Server) # is only trusted by Cloudflare’s edge, not public browsers. # Direct connections to origin IP will show an untrusted cert warning. # This is expected behavior for Cloudflare origin certs. |
Cause 4: Keep-alive misconfiguration
HTTP keep-alive allows multiple requests to reuse the same TCP connection. When keep-alive timeout values are mismatched between the load balancer and the upstream server, the server closes an idle connection at the same moment the load balancer sends a new request on it. The result: the connection exists but immediately closes, producing ERR_EMPTY_RESPONSE.
The classic scenario: Nginx upstream keepalive timeout is shorter than the load balancer’s keepalive timeout. The load balancer assumes the connection is still open, sends a request, and Nginx closes it. Fix by setting the upstream server’s keepalive timeout slightly longer than the load balancer’s, or by disabling keepalive between load balancer and upstream.
Cause 5: Backend workers crashed or are at capacity
If all PHP-FPM workers, Node.js cluster processes, Gunicorn workers, or Unicorn workers are busy or have crashed, incoming requests have nowhere to go. The web server accepts the connection (TCP handshake completes) but cannot route to any available worker. In some configurations this produces a timeout and empty response rather than a 502 or 503 error.
Check worker process status: for PHP-FPM, check the FPM status page or run ps aux | grep php-fpm. For Node.js, check PM2 or systemd service status. Restart dead workers and investigate why they died (OOM kill, unhandled exception, CPU exhaustion).
Frequently Asked Questions
What is ERR_EMPTY_RESPONSE in Chrome?
ERR_EMPTY_RESPONSE is a Chrome error code indicating that the server accepted the connection but returned zero bytes of HTTP response. The error displays as ‘No data received’ in Chrome. It is distinct from connection refused (server not listening), DNS errors (domain not resolving), and SSL certificate errors (TLS handshake failed). ERR_EMPTY_RESPONSE specifically means the connection was established and then the server sent nothing before closing it.
Is ERR_EMPTY_RESPONSE caused by my browser or the website?
Either. If the error appears on one specific site while other sites load normally, the cause is almost certainly on the server side: the site’s application crashed before responding, a proxy timeout occurred, or an origin certificate problem prevented the CDN from completing the connection to the origin. If the error appears on many sites or all HTTPS sites simultaneously, the cause is on your device: corrupted cache, browser extension interference, antivirus HTTPS scanning conflict, or network configuration problem.
Why does ERR_EMPTY_RESPONSE appear after an SSL certificate change?
After updating an SSL certificate on an origin server behind a CDN or load balancer, several things can go wrong that produce ERR_EMPTY_RESPONSE. The CDN’s connection to the origin uses Full (Strict) SSL mode and the new certificate is not trusted by the CDN (wrong CA, missing intermediate, or Cloudflare-specific origin certificate required). The web server was not restarted after the certificate was updated and is still serving the old certificate. The new certificate’s chain is incomplete, stalling TLS handshakes. Verify the origin server is serving the correct certificate using openssl s_client and check CDN SSL settings after any certificate change.
How do I diagnose ERR_EMPTY_RESPONSE as a site owner?
Run curl -v https://yourdomain.com from an external server (not your origin server) with verbose output. Watch what happens after the TLS handshake: if curl shows ‘Empty reply from server’ or the connection closes immediately without any HTTP headers, the application is not sending a response. Check application logs for errors at the timestamp of the request. If curl returns data but browsers receive ERR_EMPTY_RESPONSE, the issue may be CDN-level or browser-specific. Test the origin directly with curl –resolve yourdomain.com:443:ORIGIN_IP to bypass CDN routing.
