Cloud firewall vs server firewall: why your port is still blocked

You opened the port, refreshed the page, and still got nothing — no website, no app, maybe just a browser that spins until it says "Connection timed out".

Short version: in the cloud firewall vs server firewall problem, traffic has to pass two different doors before it reaches your app. The cloud firewall sits outside your server at the provider level, while the server firewall runs inside your server’s operating system. If either one blocks the port, the port is still blocked from the outside.

What is the difference between a cloud firewall and a server firewall?

Think of your server like an apartment inside a building.

The cloud firewall is the building’s front desk. It decides which visitors are allowed into the building at all. This is usually controlled in your hosting provider’s panel and may be called a cloud firewall, network firewall, Security Groups, firewall rules, or something similar.

The server firewall is your apartment door. It runs on the server itself. Common tools include ufw, iptables, nftables, and firewalld. Even if the front desk lets someone into the building, your apartment door can still refuse them.

Both can be useful. The confusion starts when you only check one.

That third row matters too. A firewall can allow port 3000, but if no app is listening on port 3000, visitors still get nowhere.

If you want the broader first-principles version, we cover the server side in how to set up a firewall on your server.

Why is your port still blocked?

Most port problems happen because people picture “open the port” as one switch. It is more like a hallway with several locked doors.

For example, your app may be running on port 8080. You allow port 8080 in ufw, so the server firewall is happy. But the cloud firewall still only allows ports 22, 80, and 443. From the outside, port 8080 is blocked before the traffic even reaches the server.

Or the reverse happens. You add a provider firewall rule for port 443, but firewalld on the server still rejects HTTPS traffic. The provider did its part, but the server door is closed.

There are a few common failure modes:

• You opened the port in the cloud firewall but not in the server firewall.
• You opened the port in the server firewall but not in the cloud firewall.
• The rule allows the wrong protocol, such as UDP instead of TCP.
• The rule allows only your old home IP address.
• The app is listening only on localhost, which means “inside this server only.”
• A container is running, but its port is not published to the outside.

That last one is common with Docker. Containers can feel like little rooms inside the apartment. The server may be reachable, but the container’s door may still not face the hallway. If that is new territory, Docker on a server for beginners explains the mental model without assuming you are already a sysadmin.

How do you find the layer that is saying no?

Start from the outside and move inward.

First, ask: can traffic even reach the server? If a public port checker says the port is closed, and you are sure your app is running, the cloud firewall is a strong suspect. Check the provider’s firewall rules for the exact port, protocol, and source address.

Next, ask: does the server allow that traffic once it arrives? This is where ufw, iptables, nftables, or firewalld matter. A common beginner mistake is assuming the provider panel tells the whole story. It does not. The server can still have its own rules.

Then ask: is anything listening? A firewall rule is not the same as an app. Opening port 80 does not create a website. Opening port 5432 does not start a database. Something must be running and listening on the public-facing address.

Finally, check whether you are testing the right address. If your domain points to an old server, you can fix firewalls all day on the new one and see no change. Domain routing is its own layer; we explain that in how to point a domain at your server.

A useful way to think about it: cloud firewall, server firewall, app, domain. Any one of those can make the service look “down.”

FAQ

Does the cloud firewall replace the server firewall? No. It can reduce what reaches the server, but the server firewall still protects the machine from inside its own operating system.

Should I use both firewalls? Usually, yes. The cloud firewall is a clean outer gate, and the server firewall is a second line of defense if rules change or a service appears later.

Why does SSH work but my website does not? Port 22 for SSH may be allowed, while ports 80 and 443 for web traffic are still blocked or not served by an app.

Is “Connection timed out” always a firewall problem? No. It often is, but the same symptom can come from a wrong IP address, a stopped app, a bad route, or a service listening only internally.

The shortcut

Server Manager helps by keeping these layers visible as one setup instead of a pile of half-remembered changes. The outcome is simple: you are less likely to open port 443 in one place, forget the other firewall, and spend an evening chasing a website that still cannot be reached.

It also helps months later, when the original setup is no longer fresh in your head. The important win is not just that the service works today; it is that the reason it works stays legible, so you can tell which ports are meant to be public and which ones should stay private.

The real benefit is fewer mystery failures: a cloud rule that blocks the port, a server firewall that rejects traffic, a domain pointing somewhere else, or an app that never exposed the port you thought it did.

What you win

When you understand cloud firewall vs server firewall, “the port is blocked” stops being a vague problem.

You can look at the path in order: provider network, server rules, running app, domain. That turns a frustrating timeout into a checklist you can actually reason through — and it keeps your server safer while you fix it.