Why isn't my website loading? The three layers that decide if it's reachable

You did everything right. The site is deployed, it runs, you can see it. Then you send the link to a friend and… nothing. A spinning tab, a "this site can't be reached," a "took too long to respond." It works for you and not for them — the most maddening kind of broken.

Here's the good news: a website that won't load is almost never a mystery. There are exactly three layers between a visitor's browser and your running site, and the problem is always in one of them. Once you know the three, you stop guessing and start checking.

The three layers

When someone types your address, their request travels through:

1. The name — DNS turns yourdomain.com into your server's IP address.
2. The door — the request has to actually reach your server on the right port (80 for HTTP, 443 for HTTPS).
3. The app — something on the server has to be listening, and answer.

A failure at any one of these looks identical from the outside: the page doesn't load. The trick is working out which layer. Three quick questions get you there.

Layer 1 — Is the name pointing at the server?

Ask: does it load if you visit the IP address directly (e.g. http://203.0.113.10)?

If the IP works but yourdomain.com doesn't, the problem is the name — DNS. Either the domain isn't pointing at the server, or the change hasn't propagated yet. Browser errors like "server not found" or "we can't find that site" point here too.

Fix: check that the domain's DNS record points at your server's IP. (We wrote a guide on exactly this: pointing a domain at your server.)

Layer 2 — Can the request reach the door?

Ask: does it load from the server itself, but not from your laptop?

If you can reach the site when you're on the server but not from outside — and the symptom is "took too long to respond" or a connection that just hangs — the request isn't getting through the door. Something is blocking the port.

There are usually two doors to check, and people forget the second one:

• The server's own firewall (like ufw) — is port 80/443 allowed in?
• Your provider's firewall — many hosts have a separate firewall or "security group" outside the server, configured in their dashboard rather than on the machine. A port can be open on the server and still blocked here.

Both have to allow the traffic.

Layer 3 — Is the app actually answering?

Ask: does it fail even on the server itself?

If it won't load even from the server — "connection refused," or an error page instead of your site — the problem is the app. Either the thing that serves your site isn't running (a stopped container, a crashed service), or the web server in front of it is pointed at the wrong place.

Fix: check that your site's service is up, and that whatever routes traffic to it — the reverse proxy — is configured for the right domain and port.

Putting it together

Three questions, in order:

• Loads by IP but not by name? → Layer 1, DNS.
• Loads on the server but not from outside? → Layer 2, a firewall.
• Doesn't load even on the server? → Layer 3, the app.

That's the whole diagnostic. No more refreshing and hoping.

The shortcut

You can walk these checks yourself — or you can just ask. Tell Faro, the assistant inside Server Manager, that your site won't load, and it checks all three layers for you: whether the domain resolves, whether the ports are open, whether the service is running and routed. It tells you which layer is broken and, usually, fixes it — instead of leaving you to bisect the stack by hand.

Your server, understood

A site that won't load feels like a wall. It isn't — it's just one of three doors, and now you know which to try. That's the quiet benefit of running your own server: when something breaks, it's yours to understand, and the map is small enough to hold in your head.

The help guides go deeper on DNS, firewalls, and the reverse proxy when you want the detail.