How to Fix ERR_EMPTY_RESPONSE in Chrome (Server Closed the Connection)
What ERR_EMPTY_RESPONSE means
To load a page, your browser first opens a connection to the server and then asks for the page. Most errors describe a failure in one of those two moments. ERR_EMPTY_RESPONSE describes something weirder: the connection opened fine — the server picked up the phone — and then the server closed it without sending anything back. No headers, no HTML, no status code. Chrome cannot show you a proper error page because there was no response at all, so it shows this message instead.
That ambiguity is what makes this error tricky, because the connection can die on either end. On your side, an ad blocker or VPN extension can intercept and kill the request before it ever reaches the site. Your router or ISP can route the connection fine and then drop it mid-request. On the server side, a crashed backend application leaves the web server accepting connections it cannot answer. A firewall or rate-limit rule can terminate a connection instead of returning a polite 429. A server out of memory or out of database connections will quietly die. The good news: a simple elimination order — extensions first, then the network, then the server — finds the culprit in almost every case, and the steps below walk it in exactly that order.
Common causes
- Crashed or stopped backend service: the reverse proxy (Nginx, Apache, Cloudflare) accepts your connection but the application behind it — PHP-FPM, Node, Python, or the database — is dead, so the proxy has nothing to return.
- Extension interference: ad blockers, privacy tools, VPN and proxy extensions, and antivirus browser plugins intercept requests and can terminate ones that match their rules without sending an error page.
- Network or routing interruption: a Wi-Fi drop, a stale DNS answer, or a bad ISP route opens the connection and then loses it before any data comes back.
- Firewall or rate-limit rules: a server firewall, web application firewall, or rate limiter closes connections it considers suspicious instead of returning a proper status.
- Resource exhaustion on the server: out of memory, a full disk, or exhausted PHP-worker and database connection pools kill the connection silently when the server cannot handle one more request.
How to fix ERR_EMPTY_RESPONSE — step by step
Steps 1 through 4 are for visitors. Steps 5 and 6 are for site owners.
- Visitor: hard-refresh the page and retry. An ERR_EMPTY_RESPONSE is often a one-off: the server accepted the connection, then something on its side died before it could reply. Give it the simplest possible test first — hard-refresh with Ctrl+Shift+R on Windows or Cmd+Shift+R on Mac, which reloads the page while bypassing the browser cache, and try the URL again. If the page loads on the second or third attempt, it was a transient server hiccup or a momentary network drop, and nothing else needs fixing.
- Visitor: clear the site's cache and cookies. Corrupted cache entries and stale cookies can break the request before the server ever processes it. In Chrome go to Settings, then Privacy and security, then Delete browsing data, choose Cached images and files plus Cookies and other site data, set the time range to All time, and click Delete data. Then close every tab for that site, reopen it, and retry. If the error is gone, a bad cached response or an expired session cookie was triggering the server to close the connection.
- Visitor: disable extensions and test in incognito. Ad blockers, VPN and proxy extensions, and security toolbars sit between your browser and the server — and some of them kill connections that match their filter rules. Disable your extensions (especially any ad blocker, VPN, or privacy extension), or faster: open the page in an incognito window, which loads with extensions turned off and a clean profile. If incognito works, re-enable extensions one at a time until the error returns, then remove or whitelist the site in the offending one.
- Visitor: reset the network path — restart the router, flush DNS, try another network. A flaky route between you and the server can open the connection and then drop it. Power-cycle your router by unplugging it for a full 60 seconds, then flush the DNS cache so your machine stops using a stale address: on Windows open Command Prompt as administrator and run ipconfig /flushdns; on Mac run sudo dscacheutil -flushcache in Terminal. Then test the page on a different network — mobile hotspot is the fastest check. If the site loads on the hotspot, your ISP's routing or your router's state is the problem, not the website.
- Site owner: confirm the backend service is actually running. On your server, check that the service answering the port is alive. If the site runs behind a reverse proxy (Nginx, Apache, or Cloudflare) with the application in PHP-FPM, Node, Python, or a database, the proxy may accept the connection and then find nothing behind it — which produces exactly this error. Look at the running processes, restart the application service and the web server, and watch the error logs (for example /var/log/nginx/error.log or the Apache error log) during a test request: a crashed worker, an out-of-memory kill, or a database that refuses connections will show up there.
- Site owner: check firewall rules, rate limits, and resource exhaustion. Security layers can close a connection before the application ever sees it. Check your server firewall and any web application firewall (Cloudflare rules, ModSecurity, fail2ban) for blocks on your own IP or on the visitor's range, and look for rate-limit rules that drop connections instead of returning a 429. Then check resource limits: a server out of memory, out of disk, or hitting its PHP worker or database connection cap will accept sockets and then die silently. Free up disk space, raise the worker and connection limits if the traffic justifies it, and confirm the site serves a normal response to curl -sI before declaring it fixed.
Did this fix it? Quick checklist
- The page loads after a hard refresh — if not, it loads in an incognito window with extensions off
- Browser cache and cookies for the site were fully cleared, not just reloaded
- The page works on a different network (mobile hotspot) — if yes, the original network or router was the problem
- Server-side: the backend service is running, no firewall rule is dropping connections, and curl -sI returns a normal response
If the error shows up only in your normal profile but never in incognito, an extension is the culprit — disable them one at a time rather than resetting your whole browser. If it shows up on every device on your home network but works on mobile data, power-cycle the router and flush DNS; router state is the quiet cause behind a surprising number of these. Site owners who fixed it by restarting a crashed backend should also find out why it crashed — a service that dies once will die again, and the error logs usually name the reason. And if nothing on either side explains it, check whether a CDN, security plugin, or host-level rate limiter sits between the visitor and the server: any layer that accepts a connection and then silently terminates it produces exactly this error, and the fix is always at the layer that hung up.
Frequently asked questions
What does ERR_EMPTY_RESPONSE mean?
ERR_EMPTY_RESPONSE is Chrome's way of saying the connection to the server opened successfully, but the server then closed it without sending back any data — no headers, no page, not even an error status. In plain English: your browser knocked, the server opened the door, and then hung up without saying a word. The cause can sit on either end: a browser extension, your network, or a server whose backend crashed or was killed by a firewall or resource limit.
How is ERR_EMPTY_RESPONSE different from ERR_CONNECTION_REFUSED or ERR_CONNECTION_TIMED_OUT?
They fail at different stages. ERR_CONNECTION_REFUSED means nothing was listening on the server at all — the door was locked. ERR_CONNECTION_TIMED_OUT means the server never answered the knock — nobody came to the door. ERR_EMPTY_RESPONSE means the server answered and then abruptly ended the conversation — it picked up and hung up. That distinction matters: refusal and timeout usually mean the server is down or unreachable, while an empty response often means the server (or something in front of it, like a proxy, firewall, or crashed backend) accepted the connection and then dropped it.
Is ERR_EMPTY_RESPONSE my fault as a visitor, or the website's fault?
It can honestly be either, so test your side first. Extensions (especially ad blockers and VPN tools), corrupted cookies, and a bad network route are all visitor-side causes you can fix yourself in minutes. The fastest verdict: try the page in incognito, then try it on a different network like a mobile hotspot. If it works in incognito, your profile is the problem. If it works on the hotspot, your network is the problem. If it fails everywhere, the server or something between you and it is closing the connection, and only the site owner can fix it.
Can an ad blocker or VPN extension cause ERR_EMPTY_RESPONSE?
Yes — this is one of the most common visitor-side causes. Extensions that filter traffic (ad blockers, privacy tools, VPN and proxy extensions, some antivirus browser plugins) intercept your requests, and some of them terminate connections that match their rules without returning a proper error page — which Chrome reports as an empty response. Test in an incognito window with extensions off; if the page loads, disable extensions one by one in your normal profile until the culprit shows itself, then remove it or add the site to its allowlist.
I own the site and keep getting ERR_EMPTY_RESPONSE — where do I start?
Start with the two most common server-side causes: a dead backend and a hungry firewall. First, check that the application behind your web server is running — a crashed PHP-FPM pool, a dead Node process, or a database refusing connections makes the proxy accept the socket and then drop it. Second, check your firewall, web application firewall, and rate-limit rules for blocks that silently close connections. Then read the error logs while reproducing the failure; out-of-memory kills, full disks, and exhausted connection pools all leave a trace there.