"Site can't be reached" after deploying — how to diagnose

You deployed the app, opened the domain, and got the most unhelpful message possible: “This site can't be reached.” Nothing on the page tells you whether the problem is your code, your domain, or the server.

Short version: “This site can't be reached” after deploy means the browser could not complete the trip from your laptop to your website. Diagnose it by checking each handoff in order: domain points to the right server, the server accepts traffic, a web server is listening, your app is running, and HTTPS is valid.

What does “This site can't be reached” mean after deploy?

Chrome’s exact error string, “This site can't be reached,” is a delivery failure. Think of it like a package that never reaches the front door. The address may be wrong, the road may be blocked, nobody may be home, or the doorman may not know which apartment to send it to.

A website request has a similar path:

1. Your domain name must resolve to an IP address.
2. That IP address must belong to the server you deployed to.
3. The server must allow web traffic on the right doors, usually ports 80 and 443.
4. A web server, such as nginx or Caddy, must answer the request.
5. Your app must be running behind it.
6. If you use HTTPS, the certificate must match the domain and still be valid.

The useful part is this: you do not need to guess. You walk the route in order and find the first broken handoff.

Where should you check first: domain, server, or app?

Start with the domain. It is the street address on the envelope. If the domain points to the wrong place, everything behind it can be perfect and the site still will not load.

Check that your DNS records point to the server’s public IP address. For a normal website, that usually means an A record for the root domain, such as example.com, and often another record for www.example.com. If you recently changed DNS, remember that updates can take time to spread, so two people in different places may temporarily see different results.

If the domain is new to you, this guide on how to point a domain at your server explains the idea without turning DNS into a maze.

Next, try the server IP directly in the browser. If the IP responds but the domain does not, the problem is probably DNS or the web server’s domain routing. If neither responds, move inward: firewall, web server, and app.

Why does the server answer nothing?

If the domain is right but the browser still says “This site can't be reached,” the server may be refusing the connection or not listening at all.

A firewall is like the building’s security desk. It decides which doors are open. For websites, the usual public doors are HTTP on port 80 and HTTPS on port 443. If those are closed, the browser cannot get in, even if your app is healthy.

Then there is the web server. Tools like nginx, Apache, or Caddy act like receptionists. They receive the visitor’s request and pass it to the correct app. If the receptionist is not running, is listening on the wrong port, or does not recognize your domain, the request stops there.

This is also where multiple projects can get tangled. One site may work while another fails because both are trying to use the same port, or because the web server sends the domain to the wrong folder or app. If you are hosting more than one project, it helps to keep each site’s domain, ports, and certificates clearly separated. We cover that problem in hosting multiple websites on one server.

Why does the app work locally but not after deploy?

“Works on my machine” often means the app itself is fine, but the way it is packaged or exposed on the server is different.

Your app may be running only on an internal address, so the web server cannot reach it. It may have crashed after startup because an environment variable is missing. It may be waiting for a database that is not running. Or it may be listening on a different port than the web server expects.

Docker adds one more layer. Docker is a way to run an app inside a container, like putting it in a labeled box with its own dependencies. That is useful, but the box still needs the right outside label: the server must know which public request goes to which container and port. If you are new to that idea, this plain-English guide to Docker on a server for beginners is a good companion.

HTTPS can also make a working app look broken. A wrong, missing, or expired certificate can cause browser warnings or failed secure connections. If HTTP works but HTTPS fails, the problem is probably not your app code. It is the certificate or the domain-to-certificate match.

FAQ

Does “This site can't be reached” mean my deployment failed? Not always. It means the browser could not reach the site. The app may be deployed correctly while DNS, firewall, web server routing, or HTTPS is broken.

Should I wait for DNS before changing anything else? If you just changed DNS, give it some time. But still confirm the domain points to the correct server IP, because waiting will not fix a wrong record.

Why does the server IP work but the domain does not? That usually points to DNS or web server routing. The server is reachable, but the domain is not being sent to the right website.

Why does HTTP work but HTTPS fail? The app is probably reachable, but the certificate setup is not right. Common causes are a missing certificate, an expired certificate, or a certificate issued for a different domain.

The shortcut

Server Manager helps by keeping the path from domain to running site visible instead of scattered across notes, terminal history, and memory. When a site cannot be reached after deploy, you are not left wondering whether the domain points to the wrong server, the certificate is wrong or expired, or one project’s routing has crossed into another’s.

The real benefit is that the setup stays understandable months later. You can come back to a project and still see what belongs to what: which domain serves which app, where HTTPS fits, and what changed since the last time it worked.

That does not remove the need to understand the basics. It gives you a calmer map, so the same failure modes are easier to spot and less likely to repeat.

How do you know it is fixed?

You are done when the domain loads from a normal browser, on a normal connection, with the correct HTTPS certificate and the expected page. Not just the server IP. Not just your local machine. The public domain should reach the right app consistently.

Once that happens, write down the path in plain language: domain, server, web server, app, and HTTPS. Future you will thank you when the next deploy breaks in a different way and the diagnosis starts with a map instead of panic.