Diagnosing 'connection refused' errors

Connection refused is one of the most common — and most misdiagnosed — errors in networking. People assume it's a firewall, spend an hour on firewall rules, and never fix it, because the error is actually telling them something quite specific. Understand what it means and the fix usually takes minutes.

What "connection refused" really means

Here's the crucial distinction:

• Connection refused means your packet *reached the server*, but nothing was listening on that port. The operating system actively sent back a rejection (a TCP RST). You got an answer — a "no."
• Connection timed out means your packet got no answer at all, usually because a firewall silently dropped it, or the host is unreachable. You got silence.

This difference is your biggest clue. Refused = reached the machine, no service there. Timeout = something is blocking the path. If you're seeing "refused," a network firewall is usually *not* your problem — the packet clearly got through.

The usual causes of "connection refused"

1. The service isn't running. The most common cause by far. Nothing is listening, so the OS refuses.
2. The service is listening on the wrong address. It's bound to 127.0.0.1 (localhost only) but you're connecting from outside. Local works, remote is refused.
3. The service is on a different port than you're connecting to.
4. The service crashed or failed to start and you didn't notice.

Step-by-step diagnosis

Work from the service outward — this order finds it fastest.

Step 1: Is the service even running?

sudo systemctl status nginx

If it's inactive or failed, that's your answer. Start it and read the logs if it won't stay up:

sudo systemctl start nginx
sudo journalctl -u nginx --no-pager -n 50

Step 2: Is anything listening on the port?

sudo ss -tulpn | grep :443

No output means nothing is bound to that port — the service isn't listening where you think.

Step 3: What address is it bound to?

This is the sneaky one. Look at the local address in the ss output:

• 127.0.0.1:5432 — localhost only. Remote connections will be refused. Databases ship like this by default.
• 0.0.0.0:443 or *:443 — listening on all interfaces. Reachable externally.

If it's bound to 127.0.0.1, edit the app's config to listen on 0.0.0.0 (or the specific public IP) and restart. In PostgreSQL that's listen_addresses; in many apps it's a host/bind setting.

Step 4: Confirm the port number.

Make sure the port you're connecting to matches the port the service is actually on. A surprising number of "refused" errors are just a wrong port in a config or URL.

Step 5: Test locally vs remotely.

From the server itself:

curl -v http://localhost:PORT

If local works but remote is refused, it's almost certainly the localhost-binding issue from step 3 — not a firewall (a firewall would give you a *timeout*, not a refusal).

When it's actually a firewall

If you see a timeout rather than "refused," now firewalls are in play:

sudo ufw status
sudo ufw allow 443/tcp

Also check any upstream/cloud network firewall. But again — pure "connection refused" points at the service or its binding, not a dropped-packet firewall.

A quick mental checklist

1. Service running? (systemctl status)
2. Something listening on the port? (ss -tulpn)
3. Bound to 0.0.0.0, not just 127.0.0.1?
4. Right port number?
5. Local works but remote doesn't → binding issue.
6. Timeout instead of refused → now look at firewalls.

Confirm reachability from the outside

Once you think it's fixed, verify from the public internet — not just from the server. Our free port checker at /tools/port-checker connects to your host and port from a remote location and tells you whether it's open, refused, or filtered. That's the definitive test of whether the outside world can actually reach your service, and it instantly separates a binding problem from a firewall one.

Running your own stack on a Nxeon VPS means full root to inspect ss, restart services and adjust bindings — with a dedicated IP and no hidden network layer between you and your ports. See /vps.