How to fix "Connection refused" on your server

You try to open your site or connect to an app, and instead of a page you get the blunt error: "Connection refused". It feels like the server slammed the door in your face.

Short version: A "Connection refused" error means your server was reached, but nothing accepted the connection on the port you tried. The usual causes are an app that is not running, the wrong port, a firewall rule, a service listening only inside the server, or a Docker port that was not exposed correctly.

What does "Connection refused" mean?

Think of your server like an apartment building.

The building exists. The street address is correct. You can walk up to the front door. But when you knock on apartment 443, nobody answers — or the door is locked from the inside.

That is different from a timeout. A timeout is like walking toward the building and never finding it, or waiting outside with no response at all. "Connection refused" is more specific: the network path got far enough to receive a clear no.

In technical terms, you reached an IP address, but the port was closed or not accepting connections. A port is a numbered doorway for a specific kind of traffic. Websites commonly use port 80 for HTTP and 443 for HTTPS. Apps, databases, dashboards, and development servers often use other ports.

Why does a server return "Connection refused"?

Most "Connection refused" cases come from one of a few plain problems.

First, the app may not be running. The server is alive, but the program that should answer the request has stopped, crashed, or never started after a reboot. This is the café being open as a building, but the counter is unstaffed.

Second, you may be knocking on the wrong door. If your app listens on port 3000 but you visit port 8080, the server may refuse you because there is simply no service there.

Third, the app may be listening only to itself. Many programs can bind to localhost, which means they accept connections from inside the server only. From the outside, it looks like the port is closed. This is like a shop with an internal staff-only entrance but no public door.

Fourth, a firewall may be blocking access. A firewall is a gatekeeper that decides which ports are allowed from the internet. If the app is running but the firewall does not allow that port, you can still see "Connection refused" or a related reachability error. If you are new to this layer, the firewall guide at how to set up a firewall on your server explains the idea without assuming you are a network engineer.

Fifth, Docker can add one more layer of doors. If your app runs in a container, it may be listening correctly inside the container but not mapped to a public port on the server. For a beginner-friendly explanation of that extra layer, see Docker on a server for beginners.

How do you find which door is closed?

Work from the outside inward. Guessing randomly wastes time because several failures look similar from the browser.

Start with the address. Are you using the right domain, IP address, and port? A typo in the port number can produce the exact "Connection refused" error even when everything else is healthy.

Next, ask whether the server itself is reachable. If nothing on the server responds, you may have a wider network, DNS, or provider problem. If some services work but one app refuses connections, the issue is likely with that app, its port, or the firewall. The post why isn't my website loading? breaks this into three layers: domain, server, and app.

Then check the app. Is it running right now? Did it crash after starting? Did it restart after the last server reboot? Many apps fail quietly because of a missing environment variable, a busy port, or a dependency that is not available yet.

After that, check where the app is listening. An app that listens on 127.0.0.1 is only available from inside the server. That can be correct if a reverse proxy is supposed to sit in front of it. But if you expect public visitors to connect directly, it will look closed from outside.

Finally, check the gatekeepers: firewall rules, reverse proxy rules, and container port mappings. A reverse proxy is a front desk for web traffic. It receives public requests on ports 80 and 443, then forwards them to the right app behind the scenes. If the forwarding points to the wrong internal port, you may see "Connection refused" even though the public website address looks right.

FAQ

Does "Connection refused" mean my server is down? Not always. It often means the server is reachable, but the specific app or port is not accepting connections.

Is "Connection refused" a DNS problem? Usually no. DNS problems often mean the name cannot find the server at all. "Connection refused" usually happens after the address has already been found.

Can HTTPS cause "Connection refused"? Yes, if nothing is listening on port 443, or if your reverse proxy is not set up to accept HTTPS traffic. Certificate problems usually produce a different warning, but the HTTPS doorway still has to be open.

Why does it work on the server but not from my laptop? The app may be listening only on localhost, or a firewall may allow local traffic while blocking outside traffic.

The shortcut

Server Manager helps by keeping the important doors visible: which project is meant to answer, which public address points to it, and whether the route still makes sense later. That matters when the real cause is not dramatic — just a wrong port, a stopped app, a missing public route, or a container that answers only to itself.

It also reduces the "I fixed this once, but I cannot remember how" problem. Months later, your setup should still be legible: which domain belongs to which app, which service is supposed to be public, and where traffic goes before it reaches the app.

The real benefit is fewer mystery refusals. You spend less time wondering whether the problem is the domain, firewall, proxy, container, or app, and more time getting the right doorway open again.

What does fixed look like?

A fixed "Connection refused" error is boring in the best way.

The right address reaches the right service. The app is running after restarts. The public port is open only where it should be. If a reverse proxy is involved, it forwards traffic to the correct internal app. If Docker is involved, the container's port is actually reachable from the place that needs it.

You do not need to memorize every networking term to solve this. Treat the server like a building with doors, guards, and rooms behind the doors. Find the closed door in order, and the error stops feeling random.