ERR_CONNECTION_REFUSED

ERR_CONNECTION_REFUSED is a browser error that appears when the browser reaches the target host but the connection is actively rejected. It differs from a timeout: instead of silence, the machine replies that it will not accept the connection, which usually means nothing is listening on that port, the port is wrong, or a firewall is blocking the attempt. The error is local to the client's connection and can occur on any operating system or browser.

What it means

To open a page, a browser first resolves a hostname to an IP address and then opens a TCP connection to a specific port — 443 for HTTPS, 80 for HTTP, or whatever the URL specifies. ERR_CONNECTION_REFUSED happens at that second step: the host answered, but refused the connection, typically by replying with a TCP reset. That is why the error tends to appear almost instantly rather than hanging; a firewall that silently drops packets produces a timeout instead of a refusal.

The usual causes are few and each is fixable. Nothing may be listening on the port, because the web, database, or application server is stopped or crashed. The port may be wrong — a development server on 3000 while the URL asks for 8080. A firewall or security tool may be blocking the port. Or there may be an address mismatch, where the service is bound to only one interface so one address works and another does not.

That last point trips up many developers, and the two names localhost and 127.0.0.1 are at the heart of it. On most systems localhost resolves to the IPv6 address ::1 before, or instead of, the IPv4 127.0.0.1. A server listening only on IPv4 will happily answer 127.0.0.1 and refuse localhost. Binding the server to all interfaces removes the ambiguity. If you meet the error on a site you do not run, it is usually transient or that site's own outage; reload, try another network, and check a status page before assuming the fault is at your end.

Common causes

• Nothing is listening — the web, database, or application server is stopped, crashed, or was never started.
• The wrong port is in the URL, or the service is bound to a port other than the one being requested.
• A firewall, antivirus, or network security tool is blocking the connection.
• The app listens only on 127.0.0.1, so localhost (IPv6 ::1) or the machine's LAN address is refused.
• The service is bound to a loopback address while a client on another machine tries to connect to it.

How to fix it

1. Confirm whether anything is listening. On Linux or macOS use ss -ltnp or lsof -iTCP -sTCP:LISTEN; on Windows use netstat -ano | findstr :8080. No row for the port means nothing local is listening on it.
2. Start the service and match the port. Restart the server and check that it listens on the port the URL uses. For a development server, browse to the exact host and port it printed when it started.
3. Try the IP instead of the name. If http://localhost:3000 fails but http://127.0.0.1:3000 works, the server is bound to IPv4 only. Bind it to all interfaces:

   # bind to 0.0.0.0 (all IPv4) or :: (all interfaces)
   python -m http.server 8000 --bind 0.0.0.0
   node server.js   # use app.listen(8000, '0.0.0.0')

4. Open the firewall for the port. Allow the port through the operating system firewall or security suite and confirm the rule's direction and profile. On Linux with ufw:

   sudo ufw allow 8000/tcp
   sudo ufw status

5. Rule out the local stack. Restart the networking service, flush the DNS cache, and load another site to be sure the problem is the target and not your own connection.

How to prevent it

Bind servers to a documented, consistent interface and port, and write that down so you stop guessing later. Add a health check or a service supervisor that restarts a crashed process automatically, open firewall rules deliberately, and review them so stale blocks do not linger. In scripts and config, use 127.0.0.1 where you mean IPv4 so IPv6 name resolution cannot surprise you.

When you deploy, verify that the listening socket is actually live before you switch traffic to it, and keep a clear note of which port each service owns. Most connection refusals come down to a stopped process, a mismatched port, or a blocked one; a short checklist covering those three will resolve the great majority of them in a minute or two.