My site won't load: is it DNS, the server, or the certificate?

When a site does not load, one of three separate layers is broken: the domain pointing at the right place, the server answering, and the connection being encrypted. All three look like "it won't load" and all three are fixed in completely different places. The order below starts with the cheapest check and tells you which one it is within a few minutes.

The browser message tells you the layer

Start the diagnosis with the text on screen, not with a guess.

1. Is it only broken for you?

This check is free and closes a noticeable share of cases. Try it over your phone's mobile data and in a private window. The browser cache, an HSTS entry and the operating system's DNS cache can hold stale information for hours; if it only fails for you, there is nothing to look for on the server.

2. Does the domain point at the right IP?

dig +short example.com
dig +short www.example.com
dig NS +short example.com

The Windows equivalent is nslookup example.com.

If your domain sits behind a CDN or proxy, dig returns that service's address rather than your server's; this is normal and not an error in itself. But it adds a layer to the diagnosis: if the proxy cannot reach your server, the error may be coming from the layer in between rather than from your machine. Temporarily bypassing the proxy, or running the direct-IP test in step 3, separates the two.

If the returned address is not the address of your server, the diagnosis ends in DNS. There are three common causes: you changed the record recently and the TTL has not expired, the domain's nameservers still point at the old provider, or — the sneakiest one — the domain itself expired. In the third case nothing on the server is broken; check the panel at your registrar.

3. Is the server answering?

You can take DNS out of the picture entirely and query the server directly. This is the single sharpest step in the diagnosis:

curl -I http://185.137.98.29
curl -I -H "Host: example.com" http://185.137.98.29

The second command sends the request with the correct domain name but straight to the IP. If you get a response here, both the server and the site are up and the problem is definitively on the DNS side. If you do not, move to step 4.

If you cannot reach the server over SSH either, solve access first: I can't connect to my server

4. Is the web service running?

systemctl status nginx
ss -tulpn | grep -E ':80|:443'
nginx -t

The reason behind a "connection refused" almost always shows up here: the service has stopped, or it was never restarted after a configuration change. nginx -t tests the configuration without applying it and gives you the line number if something is wrong.

If the service will not start, rule out a cause nobody thinks of: a full disk. A web server that cannot write its log does not come up, and the error message does not say so directly. How to check and clear it safely: the disk is full

5. The certificate

Certificate problems look alarming in the browser but are easy to diagnose:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject

If the notAfter date in the output is in the past, the certificate has expired. With Let's Encrypt three causes are common: the renewal job is not running, port 80 needed for validation has been closed in the firewall, or the domain no longer points at that server so validation fails.

If the domain in the subject line does not match what you asked for, the certificate is for the wrong name — most often it covers only the apex domain and throws an error when the site is opened with www.

6. If you still have not found it: the logs

journalctl -u nginx -n 50 --no-pager
tail -n 100 /var/log/nginx/error.log

The cause of 500 and 502 errors is written there. A 502 means the web server could not reach the application behind it (PHP-FPM, Node, an application server); check separately whether that process is running. Another frequent root cause is the database not answering: MySQL performance tuning

When to open a support ticket

In these situations there is nowhere left to go on your own:

• You get no response from curl straight to the IP and you cannot reach the server over the console either.
• DNS is correct, the service is running, the certificate is valid — and it still cannot be reached from outside.
• You are on web hosting and the problem is at service level: you do not have access to the server services anyway, so opening a ticket directly is the fastest route.

Attach the domain, the exact text of the error message, the dig +short output and the time the problem started. What the downtime means under the commitment is a separate subject: uptime and SLA

If the problem keeps coming back and the cause is a resource limit, you have to return to the question of which layer the site should be hosted on. Limits are different on configurations prepared for WordPress; if you want to see the limits and the monthly figure for both options side by side: which one fits your site better, with current pricing