---
title: ERR_CONNECTION_REFUSED: what it means and how to fix it
description: Connection refused means you reached the server's door — and it slammed shut. Nothing is listening (or something is blocking). Here's how to track down which.
canonical: https://watchfor.io/blog/connection-refused
---

# ERR_CONNECTION_REFUSED: what it means and how to fix it

2026-02-22 · WatchFor Team · Networking · networking, debugging, basics

Connection refused means you reached the server's door — and it slammed shut. Nothing is listening (or something is blocking). Here's how to track down which.

The browser fails fast and blunt: **ERR_CONNECTION_REFUSED.** No timeout, no error page — just an immediate "nope." That speed is actually a clue: the request reached the destination, and the destination *actively rejected* it.

Unlike a [500](/blog/500-internal-server-error) (the app broke) or a timeout (nobody answered in time), "connection refused" means you knocked and someone (or some rule) firmly said no.

## What it means

A **connection refused** happens at the network level, before any HTTP even starts. You reached the server's IP and port — but **nothing accepted the connection.** The two reasons:

1. **Nothing is listening** on that port (the service isn't running, or is on a different port).
2. **Something is blocking** it (a firewall rejecting, not silently dropping).

> **Refused vs timeout:** *refused* is instant — the destination said "no" right away. A *timeout* is slow — the destination never answered at all. Instant rejection usually means "wrong port / not running"; a hang usually means "firewall dropping" or "host unreachable."

## The usual causes

| Cause | What's happening |
| --- | --- |
| **Service not running** | The app/web server crashed or was never started |
| **Wrong port** | You're hitting `:80` but it's serving on `:8080` |
| **Bound to localhost only** | The service listens on `127.0.0.1`, not the public interface |
| **Firewall rejecting** | A rule actively refuses the connection |
| **Server overwhelmed** | The connection backlog is full |
| **DNS pointing at the wrong host** | You reached *a* server, just not the right one |

## How to fix it

1. **Is the service running?** The single most common cause. Check the process is up and hasn't crashed.
2. **Right port?** Confirm the service is listening on the port you're requesting. (A [port checker](/port-checker) tells you instantly whether a port is open.)
3. **Listening on the right interface?** A service bound to `localhost` works locally but refuses external connections — bind it to the public interface.
4. **Firewall rules.** Make sure the port is allowed for the clients (and monitors) that need it.
5. **Check DNS.** If the name resolves to the wrong IP, you might be knocking on the wrong door entirely — see [how DNS works](/blog/how-dns-works).

## Refused, timed out, or reset?

Three connection-level failures people lump together:

| Symptom | Likely meaning |
| --- | --- |
| **Connection refused** (instant) | Nothing listening / actively rejected |
| **Connection timed out** (slow) | Firewall dropping, or host unreachable |
| **Connection reset** | The connection opened, then was abruptly dropped |

Knowing which one you're seeing points you straight at the cause.

## How to catch it early

"Connection refused" means your service is, from the outside, completely **down** — even though the box might be running fine. A crashed process or a firewall change can trigger it silently. A simple uptime or [port monitor](/docs/monitors/network) that tries to connect from outside catches it immediately — which is the whole point of monitoring from where your users are.

## The bottom line

| | In one line |
| --- | --- |
| **What** | You reached the host, but the connection was rejected. |
| **Why** | Nothing's listening on that port, or a firewall refused it. |
| **Refused vs timeout** | Refused = instant "no"; timeout = no answer at all. |
| **Fix** | Check the service is running, on the right port and interface. |

ERR_CONNECTION_REFUSED is the network equivalent of a locked door with the lights off. Confirm the service is actually running, listening on the right port and interface, and not blocked — and monitor it from outside so you know the instant the door shuts.

Related: [uptime monitoring 101](/blog/uptime-monitoring-101); test a port with the free [port checker](/port-checker).

---

Canonical page: https://watchfor.io/blog/connection-refused · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt