ERR_EMPTY_RESPONSE: What It Means & How to Fix It

What Is ERR_EMPTY_RESPONSE?

ERR_EMPTY_RESPONSE is the error code Chrome and Edge show when a site sends nothing back; Chrome's page reads "This page isn't working. example.com didn't send any data." In Chromium it is net error -324, defined as: "The server closed the connection without sending any data" (net_error_list.h).

The browser got further than with most connection errors. The address resolved, the connection opened, and the browser sent its request. Then the server, or something in front of it, closed the connection with an empty reply: no status code, no headers, no page. Only Chromium's HTTP/1.1 code uses this error, and only for a fresh connection that closes with zero bytes (Chromium); when an old, reused connection closes, Chrome quietly retries, and over HTTP/2 the same close shows as ERR_CONNECTION_CLOSED. That's why you see it most on localhost, plain-HTTP addresses and servers that only speak HTTP/1.1.

Because a request was actually delivered, ERR_EMPTY_RESPONSE usually points at the server side: an app that crashed while handling the request, a rule that deliberately drops connections, or a service that accepted the connection but had nothing behind it. A few causes on your own computer can produce it too.

Firefox's NS_ERROR_NET_EMPTY_RESPONSE Is Something Else

Firefox has an error with almost the same name, and it means something different. NS_ERROR_NET_EMPTY_RESPONSE is desktop Firefox's code for a page that came back with an error status in the 400s (such as 403 or 404) and an empty body (Firefox source); Firefox for Android shows a blank page instead. The server did reply; it just sent no page to go with the error, so Firefox shows its own "Looks like there's a problem with this site" page instead.

So the fix is different too: find out which status the server sent and why. The browser's Network panel shows it; curl -I may get a different answer, because anti-bot rules often treat curl differently from a browser. A firewall or anti-bot rule that answers 403 with an empty body is one cause. Firefox's version of Chrome's empty reply, a connection closed with nothing sent, is NS_ERROR_NET_RESET, shown as "The connection was reset".

What Causes ERR_EMPTY_RESPONSE?

Fix 1: Reload and Try Incognito

If the server restarted at the wrong moment, a reload a few seconds later is all you need. If the error repeats, open the page in an Incognito window (Ctrl + Shift + N, Mac Cmd + Shift + N). Incognito starts without your saved cookies and runs only the extensions you've allowed in Incognito (none by default), so it quickly tells you whether something stored in your browser is involved.

Then check whether the site is down for everyone. The Website Down Checker loads the page from 11 places, and the HTTP Header Checker shows the status and headers our server gets: if they get a normal response, the problem is between you and the site. If they also get nothing, the site itself is failing.

Fix 2: Turn Off VPN, Proxy and HTTPS Scanning

Anything that sits in the middle of your connections can accept the request and then close it without passing the reply back:

• VPN: disconnect it completely and reload.
• Proxy: on Windows 11, Settings → Network & internet → Proxy → next to Use a proxy server, select Edit and turn it off (and turn off Use setup script if it's on). On a Mac, System Settings → Network → your connection → Details… → Proxies.
• Antivirus HTTPS scanning: turn off only the web or HTTPS-scanning feature (often called HTTPS scanning, Web Shield or SSL/TLS protocol filtering) and reload. If that fixes it, add an exclusion for the site and turn scanning back on.

Fix 3: Clear the Site's Data and Disable Extensions

Most servers answer very large cookies with a 400 or 431 error, but some servers and proxies drop the request instead, which shows up as an empty reply only after you log in. Clear that site's cookies: click View site information at the left of the address bar → Cookies and site data → Manage on-device site data → delete, then sign in again.

Next, disable all extensions at chrome://extensions and reload. Re-enable them one at a time to find the one that interferes, which is often an ad blocker, a privacy tool or anything that edits requests.

Fix 4: Flush DNS and Reset the Network Stack

If every site gives empty responses on one computer, reset its network configuration. In an administrator Command Prompt on Windows, run the commands below and restart. On a Mac, flush the DNS cache and remove and re-add the Wi-Fi network.

ipconfig /flushdns
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew

Also try another network, such as your phone's mobile data. If the site works there, a filter on your usual network (school, work or ISP) may be cutting the connection.

ERR_EMPTY_RESPONSE on Localhost and Docker

Developers see this error most often on their own machine. The usual causes:

• The app in a Docker container listens on 127.0.0.1. Inside a container, 127.0.0.1 means "only this container", so Docker's port forward has nothing to connect to and your browser gets an empty reply (or, depending on the setup, a connection reset). Make the app listen on 0.0.0.0 inside the container, for example vite --host 0.0.0.0, flask run --host=0.0.0.0 or uvicorn main:app --host 0.0.0.0 (next dev already listens on all interfaces).
• The container port mapping doesn't match. -p 8080:3000 forwards your port 8080 to port 3000 inside the container. If the app actually listens on 5000, every request comes back empty.
• http:// on an HTTPS-only port. Some servers expect TLS on a port and simply hang up when plain HTTP arrives. Try https://localhost:8443 instead of http://.
• The dev server crashed while handling the request. Check the terminal it runs in. An exception or out-of-memory error at that moment is your answer.

# Reproduce without the browser
curl -v http://localhost:8080/
# "Empty reply from server" = connection accepted, nothing sent back

# Which ports does the container publish, and what listens inside it?
docker ps --format "table {{.Names}}\t{{.Ports}}"
docker exec -it <container> sh -c "netstat -tlnp 2>/dev/null || ss -tlnp"

For Website Owners: Why Your Server Sends Empty Replies

• Crashes and out-of-memory kills. If the process handling the request dies, the connection closes with nothing sent. Check the app logs and dmesg -T | grep -i "killed process" for the Linux out-of-memory killer, especially on heavy pages and uploads.
• Deliberate drops. nginx's special return 444; closes the connection without any response, and it's often used to block bad bots or unknown hostnames. If a rule like that matches real visitors (an over-broad user-agent or GeoIP rule), they see ERR_EMPTY_RESPONSE, or ERR_HTTP2_PROTOCOL_ERROR on HTTP/2 connections, where nginx resets the stream instead. WAFs, rate limiters and anti-bot services can do the same.
• Port forwards and load balancers with no backend. A listener that accepts the connection but has no healthy server behind it can close it empty. Check target health and that the backend port matches.
• Timeouts that close instead of answering. Make long-running requests return a proper error (such as 504) instead of silently closing the socket, so visitors and monitoring see what happened.
• Oversized requests. Most servers answer very large headers or cookies with a 400 or 431 error, but some drop the request instead. Keep cookies small.

# Any rules that drop connections?
sudo grep -rn "return 444" /etc/nginx/

# Test from outside, the way visitors connect
curl -sv https://yourdomain.com/ -o /dev/null

ERR_EMPTY_RESPONSE vs Similar Errors

Related guides: ERR_CONNECTION_CLOSED, ERR_CONNECTION_RESET, 502 Bad Gateway and 500 Internal Server Error. To check whether a server's port accepts connections from outside, use the Port Checker.