Your Server Says "Running." So Why Can't You Connect?

A simple guide to cloud networking: VCNs, subnets, route tables, gateways, and security lists, using one mental model that actually makes sense.

Your instance is up. The dashboard shows a calm green RUNNING. No errors. No red flags. Nothing looks wrong.

So you try to connect. You open a terminal, type ssh, and hit enter. Nothing happens. It just hangs. Then it dies: Connection timed out.

You try again. Same thing. Nothing changed, but now doubt creeps in. Wrong key? Wrong IP? Wrong username? You check all of it. It's fine. You try a third time anyway, and now you're just confused.

Here's the real answer. It's not a typo. "On" and "reachable" are two different things.

Here's a picture that helps. Imagine your server is a person. That person is standing inside a room. The room is inside a house. The house is built on a piece of land, with a fence around the whole property. When the dashboard says RUNNING, all it's telling you is that the person is standing there, alive and well, inside the room. It says nothing about whether the fence is actually up, whether the house has a working door, or whether anyone outside is even allowed to walk in.

That's the real gap. And it comes down to five things you have to set up, each one a piece of that picture:

• The fenced property your house sits on
• The rooms inside the house
• A sign that tells you which way to walk
• The door in the outer wall
• A guard checking who's allowed through each door

Set up all five correctly, and people can reach your server. Miss even one, and you get exactly what happened above: a server that's RUNNING, and a connection that goes nowhere.

And once you know these five, you understand something bigger too: why all of this has to be set up before your app can even run. It's not extra steps the cloud is making you jump through for no reason. Most providers, including Oracle, quietly create a default version of all five the moment you spin up your first instance, so you don't always have to build them by hand. But they still exist, still get used, and still break things when one of them isn't set up the way you need. Once you see that path, cloud docs stop being confusing pages full of short-forms and unfamiliar terms. They become a simple checklist you actually understand.

We'll build this picture one piece at a time, in the order it actually has to exist. By the end, you'll know exactly which piece was missing the last time something "should have worked" and didn't.

The Property: Your VCN

Before anything else can exist, you need a piece of property.

Not a server. Not a house yet. Just an empty, fenced-off piece of ground, marking out territory that belongs to you and nobody else. In the cloud, this fenced property is called a VCN, short for Virtual Cloud Network.

This is the part people get backwards. It feels like you should spin up your server first, and the network just kind of appears around it. It's the opposite. The property always comes first. You can't build a house with no ground to put it on, and you can't run a server with no VCN to put it in. Some cloud consoles hide this from you with a quick "Create Instance" button that sets up a default VCN behind the scenes, so it can feel instance-first even when it isn't. Underneath, the order never changes: property first, then everything else on top of it.

Right now, this property is empty. No house, no rooms, no door. Just a fenced boundary that says: this address belongs to you.

That's it. That's a VCN. Nothing lives here yet, but everything you build next has to sit inside this fence.

The Rooms: Your Subnets

Now you build a house on that property. But a house isn't one giant open space. It has walls dividing it into separate rooms. In the cloud, these rooms are called subnets.

Here's the part that matters most: every room starts out locked, with no window to the street. Nobody outside can see in or reach in. This is the default for every subnet you create. Not some of them. All of them.

If you want one room to actually be reachable from outside, like a room the public should be able to walk up to, you have to unlock it on purpose. That becomes a public subnet. Every other room stays locked down. That becomes a private subnet.

So picture standing in the middle of this house. Some rooms are locked. One room has a window to the street. Nothing has told you yet how to actually move between them, or how to get out to the street from the room with the window. For that, you need a sign. That's the next piece.

The Sign: Your Route Table

Now picture a sign hanging in the hallway of your house. It doesn't open any doors. It doesn't check anyone's ID. All it does is point.

"Want to reach the database room? Go this way." "Want to reach the internet? Go that way." In the cloud, this sign is called a route table.

The important thing to understand is what this sign does not do. It only tells traffic which way to go when it's leaving somewhere. It has nothing to say about who's allowed to come in that's not a direction it points, it's just a question this sign was never built to answer. Letting people in or keeping them out is a completely different job, handled by a completely different piece, which we'll get to soon.

So there's a sign now, and it's pointing outward, telling traffic that wants to reach the internet which way to walk. Follow where it's pointing, though, and there's nothing there yet. No door. Just an empty gap in the wall. That's the next piece we need to build.

The Door: Your Internet Gateway

Now a door gets built right into that gap, in the outer wall of the house, the wall that faces the street. In the cloud, this door is called an Internet Gateway.

