ERR_CONNECTION_REFUSED — What It Means and How to Fix It

Refused, timed out, reset — they mean different things

These three get treated as interchangeable "site is broken" errors, but each one tells you something specific about where the failure happened.

Common causes, most frequent first

• Nothing is listening on that port. The web server crashed, was stopped, or never started after a reboot. This is the single most common cause when you own the site.
• You are using the wrong port. Hitting https:// on a server that only serves plain HTTP, or connecting to a dev server on 3000 that is no longer running.
• A firewall is set to REJECT rather than DROP. Both block you, but REJECT sends back the rejection that produces this exact error.
• The service is bound to localhost only. Very common with development setups and newly configured databases — the process is running, but it only accepts connections from the machine itself.
• Browser proxy or extension misconfiguration. A VPN or proxy extension pointing at a proxy that is not running will refuse every connection you make.
• Local software blocking it — antivirus, a corporate endpoint agent, or a parental-control tool refusing outbound connections to that host.
• The site genuinely moved or shut down and something else now answers at that IP.

First: is it just you, or everyone?

Two minutes here saves an hour of fixing a server that was never broken.

• Open the site on mobile data with Wi-Fi off. If it loads, the server is fine and the problem is your network, your machine, or your browser.
• Try an incognito window, then a different browser. This clears extensions and cached proxy settings from the list of suspects.
• Use any "is it down for everyone" checker. It connects from an outside server and gives you an objective answer.
• Try the same site from a different device on the same network. If every device fails but mobile data works, the problem is your router or ISP-level filtering.

If you are a visitor — check in this order

• Confirm the address is right, including the protocol. Some servers only listen on HTTP and will refuse HTTPS outright, and vice versa.
• Disable your VPN or proxy extension and retry. If a proxy is configured but the proxy software is not running, every connection gets refused.
• Check your system proxy settings. On Windows, look under Internet Options; on macOS, under Network settings. Clear anything you did not set deliberately.
• Clear the browser cache and DNS cache. On macOS run "sudo dscacheutil -flushcache"; on Windows run "ipconfig /flushdns".
• Temporarily disable antivirus web protection. Some security suites refuse connections to hosts on their blocklists without saying so clearly.
• Restart your router. This clears stale NAT state that occasionally causes connections to be rejected for one specific destination.
• If nothing works and other people can reach the site, your ISP may be filtering it. Test with mobile data to confirm before spending more time.

If you own the site — the diagnosis that matters

When you control the server, "refused" is one of the easier errors to track down, because it points at a very specific question: is anything listening on that port, and will it accept connections from outside?

• Check whether the service is running: "systemctl status nginx" or "systemctl status apache2". If it is stopped, start it — then read the logs to find out why it stopped, because it will happen again.
• Check what is actually listening: "ss -tlnp" (or "netstat -tlnp"). This is the most informative single command for this error. You want to see your web server bound to ports 80 and 443.
• Look at the bind address in that output. "127.0.0.1:80" means the service only accepts local connections and will refuse everyone else. It needs to be "0.0.0.0:80" or your public IP.
• Check the firewall. With ufw, run "ufw status"; with firewalld, "firewall-cmd --list-all"; on a VPS, also check your provider's network-level firewall, which is separate from the one on the machine.
• Confirm from outside the server. Run "curl -I https://yoursite.com/" from another machine, or "telnet yoursite.com 443". Testing from the server itself will succeed even when the outside world is blocked.
• Check the port a service actually uses after config changes. A typo in a listen directive is a very common cause right after an edit.
• If the service will not start, read the error log before restarting again. Port conflicts ("address already in use") and syntax errors in config files are the usual reasons.

The bind-address trap

This deserves its own section because it produces the most confusing version of this error: the service is definitely running, the firewall is definitely open, and connections are still refused.

Many services default to binding on 127.0.0.1 — the loopback address — which means they only accept connections originating from the machine itself. This is a sensible security default for databases and development servers, and it is exactly what you want for MySQL in most setups.

But it is not what you want for a public web server. If ss shows "127.0.0.1:80" instead of "0.0.0.0:80", the fix is in the service configuration, not the firewall. In Nginx it is the listen directive; in Apache, the Listen line; in Node or Python apps, the host argument you pass when starting the server — binding to "localhost" instead of "0.0.0.0" is a one-word mistake that produces exactly this error.

The reason this trips people up is that testing from the server works perfectly. Always test from a different machine.

Preventing it from happening again

• Enable the service so it survives reboots: "systemctl enable nginx". A service that starts manually but is not enabled will disappear after the next restart.
• Set up uptime monitoring with alerting. Finding out from a customer costs you the first and most expensive half hour.
• Test config changes before applying them. "nginx -t" validates the configuration and catches the typos that stop the service from restarting.
• Document your firewall rules. Rules added during troubleshooting and never removed cause mysterious refusals months later.
• Watch memory. Services killed by the OOM killer stop cleanly and produce exactly this error — check "dmesg | grep -i oom" when a service dies for no obvious reason.
• Keep a second way in. VNC or a rescue console lets you fix a firewall rule that locked you out; without one, a bad rule means a support ticket.