ERR_CONNECTION_REFUSED

The short version: Double-check the URL and port, then reload. Clear cache and cookies, open an incognito window, and switch off any VPN, proxy, firewall, or antivirus that could be blocking it. Flush DNS and restart your router. And if the website is down for everyone, the fix lives on the server side, not yours.

Key takeaways

• ERR_CONNECTION_REFUSED is an active no. Your browser sent a TCP SYN; the other end fired a RST (reset) straight back. The rejection lands instantly, with no slow wait.
• Boil it down and there are two real causes. Either nothing is listening on that port (service stopped, or bound somewhere else), or a firewall is rejecting the connection for the server.
• Watch the timing. A refusal hits the second you press Enter; a timeout leaves you waiting. No spinner means a refusal, not a host you cannot reach.
• From the shell, a refusal is curl exit code 7, the same code curl uses for any failed connect. To see what is really listening on the port, run ss -tlnp on the server.
• Refusals are tied to a single port. A web server on 443 can be perfectly fine while SSH or a database refuses on its own port, so monitor the exact port each service answers on.

Error type

Browser connection error

Whose side

Either: the server, or your local block

Fix difficulty

Easy to moderate

Common cause

Nothing is listening on that port

What does ERR_CONNECTION_REFUSED mean?

ERR_CONNECTION_REFUSED means your browser found the server and knocked, but got a flat no in return. Under the hood, your machine sent a TCP SYN to start the connection and received a RST (reset) instead of a handshake. Two things cause that: nothing is listening on the port you tried (the web service is stopped, or bound to the wrong port), or a firewall is actively rejecting the request and sending the reset on the server's behalf.

Speed gives it away. A refusal is instant because the server flatly turned you away. A timeout does the opposite, leaving your browser to sit and wait for an answer that never arrives. See the error the moment you press Enter and you are almost certainly looking at a refusal, not a slow or unreachable host.

RST

A refused connection is an active TCP reset, sent back instantly

80 / 443

The HTTP and HTTPS ports a browser expects a web server to answer on

0 ms

Refusal is immediate, unlike a timeout that waits for a reply that never comes

How the ERR_CONNECTION_REFUSED error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This site can't be reached

example.com refused to connect.

ERR_CONNECTION_REFUSED

• Chrome / Edge: ERR_CONNECTION_REFUSED
• Firefox: Unable to connect
• Safari: Safari can't open the page because the server unexpectedly dropped the connection
• curl: Failed to connect to host: Connection refused
• localhost refused to connect
• Telnet / nc: Connection refused

ERR_CONNECTION_REFUSED vs timed out, reset, unreachable

These four errors look similar but point at very different failures, and knowing which you have narrows the fix immediately.

What sends the reset, and who fixes it

A refusal always comes from something sending a reset; identifying the source points straight at the fix.

Refused vs timed out vs reset, by what the server did

These three connection failures look alike but reflect three different server responses, and each narrows the fix.

What causes ERR_CONNECTION_REFUSED?

• The web service is down, or not listening on the port the browser is using.
• The URL carries the wrong port, so you are knocking on a door with no service behind it.
• A firewall or some security tool is actively rejecting the connection.
• A proxy or VPN routes your traffic through a server that refuses, or simply cannot reach the target.
• A stale local DNS entry or browser cache points you at the wrong place.
• A browser or security extension blocks the request before it ever leaves.
• For developers: the local server is not running, or it is bound to localhost only.

How to find the cause fast

1. Open a different website. If everything else loads, the trouble is that one site, not your connection.
2. Hop to a second network, say Wi-Fi to a phone hotspot, which rules out a local block.
3. Look hard at the address and port. A missing or wrong port number is a classic cause of an instant refusal.
4. On your own website, confirm the web service is running and listening on the expected port with ss -tlnp.

Terminal

curl -I https://example.comcurl: (7) Failed to connect to example.com port 443: Connection refused# nothing is listening on the port, or a firewall rejected it

How ERR_CONNECTION_REFUSED looks from the outside

ERR_CONNECTION_REFUSED is one of the cleaner things to monitor for, since the rejection is immediate and explicit rather than a slow fade into a timeout. Pulsetic runs HTTP(S), TCP, and port checks from 15+ locations every 30 seconds, so a refused connection trips an alert the moment the server quits answering on the expected port. Running from outside your own network, the check also tells you whether the refusal is global or just local to one visitor. Here is the honest catch: a monitor confirms the door is shut from the outside, but it cannot tell you why the service stopped listening.

How to fix ERR_CONNECTION_REFUSED

If you are a visitor

1. Re-read the URL, make sure the port is right, then reload.
2. Clear the browser cache and cookies for that website.
3. Open the site in an incognito or private window, which sidelines extensions.
4. Drop any VPN or proxy, and turn off proxy settings in your system network options.
5. Switch off your firewall or antivirus briefly to see if it is the block, then turn it back on.
6. Flush your DNS cache: ipconfig /flushdns on Windows, or sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS.
7. Restart the router to clear any stuck network state.
8. Before blaming your own setup, check an external uptime tool to see whether the site is down for everyone.

If you run the website or server

1. Confirm the web service is running and bound to the right port with ss -tlnp.
2. Open the relevant port (usually 80 and 443) in the server firewall.
3. Look at the reverse proxy, Nginx or Apache, and make sure its upstream is alive.
4. Restart the web service and read the logs as it comes back up.
5. If remote visitors need in, verify the service listens on 0.0.0.0, not just 127.0.0.1.
6. Put an external monitor on the port so the next refusal pages you before users do.

Still not fixed? Next steps

• Found the service bound to 127.0.0.1 while remote clients are refused? Rebind it to 0.0.0.0 (or the right interface) and restart. A localhost-only bind refuses every external connection by design.
• Port open in the firewall, service listening, clients still refused: look upstream. A reverse proxy with a dead backend will reject connections because it has nothing healthy to hand them to.
• When a refusal shows up only after a deploy or restart, tail the service logs while it comes back. A process that crashes on startup leaves the port unbound, and that reads as a refusal to every visitor.
• One service refusing while the web server stays healthy is easy to miss. Put an external monitor on that specific port so the next port-level refusal pages you, instead of leaning on a homepage check that would never catch it.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Check what is actually listening on the server

ss -tlnp
# or on older systems:
netstat -tlnp | grep LISTEN

Test the exact port from the client

nc -zv example.com 443
curl -v https://example.com

Open the port in the firewall (Linux ufw example)

sudo ufw allow 443/tcp
sudo ufw reload

How to prevent ERR_CONNECTION_REFUSED

A refused connection means the door is shut: the service is down, the port is closed, or a firewall is rejecting traffic, and every visitor sees it the instant they arrive. Pulsetic checks your website and ports from multiple locations every 30 seconds with HTTP, TCP, and port checks, and the moment a service stops accepting connections it alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook. What it measures is reachability from the outside, not your server's CPU or memory.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.