At first it seems like a one-way door. Traffic leaves through it to reach the internet, and that's the end of the story. But think about it for a second. If you load a website, the request goes out through this door, sure, but the response has to come back in through the same door too, or you'd never see the page load at all. So it's actually two-way. Things go out, and things come back in.

Here's the part that should worry you a little. This door has no guard standing at it. Nobody is checking who walks through, in either direction. It's not that kind of door. It's just an opening. Whether anyone should be allowed to actually walk through, and who, isn't this door's job at all.

So now there's a door, and it swings both ways. But it's wide open, with nobody watching it. Anyone on the street could walk straight up and let themselves in. That's the problem we need to solve next.

The Guard: Your Security List

So you put a guard at the front door. That fixes it, right? The guard checks IDs, checks who's allowed in, checks what they're carrying, in and out. In the cloud, this guard is called a security list, or on some platforms, a network security group (NSG). Same job, different name.

Now here's a question worth sitting with. Your private room, the one with no window, the one nobody outside can even see. Does that room need a guard too? It feels like no. Nobody from the street even knows it's there.

But think about what "private" actually means. It only means the street can't see in. It does not mean nothing inside the house can reach it.

Say your public room is running the backend of your app, reachable from the internet through the front door. Say your private room, down the hall, is running your database. If someone breaks into that public room, maybe through a bug in your app, they're not standing on the street anymore. They're already inside the house. From there, walking down the hall to the private room isn't stopped by anything, unless that room has its own guard too.

This is why a guard belongs at every single door, public and private. And it's why the guard's rules should be specific, not just "let anything in." Your backend room should only be allowed to reach the database room on one exact port, and the database room should only accept connections from that one backend room, nowhere else.

A quick word on "port," since it comes up a lot from here: a port is just a number a program picks when it starts running, so incoming traffic knows which program on the machine it's meant for, not which machine. Databases like Postgres default to port 5432, web servers often use 80 or 443. It's not something the VCN or subnet hands out. It's the software itself, listening.

If somebody asks "does the database even need rules, since it's private and hidden?", the honest answer is yes, maybe more than anywhere else. Private keeps strangers off the street from seeing it. It does nothing to stop someone who already got past your front door.

Every door gets a guard. Not because you don't trust the street. Because you don't fully trust anything, including your own house.

Common Gotchas: Why It Broke For Me

Knowing the five pieces is one thing. Actually getting them right the first time is another. These are the mistakes almost everyone runs into at some point.

"The gateway exists, so traffic should reach it." Wrong. Having a door in your outer wall means nothing if there's no sign telling traffic to walk toward it. The Internet Gateway and the route table are two separate pieces, and both have to be set up. It's a common trap: the gateway is built, but outbound traffic still doesn't work, because nothing is pointing at it. The sign has to explicitly say "internet-bound traffic, go this way, toward the gateway." Skip that, and the door might as well not exist.

"The gateway only handles outgoing traffic." Wrong. It's easy to assume a door made for reaching the internet is a one-way thing. It's not. A response has to come back through the same door it went out of. If you only think about the outbound half, you'll misunderstand what the gateway is actually doing.

"My database is private, so it's already safe." Wrong, or at least incomplete. Private means invisible from the street. It does not mean invisible from a room that's already inside your house. If your public-facing app ever gets compromised, whoever's in there is now inside the property, not outside it. A private room with no guard is only safe until something inside the house turns against it. This is the one that costs the most later, because it's invisible until the day it isn't.

The pattern behind all three: it's never just one piece. A door with no sign does nothing. A sign with no door points at nothing. A locked room with no guard is locked against the street, not against the house. The five pieces only work together.

Quick Reference: The Five Pieces

House	Cloud Term	What It Actually Does
The property	VCN (Virtual Cloud Network)	The boundary. Has to exist before anything else. Nothing lives here yet, it just marks the territory.
The rooms	Subnet	Where things actually live. Private by default. Made public only on purpose.
The sign	Route Table	Governs outbound traffic only — points it in the right direction. Has no say over inbound at all.
The door	Internet Gateway	Connects the property to the internet. Two-way, traffic goes out and comes back in. Has no guard of its own.
The guard	Security List / NSG	Decides who's actually allowed through a door, by address and by port. Belongs at every door, public and private.

The one line to remember: "Running" means your server showed up. It says nothing about the property, the rooms, the sign, the door, or the guard. All five have to be in place before anyone, including you, can actually reach it.

Building this in public, one wrong turn at a time. Follow along on X: x.com/HKsoldev

Video 1 (the full house analogy, animated) drops soon on the channel: youtube.com/@MrDevGhost