Connection refused: no status code, and that is the point

Every HTTP status code, including the ugly ones, is proof that a web server ran. Something parsed a request and chose a number. A 500 means your application crashed, which at least means your application exists and was reached.

Connection refused is not that. There is no code, because there was no HTTP conversation. The failure happened one layer down, and that is why it is worth more than a 500: it removes the entire application from suspicion before you have opened a single log.

Three failures that get reported as one

Clients, and quite a few monitoring dashboards, say "the site is down". Underneath there are three distinct outcomes, and they point at different people.

Refused is the friendliest of the three, and people misread it as the worst. A reset is a deliberate answer from a real machine. The server exists, you found it, and the specific process that should have been listening on port 443 is not running or is bound somewhere else.

Timed out is the ambiguous one, because silence has many causes. A firewall dropping packets, an address that belongs to nobody, a host that is genuinely off, a security group that was edited this morning. Silence tells you only that you got no reply.

Getting the actual answer instead of the browser's version

Browsers rewrite these errors into reassuring prose and then retry in the background, which is how a site can be broken in a way you cannot reproduce. Ask directly.

curl -v https://example.com/ 2>&1 | head -20

The interesting lines come before any HTTP. Trying 203.0.113.10:443... tells you which address was actually used, which is often the whole answer. Then either Connected to, or the failure in plain words.

To separate the port question from everything else:

nc -vz example.com 443
nc -vz example.com 80

Port 80 open and 443 refused is a very specific and very common state: the web server is running and its TLS listener is not. That happens when a certificate renewal wrote a file the server could not parse and the reload half-failed, leaving the plain-text virtual host up and the secure one down. It also happens when a firewall rule was written for one port and not the other.

And if you have a shell on the machine, the question of who is listening has an exact answer:

ss -ltnp | grep -E ':(80|443)\b'

The one that will waste your afternoon: IPv6

This is the case worth knowing, because it produces a disagreement between two tools that are both telling the truth.

A domain has an A record and an AAAA record. The AAAA points at an address that no longer serves anything: a host that moved, a load balancer that was rebuilt, an address inherited from a previous provider and never removed from the zone. IPv4 works perfectly.

Your browser tries both, in parallel, and uses whichever connects first. It never mentions the one that failed. Your monitoring probe, or your colleague's terminal, resolves AAAA first and gets refused. One of you says the site is down and the other says it is fine, and you are both right about your own path.

curl -sS -o /dev/null -w '%{http_code}\n' -4 https://example.com/
curl -sS -o /dev/null -w '%{http_code}\n' -6 https://example.com/
dig +short example.com A
dig +short example.com AAAA

If -4 succeeds and -6 refuses, you have found it, and the fix is in the DNS zone rather than on the server. Either point the AAAA record at something that listens or remove it. Leaving a stale AAAA in place means a growing share of visitors, on mobile networks in particular, take the broken path first.

The same disagreement appears whenever two observers resolve a name to two different addresses, which is also the everyday shape of a DNS change still working its way through caches. In both cases the rule is the same: before arguing about whether a site is up, agree on which address you are each talking to. If you want a second opinion from somewhere that is not your office or your office's resolver, check the address from here.

Refused, from a proxy's point of view

You will rarely see connection refused on a site behind Cloudflare or any other reverse proxy, and not because it does not happen. The proxy meets the refusal, and hands you a 502 instead. The failure is identical; the reporting layer converted it into an HTTP code because it has to answer the browser with something.

That is worth remembering when a client site is proxied and you are trying to work out whether the origin is running at all: the 502 you are looking at may be a refused connection in disguise, and the way to find out is to ask the origin directly rather than through the proxy. What a 502 tells you covers that separation and the commands for it.

What to record when it happens at three in the morning

A checker that logs "site down" has thrown away everything that mattered. The three failures above call for three different people: your host, the network, or the DNS provider. By the time you read the alert, the state may have changed and you cannot ask again.

What you want stored, at the moment of failure: the address that was tried, the exact error rather than a category, and whether the attempt was over IPv4 or IPv6. That is three short strings, and having them turns a morning of guessing into one message to the right party. A monitor that stores only a red dot is asking you to reproduce an outage that has ended, which is the one thing you cannot do.

Once the connection does succeed, the reading changes completely and the number on the first line starts carrying meaning again. Which of those numbers deserve an alert, and which only deserve a counter, is the subject of the nine codes that matter in production.