"The Connection Was Reset" in Firefox: Causes and Fixes

The page title is «Problem loading page» and the heading is The connection was reset (netReset-title in Firefox's certError.ftl). Under it Firefox lists generic advice: the site could be temporarily unavailable, check your network connection, and make sure Firefox is permitted to access the web if a firewall or proxy protects your computer.

Firefox shows this page for the internal error NS_ERROR_NET_RESET (nsDocShell.cpp). Its socket layer produces that code in two situations: a real TCP reset (PR_CONNECT_RESET_ERROR) and an unexpected end of stream (PR_END_OF_FILE_ERROR), which Firefox treats «the same as reset» (nsSocketTransport2.cpp). So in Firefox this one message covers what Chrome splits into ERR_CONNECTION_RESET and ERR_EMPTY_RESPONSE.

One more case lands here: in current Firefox, NS_ERROR_OS_LOCAL_NETWORK_ACCESS_DENIED is temporarily grouped with netReset, so on macOS a page on your own LAN (router, NAS, a dev server on another machine) can show «The connection was reset» when the operating system denies Firefox local network access.

The fastest split is «who else sees it». One browser: a Firefox setting or extension. One computer: security software, VPN or proxy on that machine. One network: that network or its ISP. Everyone: the server.

1. Proxy. Open Settings, scroll to Network Settings and click Settings. If «Manual proxy configuration» or an automatic configuration URL is set and you do not need it, choose «Use system proxy settings» or «No proxy» and reload. A proxy that is down usually gives «The proxy server is refusing connections» instead, but a filtering proxy can reset individual sites.
2. Extensions. Restart in Troubleshoot Mode (Help, Troubleshoot Mode) to start without extensions. If the site loads, re-enable extensions one by one.
3. Secure DNS. Firefox can resolve names over HTTPS. If your resolver hands out a wrong address for the site, toggling DNS over HTTPS in Settings, Privacy & Security changes which address Firefox connects to.
4. A stale address. When a fresh connection is reset before any data was sent, Firefox marks that address as unusable for the retry, so a host with several addresses may recover on its own; after fixing DNS, a hard reload (Ctrl+F5) after fixing DNS avoids reusing an old connection.

1. Reproduce without Firefox, from outside your own network:

   curl -v https://example.com/ -o /dev/null
   # * Recv failure: Connection reset by peer   -> an RST
   # * Empty reply from server                  -> closed with no data

2. An empty reply means the server process gave up. Look for crashed or killed workers and for a proxy whose upstream closed early:

   dmesg -T | grep -i 'killed process'
   grep -i 'prematurely closed\|reset by peer' /var/log/nginx/error.log | tail

3. A reset can come from the firewall. Rules that answer with a reset, and bans added by fail2ban, look exactly like this to a visitor:

   iptables -S | grep -i reset
   fail2ban-client status

4. Check the port is open from outside. If the port answers on the server but not from the Internet, the reset is in the path, not in your stack. Steps for Chrome visitors are on the ERR_CONNECTION_RESET guide.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
# 200

Run it from the network that failed, then reload in Firefox with Ctrl+F5. To check that the host answers and the port is open from outside your network, use the ping and port checker.

• ERR_CONNECTION_RESET — the same reset in Chrome and Edge
• ERR_EMPTY_RESPONSE — Chrome's name for a close without data
• ECONNRESET — the reset as Node.js and other runtimes report it
• SEC_ERROR_UNKNOWN_ISSUER — a certificate problem, not a reset
• ERR_CONNECTION_CLOSED — closed with FIN in Chrome