What is the difference between ERR_CONNECTION_REFUSED and ERR_CONNECTION_TIMED_OUT?

Refused (Chromium net error -102) means the host answered your SYN with a TCP RST: it is reachable, but nothing is listening on that port, or a REJECT rule sent the reset. Timed out (-118) means the SYN got no answer at all, so the browser waits out its retries before failing. Refused is the instant one; timed out is the long hang.

It loads when I run curl on the server itself but refuses from every other machine. Why?

Almost always a bind-address problem. The service is listening on 127.0.0.1 (loopback) instead of 0.0.0.0 (all interfaces), so it answers connections that originate on the box and refuses everything arriving on the public interface.

Why does the error appear instantly instead of hanging?

A RST comes back in a single round-trip, so the browser learns the connection failed immediately. There is nothing to retransmit and nothing to wait for. That instant failure is the signal that you are looking at a refusal, not a silently dropped packet.

Views: 22

ERR_CONNECTION_REFUSED Fix Guide

ERR_CONNECTION_REFUSED is an instant TCP RST, not a timeout. Fix it in 3 checks: listening port, bind address, firewall reject rules. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A page fails almost instantly with ERR_CONNECTION_REFUSED (or “This site can’t be reached”). The host is reachable and it answered your SYN, but it answered with a TCP RST instead of a SYN/ACK. Something on the other end is actively saying go away. The lack of a hang is the diagnostic signal: this is a rejection, not a silently dropped packet.

Symptoms

The error appears immediately, not after a one-to-two-minute wait.
curl reports Connection refused; the request never starts loading.
It may work from the server itself (curl localhost) while every other client is refused.
The error is not ERR_CONNECTION_TIMED_OUT (long hang) or ERR_NAME_NOT_RESOLVED (DNS never resolved).

Top 3 Causes

Nothing is listening on that port - The service crashed, was never started, or is bound to a different port than the URL targets (an app on 8080 while the browser hits 443). With no socket in LISTEN for that port, the kernel answers the SYN with a RST, exactly as RFC 9293 specifies for a closed port.
The service is bound to loopback only - It listens on 127.0.0.1 instead of 0.0.0.0, so it serves requests that originate on the host and refuses every connection arriving on the public interface. This is the classic “works locally, refused remotely.”
A firewall actively rejects the connection - A REJECT rule, or a proxy returning ICMP port-unreachable, sends an immediate rejection. This is the opposite of a DROP rule, which swallows the packet and produces a timeout instead of a refusal.

Diagnose with DechoNet

Port Check to test the target port from outside your network. A closed (refused) result confirms the browser’s view: either nothing is listening or a reject rule sits in the path. An open result means a process is listening and the problem is higher up the stack.
HTTP Check to confirm whether the refusal is global or local to your network, by attempting the request from an external vantage point.
DNS Lookup to confirm the A/AAAA record points at the host where the service actually runs, not a previous IP where nothing listens anymore.

If the port hangs and times out instead of refusing, switch to the ERR_CONNECTION_TIMED_OUT fix. If the refusal is specifically on port 443, use the open port 443 closed checklist.

Resolution Checklist

Confirm the service process is running and in LISTEN on the expected port (ss -lntp or netstat -lntp).
Check the bind address: 0.0.0.0 (all interfaces) versus 127.0.0.1 (loopback only). Loopback-only is the usual cause of “works locally, refused remotely.”
Verify the URL’s port matches where the service listens - 443 for HTTPS, 80 for HTTP, or the explicit :port.
Look for firewall REJECT rules, or a reverse proxy whose upstream is down, that reject rather than drop.
Confirm DNS resolves to the host where the service actually runs, not an address left over from a previous deployment.
Re-run Port Check after each change to confirm the handshake now completes.

When to Escalate

Escalate to whoever owns the service if the port refuses from multiple external networks while the process looks healthy on the host itself - that points at a bind-address or proxy-configuration problem rather than the network.
Escalate to firewall or network owners if a REJECT rule is rejecting source ranges that should be allowed.